#include <stdio.h>
#include <orion/socket/http.h>

void handleResponse(char* buffer, _uint32 len);

int main(int argc, char** argv)
{
    orion_httpRequest* request = NULL;
    orion_initHttpRequest(&request);
    orion_setHttpRequestHost(request, "registro.br", 80);
    orion_setHttpRequestPath(request, "/cgi-bin/whois/");
    orion_setHttpRequestMethod(request, "POST");
    orion_setHttpRequestQuery(request, "qr=www.bugsec.com.br");
    orion_setHttpRequestOption(request, ORION_OPTDEBUG_REQUEST);
    orion_setHttpRequestHeader(request, "User-Agent", "Mozilla/1.0");

    orion_httpGet(request, handleResponse, 1024);

    orion_cleanupHttpRequest(request);

    return 0;
}

void handleResponse(char* buffer, _uint32 len)
{
    printf("%s", buffer);
}

[BugSec Team]
i4k, m0nad, Cooler, _mlk_

No post anterior eu mostrei como receber a resposta numa string do tipo C. Mas é possivel também ter a resposta já numa estrutura.

A estrutura orion_httpResponse tem a seguinte declaração:

header <orion/socket/http.h>

typedef struct
{
    _uint8 version;         /* HTTP version. 1.0 || 1.1 */
    _uint16 code;            /* Status Code              */
    char* message;          /* Server Message           */
    char* serverName;       /* Server Name              */
    char* date;             /* Date                     */
    char* expires;          /* Expires time             */
    char* location;         /* Location.                */
    char* mime_version;     /* MIME-VERSION             */
    char* content_type;     /* Content-Type             */
    char* charset;          /* Charset                  */
    _uint32 content_length;   /* Length of the content;   */

    nameValue *header;      /* HTTP Headers             */
    _uint8 headerLen;       /* Number of headers        */

    nameValue *cookie;      /* Set Cookie               */
    _uint8 cookieLen;       /* Number of cookies        */

    char* body;             /* Body of the response     */
} orion_httpResponse;

A função que faz a requisição e retorna as informações nessa estrutura é a orion_httpReqRes(), o protótipo dela é o seguinte:

_uint8 orion_httpReqRes(orion_httpRequest* req, orion_httpResponse** res2);

O primeiro parametro é a estrutura com as informações da requisição e o segundo o ponteiro para o ponteiro da estrutura resposta.

Abaixo um exemplo simples com a forma de utilização:

#include <stdio.h>
#include <stdlib.h>
#include <orion/socket/http.h>

int main(int argc, char** argv)
{
    orion_httpRequest* req = NULL;
    orion_httpResponse* res = NULL;
    int i;

    // Inicializa a requisição
    orion_initHttpRequest(&req);

    orion_setHttpRequestHost(req, "www.unicheck.com.br", 80);

    // Não há a necessidade de inicializar res (orion_httpResponse)
    int code = orion_httpReqRes(req, &res);

    // or if (!code)
    if (code == ORIONSOCKET_OK)  // ORIONSOCKET_OK = 0x00
    {
        /**
         * A resposta encontra-se na estrutura orion_httpResponse *res
         */
        printf("################################\n");
        printf("# HEADERS:\n");

        printf("# Http Version: 1.%d\n", res->version);
        printf("# Http Status Code: %d\n", res->code);
        printf("# Server Message: %s\n", res->message);
        printf("# Server Name: %s\n", res->serverName);
        printf("# Server Date: %s\n", res->date);
        printf("# Todos os Headers: \n");
        for (i = 0; i < res->headerLen; i++)
        {
            printf("# %s: %s\n", res->header[i].name, res->header[i].value);
        }

        printf("################################\n");
        printf("# Body Content: \n");
        printf("%s\n", res->body);
    }

    // Desaloca a memória da requisição e da resposta
    orion_cleanupHttpRequest(req);
    orion_cleanupHttpResponse(res);

    return 0;
}

Tenho muita coisa pra fazer ainda, mas já dá pra brincar

OrionSocket é uma biblioteca (ainda bem simples e em desenvolvimento) em alto nível para manipulação de sockets em C em Linux/*BSDs. O foco dela é mais agilizar o desenvolvimento de aplicações cliente/servidor para os protocolos HTTP, FTP, etc. Ainda há muita coisa a ser feita, portanto vou postando aqui as funcionalidades que forem sendo adicionadas com o tempo.

O projeto é opensource e também está hospedado no google code no link http://orionsocket.googlecode.com/.

Download

Depois de baixar, o modo de instalação é o velho conhecido dos usuários linux/BSDs:
$ tar zxvf orionsocket-1.0.4.tar.gz
$ cd orionsocket-1.0.4
$ ./configure –prefix=/diretorio/para/instalar
$ make
$ sudo make install

Agora vamos ver como utilizar a biblioteca.

Exemplo 1:

/**
 * Author: Tiago Natel de Moura
 * Date: 14/08/2010
 */
#include <stdio.h>
#include <stdlib.h>
// Library OrionSocket
#include <orion/socket/http.h>

int main(int argc, char** argv)
{
	orion_httpRequest *req = NULL;
	char *response = NULL;
	int code;

	const char* domain = "universemachine.wordpress.com";
    // Inicializa a estrutura orion_httpRequest
    orion_initHttpRequest(&req);
    // Ajusta o host e a porta alvo
    orion_setHttpRequestHost(req, domain, 80);
    // Ajusta o PATH da requisição, por default é /
    orion_setHttpRequestPath(req, "/");

    // Ajusta um Header qualquer, no caso o User-Agent
    orion_setHttpRequestHeader(req, "User-Agent", "Anakin SkyWalker");

    // Faz a requisição HTTP e retorna a resposta do servidor na variavel response
    code = orion_httpRequestPerform(req, &response);

    if (code == ORIONSOCKET_OK)
    {
        printf("%s\n", response);
        free(response);
    }

    // Desaloca a memória da estrutura
    orion_cleanupHttpRequest(req);

    return 0;
}

Para compilar utilize:

$ gcc -Wall exemplo1.c -o exemplo1 -lorionsocket

O exemplo acima está bem documentado e mostra como é simples e rápido fazer um cliente http. Mas a função orion_httpRequestPerform nem sempre é uma boa opção, pois ela faz a requisição no servidor e armazena toda a resposta na variavel passada como buffer para ela. Para fazer isso, ela lê todo o socket e só depois traz a resposta. Em alguns casos, por exemplo quando a resposta for muito grande ou em servidores que não retornam todo o buffer de uma vez (google.com), sua aplicação pode ficar vários segundos à espera da resposta sem ter feedback do que está ocorrendo.
Pra resolver esse problema, existe uma outra função muito útil chamada orion_httpGet que utiliza de um callback, deixando assim o desenvolvedor manipular o buffer de resposta.

Abaixo um exemplo utiiizando orion_httpGet().

Exemplo 2:

#include <stdio.h>
#include <orion/socket/http.h>

void myCallBack(char* buffer, unsigned int count)
{
    printf("%s\n", buffer);
}

int main(int argc, char** argv)
{
    orion_httpRequest* req = NULL;

    orion_initHttpRequest(&req);
    orion_setHttpRequestHost(req, "universemachine.wordpress.com", 80);

    // Realiza a requisição no host especificado em req e envia o buffer
    // para a função myCallBack
    int code = orion_httpGet(req, myCallBack, 100);

    if (code == ORIONSOCKET_OK)
        printf("\n[+] requisição realizada com sucesso.\n");
    else
        printf("\n[-] erro ao fazer requisição...\ncodigo de erro=%d\n", code);        

    orion_cleanupHttpRequest(req);
    return 0;
}

$ gcc -Wall -o exemplo2 exemplo2.c -lorionsocket

A assinatura da função orion_httpGet é:
_uint8 orion_httpGet(orion_httpRequest* req, void (* callback)(char*,_uint32), _uint32 count)

Em breve disponibilizarei uma documentação online (doxygen) do projeto.

Se voce achar realmente necessário, voce pode baixar o nível e trabalhar diretamente com o socket da seguinte forma:

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <sys/socket.h>

#include <orion/socket/socket.h>

#define LEN 1024

int main(int argc, char** argv)
{

    if (argc < 2)
    {
        fprintf(stderr, "[ERROR] Usage: %s <host> <port>\n", argv[0]);
        return 0;
    }

    char temp[LEN];
    int n;

    // Inicializa um socket TCP/IP e conecta no alvo
    // Retorna o socket criado e conectado
    int sockfd = orion_tcpConnect(argv[1], atoi(argv[2]));

    bzero(temp, LEN);
    if (send(sockfd, "GET / HTTP/1.1\nHost: xxx\n\n", 26, 0) < 0)
    {
        fprintf(stderr, "[-] Erro ao enviar os dados.\n");
        close(sockfd);
        return 1;
    }

    while ((n = read(sockfd, temp, LEN-1)) > 0)
    {
        printf("%s\n", temp);
        bzero(temp, LEN);
    }

    close(sockfd);

    return 0;
}

$ gcc -Wall -o exemplo3 exemplo3.c -lorionsocket

É isso aí, os exemplos estão comentados. Conforme a API for ganhando forma eu vou postando aqui as formas de utilização.

No ano passado eu estudei PHP-GTK e adorei. Muito fácil desenvolver uma aplicação com um ambiente agradável em poucas linhas de código. Só que o PHP é uma linguagem voltada para a web então muitos dos recursos que seriam necessários à uma aplicação gráfica não estão disponíveis. Por isso que na época acabei me interessando em entender como se escreve uma extensão para o PHP. E descobri que é muito fácil.
Há tempos que estava querendo escrever sobre isso.

Fractais em PHP

Não vou ensinar a fazer o chato do hello world mas sim uma extensão que cria fractais. Depois de a extensão pronta poderemos chamar a função orion_fractal() como se fosse uma função nativa do PHP.
Esse código PHP:

<?php

print orion_fractal();

Imprimirá na tela:

Configurando um ambiente de desenvolvimento [LINUX]

No linux já temos um ambiente de desenvolvimento em C nativo, então tudo que precisaremos é do código fonte do PHP.
Código fonte do PHP

Eu fiz este tutorial com o PHP 5.3.1 mas deve funcionar normalmente em qualquer versão do PHP >= 5.2.0.
Eu utilizei o diretório $HOME/php/dev para o desenvolvimento, assim:

# cd $HOME/php/dev
# svn checkout http://svn.php.net/repository/php/php-src/branches/PHP_5_3 php-src-5.3
# cd php-src-5.3
# pwd
$HOME/php/dev/php-src-5.3

Da outra vez que mechi com extensões para o php eu usava o fedora e não tive nenhum problema com as compilações, mas desta vez (archlinux) tive um pequeno problema, vou explicar:
Você não conseguirá rodar o buildconf para gerar o configure com qualquer variação de versão das ferramentas autoconf, automake e libtool. As combinações de versões que certamente funcionarão são:

• autoconf 2.13, automake 1.4 and libtool 1.4.3
• autoconf 2.13, automake 1.5 and libtool 1.4.3
• autoconf 2.63, automake 1.11 and libtool 2.2.6 (Com vários warnings)

Leia aqui: http://www.php.net/svn.php#buildconf_fail
Como eu tinha o autoconf 2.64, o automake 1.4 e a libtool 2.2.6 eu decidi ir pela terceira alternativa e instalar o autoconf 2.63. E conforme na tabela foram vários warnings mas deu pra trabalhar tranquilamente.

As extensões do PHP ficam dentro do diretório ext. Ali estão os fontes de todas as extensões, é legal dar uma olhada.
O PHP provê uma ferramenta para automatizar/facilitar o processo de criação de extensões, ela se chama ext_skel:

# cd ext
# ./ext_skel --help
./ext_skel --extname=module
             [--proto=file]
             [--stubs=file]
             [--xml[=file]]
             [--skel=dir]
             [--full-xml]
             [--no-help]

  --extname=module   module is the name of your extension
  --proto=file       file contains prototypes of functions to create
  --stubs=file       generate only function stubs in file
  --xml      generate xml documentation to be added to phpdoc-cvs
  --skel=dir         path to the skeleton directory
  --full-xml  generate xml documentation for a self-contained extension
                (not yet implemented)
  --no-help   don't try to be nice and create comments in the code
                  and helper functions to test if the module compiled

O único parametro que nos importa no momento é o obrigatório –extname que dará o nome da sua extensão.
Vamos iniciar a criação da extensão, digite:

# ./ext_skel --extname=orion

Dê o nome que quiser para sua extensão, mas lembre-se que este deve ser um nome único, não deve haver outra extensão com este nome.
Ao rodar este comando será criado o esqueleto (skel) da sua extensão dentro de um diretório com o mesmo nome escolhido para o módulo, dentro de ext. No meu caso criou-se o diretório “$HOME/php/dev/php-src-5.3/ext/orion”.
Entre nesse diretório e vamos ver o que foi criado.

• orion.c: Arquivo fonte da sua extensão
• orion_php.h: Header da extensão
• config.m4: Macros do GNU/M4
• orion.php: Arquivo PHP para testar a extensão
• tests/001.phpt: TEST

O próximo passo é habilitarmos a extensão no arquivo config.m4.
O config.m4 é o arquivo de macros do programa GNU/m4. Com esse programa podemos usar macros de substituição para diversas tarefas, seu uso é geral do mesmo modo que o make. As macros dos arquivos m4 geralmente são usadas para criar os arquivos de configuração configure.ac que por sua vez gerará o configure.
Esses arquivos m4 aparentemente são bem difíceis mas na verdade eles ajudam muito e facilitam a tarefa mais argilosa que seria manipular um projeto grande diretamente pelos Makefile‘s.
A sintaxe do m4 é parecida com shell script. Mas no m4 comentários são dados por “dnl “. Todas as linhas que iniciarem com “dnl” são comentários.
Abra o arquivo config.m4 procure por esse trecho de código:

dnl PHP_ARG_ENABLE(orion, whether to enable orion support,
dnl Make sure that the comment is aligned:
dnl [  --enable-orion           Enable orion support])

Aqui era a linha 16.
Você deve descomentar deixando assim:

PHP_ARG_ENABLE(orion, whether to enable orion support,
dnl Make sure that the comment is aligned:
[  --enable-orion           Enable orion support])

Agora vamos gerar um novo configure. Toda vez que você alterar o arquivo config.m4 você deverá rodar o script buildconf na raiz do projeto.
Rodando o buildconf:

# pwd
$HOME/php/dev/php-src-5.3
# ./buildconf --force

Esse script é um pouco demorado. Se der algum erro, veja as versões das suas ferramentas de compilação como falei na tabela lá em cima. Autoconf, Automake e libtool devem ter alguma daquelas combinações de versões.

Se deu tudo certo foi gerado um novo configure.
Para habilitar sua extensão rode o configure com a opção –enable-[SUA-EXTENSÃO].
No meu caso seria: ./configure –enable-orion
E depois compile com make.
Não rode o “make install” pois isto instalará o PHP e não é o que a gente quer. Só queremos compilá-lo. O binário do php, depois de compilado (dãã) fica em sapi/cli/php.
Para testar se a sua extensão foi compilada com sucesso rode o script orion.php (minha_extensao.php) gerado automaticamente dentro de ext/orion/orion.php.

# sapi/cli/php ext/orion/orion.php
Se aparecer a sua extensão na tela e a função confirm_orion_compiled é porque está tudo certo !

Pronto, seu ambiente de desenvolvimento de extensões para o PHP está pronto !

Introdução à API do PHP

É sempre recomendado utilizar a API que o PHP dispõe para criar as extensões, porque dessa maneira o núcleo do PHP irá poder controlar o fluxo da aplicação, a memória, etc. É claro que você pode usar funções das bibliotecas nativas do C como printf(), scanf(), fopen(), etc, mas não é recomendado. Primeiro porque muitas destas funções não são seguras e depois porque o PHP provê todas estas funções de uma maneira integrada com o core. A maoria destas funções são binary-safe, portanto é sempre bom utilizá-las quando for manipular dados vindos do usuário.

A maioria (ou todas?) destas funções da API são MACROS e estão definidas em Zend/zend_API.h, vale a pena dar uma olhada. No começo vai parecer bem bagunçado, mas com o tempo você se acostuma.
Neste header, a maioria das MACROS estão definidas como ZEND_*, mas você verá os tutoriais na net mandando chamar MACROS como PHP_*, isso é porque lá no header main/php.h você verá vários #define’s como:
#define PHP_FUNCTION ZEND_FUNCTION
#define PHP_METHOD ZEND_METHOD
Então tanto faz qual nomenclatura você utilizar, mas vale lembrar que as extensões que bisbilhotei lá no ext/* usam PHP_*.

A macro mais importante para o nosso caso é a PHP_FUNCTION. É com ela que criaremos as funções da nossa extensão. Ela recebe apenas um argumento, o nome da função.

...
PHP_FUNCTION(minha_funcao)
{
    RETURN_STRING("Essa é a minha primeira função.", 1);
}
...

Isso é uma função válida. Como falei, utilizamos apenas a API, se você usar return na função, você retornará um código para o core do PHP e não será a definição do retorno da sua função. Deixa eu explicar melhor:
Como estamos tratando de duas linguagens, extendendo a linguagem PHP a partir do C, temos que usar a interface da ZEND para se comunicar corretamente com o PHP. Então ao invés de usar return para retornar um valor da função que estou criando, deve-se usar as macros RETURN_STRING, RETURN_LONG, RETURN_*, etc, pois desta forma o core do PHP saberá o que fazer.
Existe uma macro para cada tipo que você deseja retornar, veja a tabela abaixo:

RETURN_RESOURCE(resource) = Retorna um resource.
RETURN_BOOL(bool) = Retorna um valor booleano.
RETURN_NULL() = Retorna nada (NULL).
RETURN_LONG(long) = Retorna um Long (Inteiro).
RETURN_DOUBLE(double) = Retorna um ponto flutuante de dupla precisão.
RETURN_STRING(string, duplicate) = Retorna uma string. A flag duplicate indica se a string deve ser duplicada com estrdup().
RETURN_STRINGL(string, length, duplicate) = Retorna uma string de determinado tamanho length.
RETURN_EMPTY_STRING() = Retorna uma string vazia.
RETURN_FALSE = Retorna o booleano false.
RETURN_TRUE = Retorna o booleano true.

Pode-se retornar arrays ou objetos também, mas para isso deve-se usar as funções array_init() e object_init()

Existe duas maneiras de se pegar os parametros passados para a sua função. Você pode usar a função zend_parser_parameters ou pegar diretamente pela macro TSRMLS_CC. A primeira alternativa é bem mais fácil e funciona da seguinte maneira:

...
PHP_FUNCTION(minha_funcao)
{
    int argc;
    char *argv;

    if(zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, "s", &argv, &argc) == FAILURE)
    {
        return;
    }

    RETURN_STRING(argv, 1);
}
...

O primeiro parâmetro nunca mudará, o segundo indica o tipo do argumento. No caso “s” indica que deve ser do tipo STRING. Veja os tipos possíveis:

• l – long
• d – double
• s – string (com possíveis bytes nulos) e o seu tamanho (length)
• b – boolean
• r – resource, armazenado em zval*
• a – array, armazenado em zval*
• o – object (of any class), armazenado em zval*
• O – object (de uma classe específica), armazenado em zval*
• z – zval* atual

Você pode usar eles em conjunto para setar todos os parâmetros da função, por exemplo: “sl” recebe como primeiro parâmetro uma string e segundo um inteiro. “ssb” recebe três parametros, string, string e booleano.
Existe outros três caracteres modificadores importantes:

• | (pipe) – Indica que os próximos tokens (parâmetros) são opcionais. ex.: “s|b” torna “b” opcional
• / – Chamará SEPARATE_ZVAL_IF_NOT_REF() para pegar a cópia do parâmetro.
• ! – O parâmetro pode ser de um tipo específico ou NULL. Somente se aplica à “a”, “o”, “O”, “r” e “z”.

Se zend_parse_parameter for chamado da maneira como acima, o PHP emitirá um WARNING se o usuário tentar passar um número de diferente de parâmetros para a função ou se um dos tipos não coincidirem.

Agora que já sabemos como pegar um parâmetro passado para a função e como retornar um valor da função, é só escrever a lógica da sua função e pronto.

Escrevendo a função orion_fractal()

Como vimos lá no começo, o script ext_skel cria a estrutura básica de arquivos que a extensão precisará, incluindo um header php_MINHA-EXTENSAO.h, no meu caso php_orion.h. Nesse arquivo, devemos colocar os cabeçalhos das nossas funções. Então vamos lá, abra esse arquivo:

php_orion.h

/*
  +----------------------------------------------------------+
  | PHP Version 5                                                              |
  +----------------------------------------------------------+
  | Copyright (c) 1997-2008 The PHP Group                            |
  +----------------------------------------------------------+
  | This source file is subject to version 3.01 of the PHP license, |
  | that is bundled with this package in the file LICENSE, and is  |
  | available through the world-wide-web at the following url:    |
  | http://www.php.net/license/3_01.txt                                |
  | If you did not receive a copy of the PHP license and are unable to |
  | obtain it through the world-wide-web, please send a note to  |
  | license@php.net so we can mail you a copy immediately.    |
  +---------------------------------------------------------+
  | Author: Tiago Natel de Moura                                  |
  +---------------------------------------------------------+
*/

/* $Id: header 252479 2008-02-07 19:39:50Z iliaa $ */

#ifndef PHP_ORION_H
#define PHP_ORION_H

extern zend_module_entry orion_module_entry;
#define phpext_orion_ptr &orion_module_entry

#ifdef PHP_WIN32
#	define PHP_ORION_API __declspec(dllexport)
#elif defined(__GNUC__) && __GNUC__ >= 4
#	define PHP_ORION_API __attribute__ ((visibility("default")))
#else
#	define PHP_ORION_API
#endif

#ifdef ZTS
#include "TSRM.h"
#endif

/**
 * Limites dos Buffers usados na função orion_fractal()
 */
#define FRACTAL_BUF 3000
#define ASCII_BUF 80

PHP_MINIT_FUNCTION(orion);
PHP_MSHUTDOWN_FUNCTION(orion);
PHP_RINIT_FUNCTION(orion);
PHP_RSHUTDOWN_FUNCTION(orion);
PHP_MINFO_FUNCTION(orion);

/**
 * Aqui definimos os cabeçalhos das funções.
 * Essa função "confirm_orion_compiled()" é criada
 * automaticamente com o ext_skel().
 */
PHP_FUNCTION(confirm_orion_compiled);	/* For testing, remove later. */
PHP_FUNCTION(orion_fractal);  /** cabeçalho da nossa função */

/*
  	Declare any global variables you may need between the BEGIN
	and END macros here:

ZEND_BEGIN_MODULE_GLOBALS(orion)
	long  global_value;
	char *global_string;
ZEND_END_MODULE_GLOBALS(orion)
*/

/* In every utility function you add that needs to use variables
   in php_orion_globals, call TSRMLS_FETCH(); after declaring other
   variables used by that function, or better yet, pass in TSRMLS_CC
   after the last function argument and declare your utility function
   with TSRMLS_DC after the last declared argument.  Always refer to
   the globals in your function as ORION_G(variable).  You are
   encouraged to rename these macros something shorter, see
   examples in any other php module directory.
*/

#ifdef ZTS
#define ORION_G(v) TSRMG(orion_globals_id, zend_orion_globals *, v)
#else
#define ORION_G(v) (orion_globals.v)
#endif

#endif	/* PHP_ORION_H */

/*
 * Local variables:
 * tab-width: 4
 * c-basic-offset: 4
 * End:
 * vim600: noet sw=4 ts=4 fdm=marker
 * vim<600: noet sw=4 ts=4
 */

A maioria desse arquivo foi gerado automaticamante. As únicas alterações ali foram duas macros que utilizarei lá na função e o cabeçalho que incluímos.

Além de definirmos o cabeçalho da função em php_orion.h também temos que registrá-la no core do zend. Para isso procure pela seguinte linha em minha_extensao.c:

const zend_function_entry orion_functions[] = {
	PHP_FE(confirm_orion_compiled,	NULL)		/* For testing, remove later. */
	{NULL, NULL, NULL}	/* Must be the last line in orion_functions[] */
};

No meu caso é orion.c.
É nesse array que dvemos registrar todas as funções da extensão. Para adicionar uma nova função faça:

const zend_function_entry orion_functions[] = {
	PHP_FE(confirm_orion_compiled,	NULL)
	PHP_FE(orion_fractal, NULL)
        PHP_FE(orion_outra_funcao, NULL)
        PHP_FE(orion_outra_outra_funcao, NULL)
	{NULL, NULL, NULL}	/* Must be the last line in orion_functions[] */
};

Note que não há “virgulas” entre cada função, apenas insira elas dentro da macro PHP_FE(). O final desse array deve ser {NULL, NULL, NULL}, do contrário haverá erros.

Depois de registrar suas funções, é só codá-las. Aqui a minha função orion_fractal():

orion.c

...

/**
  * @param   ascii    opcional
  * return STRING
  */
PHP_FUNCTION(orion_fractal)
{
	char *ascii;
	int ascii_len = 0;
	char str[FRACTAL_BUF];
	char b[ASCII_BUF] = " .:-;!/>)|&IH%*#";
	float i,j,r,k,x,y=-16;
	int t,idx=0;

        /**
         * A função aceita um parâmetro do tipo string opcional.
         * Se passado um valor para a função o algoritmo usará essa
         * string para imprimir o ascii ao invés de b[].
         */
	if (zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, "|s", &ascii, &ascii_len) == FAILURE) {
		return;
	}

	if(ascii_len == 0)
	{
                /**
                  * Use emalloc ao invés do malloc, isso garante que o Zend Engine
                  * possa controlar a memória alocada.
                  */
		if(! (ascii = (char *) emalloc(ASCII_BUF*sizeof(char))))
		{
			printf("Extension \"orion\" error: Não foi possivel alocar memória.\n");
			exit(1);
		}

		ascii = b;
	}

	while ((str[idx] = '\n') && y++<15)
	{
		idx++;
		for( x=0; x++ < 84; str[idx] = ascii[(int)k & 15] )
		{
			if(isascii(str[idx]) && str[idx] != '')
				idx++;

			for(i=k=r=0; j=r*r-i*i-2+x/25, i=2*r*i+y/10, j*j+i*i < 11 && k++ < 111; r=j);

			if(idx == (FRACTAL_BUF-1))
			{
				printf(&quot;ERROR: Estouro de buffer.\n&quot;);
				exit(1);
			}
		}
	}

	str[idx] = '\n';
	str[++idx] = '';

	RETURN_STRINGL(str, strlen(str), 1);
}

...

Pronto, criada a sua função, com protótipo devidamente declarado e registrada “zend_function_entry” podemos compilar a extensão. Para isso volte no diretório principal do PHP e rode o make:

# pwd
$HOME/php/dev/php-src-5.3
# make

Não rode o “make install” pois isto instalará o php no PATH e pode substituir o seu outro PHP (se for o caso).
Compilado!!! Para testar crie o seguinte arquivo PHP:

ext/orion/exemplo_fractal.php

<?php

print orion_fractal();
print orion_fractal(strrev(" .:-;!/>)|&IH%*#"));

?>

Para rodar este exemplo use o comando:
# sapi/cli/php ext/orion/exemplo_fractal.php

Bom, é isso. É um exemplo bem simples mas a partir daqui você já pode criar suas extensões. Claro que terá que estudar mais a API do core, mas a .introdução está dada.
Pretendo dar um exemplos mais avançados quando tiver um tempo.

Até a próxima !

Referências/Links/Documentação:
http://devzone.zend.com/node/view/id/1021
http://br2.php.net/manual/pt_BR/internals2.ze1.zendapi.php
http://www.tuxradar.com/practicalphp/20/0/0
http://docstore.mik.ua/orelly/webprog/php/ch14_07.htm
http://www.edgeofnowhere.cc/viewtopic.php?t=239515
http://www.php.net/svn.php#buildconf_fail

Eu desenvolvo com o VIM e com o kate e eles não possuem um plugin para testes como no eclipse/netbeans etc… Então, para rodar os testes unitários nestes editores eu uso sempre algum script em shell junto com arquivos Makefile pois daí não preciso criar nenhum plugin para o vim ou kate porque eles já possuem um plugin de compilação.

No VIM é só digitar :make em modo de comando e no kate (se a extensão de comandos do vim estiver desabilitada) é só usar o plugin “builder” ou “construtor” e teclar ALT+R para compilar, o kate possui uma interface para configurar o comando padrão que rodará no make.

Na verdade, eu uso o make em muito mais coisas com o PHP… Por exemplo, agora que o PHP 5.3 ainda não está sendo utilizando na maioria das hospedagens e pouca gente migrou eu estou usando o make para compilar meus fontes PHP de modo a ficarem portáveis à PHP 5.2 e 5.3, mas isto pretendo falar em um post em breve.

Controlando os Testes com Makefile

SimpleTest e PHPUnit suportam Test Suite para automatizar os testes de toda a aplicação, por exemplo, mas tem uma coisa que não gosto… Com test suite soma-se todos os “Passes” e “Failures” como se fosse apenas um teste.
Isto nem sempre é bom. Um dos problemas é que se voce colocar todos os seus testes numa única suíte de testes eles ficarão muito demorados (dependendo do tamanho dos testes).

E se cada vez que você rodar seus testes todos forem rodados (até testes que já passaram sem ligação nenhuma com o que se está desenvolvendo no momento) isto é tempo perdido. Numa aplicação pequena isto é imperceptivel, mas se o sistema abusa de I/O e/ou utiliza muitas bibliotecas/frameworks externos, isso é um problema.

Eu gosto de ter todos os meus testes separados. E criar várias rotinas de teste prontas com Makefile. Daí se eu preciso rodar todos os testes eu utilizo:

$ make test-all

Se quero apenas rodar os testes do DAO, por exemplo, faço:

$ make dao

E assim por diante, eu acho mais vantajoso e vou mostrar como que faço.

Makefile

Na verdade, não precisaria usar o make pra rodar os testes no vim e no kate. Porque podemos abrir o terminal dentro deles e no caso do vim criar um plugin é relativamente fácil, mas usando makefiles fica tudo mais organizado, não preciso instalar algo novo em cada máquina que irei trabalhar e é mais fácil de fazer manutenção e inserir novos testes.

Bom, não irei me aprofundar em explicar sobre o make, porque seria bem extenso e deveria render um post inteiro.
Mas o make é simples e entender os seus Makefile’s é mais simples ainda, mas dependendo do que você queira fazer pode ser uma baita dor de cabeça.

Basicamente, o make é um programa inteligente para gerar outros programas. Ele é utilizado 99% das vezes para compilação de programas em C/C++ e quem utiliza linux já está acostumado com eles. Mais o importante saber é que o make pode automatizar qualquer rotina, independente da linguagem. Neste uso com unit tests vamos usar o make somente para chamar o script que testará a aplicação, não será usado nenhum benefício real do make. Sugiro, pra quem não o conhece, dar uma lida sobre ele.

O make lê arquivos de configuração chamados Makefile. Quando rodamos “make” na linha de comando ele procura por algum arquivo Makefile no diretório corrente, se encontrar lê e executa as operações. Essas operações são regras que seguem o seguinte formato:

#   Arquivo Makefile exemplo
#   "#" é um comentário
objetivo: dependencia1 dependencia2
    # Aqui vêm as operações, geralmente a compilação

dependencia1:
    # Criação da dependencia1

dependencia2:
    # Criação da dependencia 2

Note que se eu chamar o make com:
$ make objetivo

Ele primeiramente chamará a regra “objetivo” que possui duas dependencias, como “objetivo” precisa delas para compilar, ele verificará se elas já existem, se não existem e forem mais antigas que a ultima alteração, ele chamará as regras correspondentes antes, no caso “dependencia1″ e “dependencia2″. Depois de criadas as dependencias aí sim compilará “objetivo”. Bom, esse é o funcionamento básico.

Vamos agora ver nosso script para rodar os testes

Automatizando os testes

O exemplo será composto de três arquivos:

* config_tests – Configura os diretórios de testes
* unit_test.sh – Script para os testes
* Makefile – Para o make

Você precisará ter o Xdialog instalado. Ele já vêm na maioria das distribuição por padrão, mas pode acontecer de não ter vindo, mas ele está em todos os repositórios.
É só fazer apt-get install Xdialog ou yum install Xdialog, etc.

No arquivo “config_tests” apenas indicamos o diretório do framework de teste e os diretórios que o script deve procurar por testes.

config_tests

#!/bin/bash
#	@author Tiago Natel de Moura
#	Arquivo de configuração de Testes Unitários

#      Binário do PHP
PHP_BIN="/opt/php5.3/bin/php"

#	Diretório do Framework de Testes
DIR_FRAMEWORK_TEST=".:/mnt/www/SimpleTest"

#	Filtro para os arquivos de teste
ER_FILES="*Test\.php$"

#	Diretórios onde buscar os testes
#      exemplo para essa estrutura:
#      test/
#           controller/
#           model/
#                 dao/
#           view/
#      Os diretórios estão em relação ao diretório de teste (./)
#      mas se for necessário pode colocar o caminho absoluto.
DIR_MODEL_TESTS="model"
DIR_CONTROLLER_TESTS="controller"
DIR_VIEW_TESTS="view"
DIR_DAO_TESTS="model/dao"

DIR_ALL_TESTS="$DIR_MODEL_TESTS $DIR_CONTROLLER_TESTS $DIR_VIEW_TESTS $DIR_DAO_TESTS"

Agora o Makefile:

#	Makefile para testes automatizados em PHP
#	@author	Tiago Natel de Moura
#	@date 17/11/2009

#	Script que automatizará os testes
SCRIPT_TEST=unit_test.sh

#	All sempre será chamado quando rodarmos o make sem argumentos
#	$ make
#	Ele chamará a dependencia test-all antes.
all: test-all
	@echo ""
	@echo "Testes rodados com sucesso"

#	Executará todos os testes
test-all:
	@echo "Executando todos os testes"
	@sh $(SCRIPT_TEST) -all

#     .PNONY é utilizado para habilitar as regras virtuais
#     no caso regras que não possuem dependencias
#     é um hack para o nosso propósito.
.PHONY: controller model view dao

controller:
	@echo "Executando os testes nos controllers"
	@sh $(SCRIPT_TEST) -controller

model:
	@echo "Executando os testes nos models"
	@sh $(SCRIPT_TEST) -model

view:
	@echo "Executando os testes na view"
	@sh $(SCRIPT_TEST) -view

dao:
	@echo "Executando os testes no DAO."
	@sh $(SCRIPT_TEST) -dao

E finalmente o script que fará tudo funcionar:

#!/bin/bash
# @author Tiago Natel de Moura
# Inclui o arquivo de configuração dos testes
. ./config_tests

# Arquivo temporário
TMP_FILE=/tmp/tmp_test

dir_tests=( )
files=( )

# Cria um arquivo vazio
echo "" &>$TMP_FILE

tests() {
	# Opções
	case $1 in
	"-controller") 	DIR="$DIR_CONTROLLER_TESTS";;
	"-model") 		DIR="$DIR_MODEL_TESTS";;
	"-dao")			DIR="$DIR_DAO_TESTS";;
	"-all") 		DIR="$DIR_ALL_TESTS";;
	*) echo "Não foi passado nenhum parametro para o script"; exit 1 ;;
	esac

        # Pega os diretórios e coloca no array $dir_tests
	get_dir_tests $DIR
        # Pega os arquivos de teste e coloca no array $files
	get_files_tests

	if [ ${#files[@]} -eq 0 ]
	then
		echo "Nenhum arquivo de testes encontrado !" >>$TMP_FILE
		echo "Só será executado testes em arquivos com formato: *Test.php" &>&>$TMP_FILE
		echo "Exemplos: " >>$TMP_FILE
		echo -e "\tcadastroControllerTest.php" >>$TMP_FILE
		echo -e "\tfactoryTest.php" >>$TMP_FILE
	fi

	(
		for (( i=0; i < $TMP_FILE
				# testa a sintaxe PHP
				echo "____________________________________________________________" >> $TMP_FILE
				if $PHP_BIN -l ${files[$i]} 2>&1>&-
				then
					echo "Syntax: [OK]" >>$TMP_FILE
				else
					echo "Syntax: [FAILED]" >>$TMP_FILE
					exit 1
				fi
				$PHP_BIN -d include_path=$DIR_FRAMEWORK_TEST -f ${files[$i]} >>$TMP_FILE
			else
				error=1
				echo "File \"${files[$i]}\" not found." >>$TMP_FILE
				echo "cancelando testes..." >> $TMP_FILE
				exit 1
			fi
			echo $percent
		done
	) | Xdialog --title "running tests..." --gauge "teststs" 0 0 0

	if [ "$error" = 1 ]
	then
		msg="Houve erros ao rodar os testes."
	else
		msg="Testes rodados com sucesso."
	fi

	for i in `cat $TMP_FILE | egrep "Test cases run" | cut -c 43`
	do
		if [ "$i" -eq 0 ]
		then
			tests="pass"
		else
			tests="fail"
			break
		fi
	done

	Xdialog --rc-file ".dialog-$tests.rc" --title "Result of tests: $msg" --msgbox "`cat $TMP_FILE`" 500x300
}

get_dir_tests() {
	if [ $1 ]
	then
		j=0
		for i in $*
		do
			dir_tests[$j]=$i
			j=$(($j+1))
		done
	else
		echo "[FAILED] Nenhum argumento passado para a função get_dir_tests()"
		return 1
	fi
}

get_files_tests() {
	for i in ${dir_tests[@]}
	do
		if test "${i:0:1}" = "/"
		then
			i="`pwd`/$i"
		fi

		if test -d "$i";
		then
			j=0
			for t in `ls -1 $i | egrep $ER_FILES`
			do
				files[$j]="$i/$t"
				j=$(($j + 1))
			done
		else
			echo "[FAILED] O diretório '$i' não foi encontrado"
			exit 1
		fi
	done
}

tests $1

rm -rf "$TMP_FILE"

Ah, eu esqueci de falar mais este script vai gerar uma caixa de diálogo verde se o script passar e vermelha caso algum dos testes falhem. Para que as cores funcionem você vai precisar colocar no mesmo diretório do script esses dois arquivos abaixo:

.dialog-fail.rc

style 'red_background' {
                bg[NORMAL] = { 0.8, 0.0, 0.0 }
                fg[NORMAL] = { 1.0, 1.0, 1.0 }
        }
        widget '*' style 'red_background'

.dialog-pass.rc

style 'green_background' {
                bg[NORMAL] = { 0.0, 0.6, 0.4 }
                fg[NORMAL] = { 1.0, 1.0, 1.0 }
        }
        widget '*' style 'green_background'

Pronto, voces podem baixar esse exemplo aqui. Esse é um exemplo simples, você pode ir adicionando funcionalidades conforme o seu projeto necessitar.

Agora de dentro do VIM podemos chamar o script com o comando :make e no Kate apertando ALT+R.
Podemos fazer:

:make controller
Para rodar os testes dos controllers ou
:make model
para os testes no model, e assim por diante.

O Resultado Final

Testes passando:

Testes falhando:

** Um detalhe: Esse script é só um exemplo, portanto ele funciona perfeitamente com o SimpleTest mas se você usar o PHPUnit, por exemplo, terá que alterar a linha 75 do arquivo unit_test.sh.

O script automaticamente ajusta o diretório do framework no include_path do php.ini.

É isso aí, qualquer dúvida é só perguntar.

Até mais !

Na minha opinião a estrutura de diretórios não deve simplesmente fornecer um padrão para seus projetos, mas sim fornecer flexibilidade, escalabilidade e se possivel produtividade. Alguns frameworks lhe garantem alguns benefícios se você seguir algumas convenções que eles impõem. Mas não gosto da maioria destas convenções e acho que nós devemos programar da maneira que mais nos convém.

Existem inúmeras maneiras de você organizar seu projeto, aqui vou falar de alguns fatores que você poderá pensar na hora de definir sua estrutura de diretórios (independente se usar framework ou não), mas óbvio que isso não significa que é a mais adequada para você ou sua aplicação corrente.

O que será falado vale para qualquer projeto que utilize do padrão MVC. Você terá que adaptar conforme seu framework exigir. Se você não utiliza framework mas programa segundo o padrão MVC esse artigo poderá lhe ajudar.

Estrutura básica

Uma aplicação MVC é formada basicamente de controllers, models, views, arquivos de configuração e bibliotecas internas/externas.

Óbviamente, separamos os controllers, models e view em seus respectivos diretórios. Esses três diretórios que formam o MVC constituem o principal da sua aplicação e por isso, a maioria dos frameworks costumam inserí-los dentro de um diretório chamado “applications” ou “apps” ou simplesmente “app”. Dentro de app/ estará toda a lógica da sua aplicação.
Mas uma aplicação também necessita de arquivos de configuração.
Em projetos pequenos talvez nem necessite de um diretório específico para arquivos de configuração, mas em médios/grandes e/ou em aplicações que sofrem constantes upgrades esses arquivos podem ser numerosos e precisam de um diretório específico. Alguns frameworks chamam esse diretório de “Etc” outros de “config”.
Depois vem as bibliotecas ou classes que compõe o sistema. Há um consenso de colocá-las dentro de um diretório chamado “lib/” ou “libs/”.
Essa estrutura básica ficaria assim:

project/
    app/
        controller/
        model/
        view/
    config/
    libs/

Para aplicações em produção por segurança, não é recomendado que seja possivel o acesso pela URL aos arquivos que compõe a lógica e configuração da aplicação. Por isso costumá-se deixar todos os arquivos do projeto fora do DocumentRoot exceto os arquivos de apresentação (css+xhtml+img) e um arquivo que lerá a requisição do usuário (costuma ser um arquivo index.php para o frontend e outro para o backend). Esses arquivos, que são visiveis, também necessitam de um diretório. Não há padrão nenhum nos frameworks PHP para o nome deste diretório, alguns o chamam “public/”, outros “web” ou “webroot”. Eu costumo nomeá-lo “public/” ou “www/”.
O próximo diretório importante é o dos testes unitários, que costuma ser chamado “tests/”.
Também há outros diretórios facultativos para informação temporária (“tmp/”) como “cache”, “logs”, etc, que não serão comentados. Você também pode criar um diretório “scripts/” ou como desejar para armazenar seus scripts.
A estrutura básica está assim:

project/
    app/
        controller/
        model/
        view/
    config/
    libs/
    public/
        index.php
    tests/

Bibliotecas/Frameworks num diretório único

Uma coisa que demorei um pouco a aprender foi desacoplar as classes do projeto de uma maneira a poder utilizá-las em outros projetos similares. Por exemplo, por que vamos ter um “symfony” dentro de cada projeto de um mesmo sistema? Podemos ter apenas um diretório contendo as classes do symfony e todos os seus projetos que o utilizem podem buscá-lo no mesmo lugar.
1° alternativa:
Por exemplo, antes tinhamos assim:

projects/
    blog1/
        app/
            controller/
            model/
            view/
        config/
        libs/
            Vendor/
                Sf/
        public/
            index.php
        tests/
    blog2
        app/
            controller/
            model/
            view/
        config/
        libs/
            Vendor/
                Sf/
        public/
            index.php
        tests/

Mas podemos reduzir o número de arquivos do servidor e facilitar upgrades mantendo apenas um diretório real com seu framework, usando Link Simbólico (usuários Windows não podem desfrutar de mais esse recurso) podemos referenciar o framework a partir de nossos projetos, ficando assim:

// Diretório com o Symfony
/home/projects/libs/Vendor/Sf/

projects/
    blog1/
        app/
            controller/
            model/
            view/
        config/
        libs/
            Sf/  --> /home/projects/libs/Vendor/Sf
        public/
            index.php
        tests/
    blog2
        app/
            controller/
            model/
            view/
        config/
        libs/
            Sf/ --> /home/projects/libs/Vendor/Sf
        public/
            index.php
        tests/

O bom dessa configuração é que tudo vai funcionar como se realmente existisse as classes do symfony dentro de projects/blogX/libs/Vendor/Sf. O ruim é que, se o framework necessita de uma configuração específica de diretórios para funcionar e ele utilizar, por exemplo, a constante __FILE__ para se encontrar no seu projeto, esta constante vai apontar para /home/projects/libs/Vendor/Sf e não para o diretório virtual que você criou para ele. Nos frameworks mais comuns isso não é problema, pois eles até recomendam essa configuração.

2° alternativa:
Pode-se também apenas acrescentar o diretório do seu framework ou conjunto de classes no PATH do sistema, assim sendo visualizado por todas as aplicações.
Pode se fazer isso diretamente na aplicação com php:

<?php
// Diretório do Simfony
$path_sf = '/home/projects/libs/Vendor/Sf';
// Pega o PATH atual e adiciona o caminho do symfony
$path = get_include_path() . PATH_SEPARATOR .
           str_replace('/', DIRECTORY_SEPARATOR, $path_sf);
// Ajusta o PATH
set_include_path($path);

ou no .htaccess:

php_value include_path ".:/home/projects/libs/Vendor/Sf"

e ainda no php.ini com include_path=”.:/home/projects/libs/Vendor/Sf”

Mas isto vale não somente para o seu framework, uma coisa importante que deveríamos sempre nos preocupar é de desenvolver um código bem desacoplado, com classes desacopladas, programando mais com interfaces. Desta forma podemos utilizar essas classes noutros projetos e, se você tiver várias aplicações no mesmo servidor, poderá buscar essas suas classes todas no mesmo diretório. Isso ajuda muito para organização e manutenção do código.
Por exemplo, imagina que você tenha criado uma boa classe de envio de email, e ela está trabalhando tão bem que você utiliza ela em outros projetos também. Daí depois de algum tempo, você nota que ela poderia ser refatorada num determinado método. O que fazer? Refatorar esta classe em cada projeto?
Quando trabalhamos localmente ou no ambiente de desenvolvimento, é aconselhável manter a prática de programar para interfaces. Quem desenvolve orientado à testes sabe da importância de se criar um sistema desacoplado.
Eu costumo chamar essas minhas classes bem desacopladas de universais e colocá-las num diretório “universe”.
Poderia ficar assim:

// Diretório com seu Framework
/home/projects/libs/Vendor/MyFramework/
// Diretório com suas classes universais
/home/projects/libs/universe
projects/
    blog1/
        app/
            controller/
            model/
            view/
        config/
        libs/
            Sf/  --> /home/projects/libs/Vendor/Sf
            universe/   --> /home/projects/libs/universe/
        public/
            index.php
        tests/
    blog2
        app/
            controller/
            model/
            view/
        config/
        libs/
            Sf/ --> /home/projects/libs/Sf
            universe/  --> /home/projects/libs/universe/
        public/
            index.php
        tests/

Nestas classes no diretório /libs/universe/ você pode utilizar um controle de versão separado, que poderá ser mantido por todos os desenvolvedores, criando branches quando necessário alguma funcionalidade a mais.

Aplicação Simples

Para uma aplicação simples, que não terá um longo histórico de modificações e/ou upgrades, vale mais a pena investir em uma estrutura simples. Como as que vimos anteriormente.

Aplicações maiores

Para projetos maiores ou que necessitarão de upgrades e/ou adição de plugins ou funcionalidades é uma boa separar os controllers em módulos.
Isso facilitará a inclusão de novas funcionalidades num projeto já um pouco grande, primeiro porque o deixará muito mais organizado e depois que evitará colisão de nomes de controllers entre os módulos.
Veja esse exemplo:

// Diretório com seu Framework
/home/projects/libs/Vendor/MyFramework/
// Diretório com suas classes universais
/home/projects/libs/universe
projects/
    blog/
        app/
            modules/
                moduleA/
                    controller/
                    model/
                    view
                moduleB/
                    controller/
                    model/
                    view/
        config/
        libs/
            Sf/  --> /home/projects/libs/Vendor/Sf
            universe/   --> /home/projects/libs/universe/
        public/
            index.php
        tests/

É isso aí, espero que tenha ajudado de alguma forma a quem está começando a desenvolver com MVC. Mas saiba que para cada desenvolvedor e/ou projeto existe uma estrutura de diretórios melhor. Você deve escolher aquela que se sente melhor ou têm mais produtividade.

Até a próxima.

Se voce usa o linux é muito fácil instalar, pois o opencv já vêm na maioria dos repositórios das distribuições. Voce vai precisar também do ffmpeg

Archlinux:
# pacman -Sy ffmpeg opencv

Debian’s like:
# apt-get install ffmpeg opencv

Fedora:
# yum install ffmpeg opencv

Como eu não tenho muita sorte, a instalação pelo repositório no meu archlinux não funciona com a minha webcam, portanto eu sempre preciso instalar a partir dos fontes. Você pode pegar os tar-ball aqui:
OPENCV
FFMPEG

Bom vamos lá então, vou partir do pressuposto que esteja estudando a teoria sobre visão computacional, do contrário pegará o bonde andando. Se não sabe nada de visão recomendo uma apostila ou um livro.
apostila do projeto Harpia
e veja a referencia da própria biblioteca que vêm com o fonte. Ache com o comando:
$ find /usr | grep opencv/doc
No meu caso o caminho é /usr/share/opencv/doc

Aqui o código final:

/**
 * @author Tiago Natel de Moura
 * @date 31/10/2009
 */

#include <stdio.h>
#include <stdlib.h>

/**
 * inclui as bibliotecas
 * Voce pode colocar somente:
 * #include <cv.h>
 * #include <highgui.h>
 * Mas aí terá que adicionar o caminho da
 * instalação do opencv no path.
 */
#include <opencv/cv.h>
#include <opencv/highgui.h>
#include <unistd.h> // para o getopt()

/**
 * Protótipos
 */
void help(int, char* []);
void negative();
IplImage* negativeImage(IplImage* img);
void logarithm();
IplImage* logarithmImage(IplImage* img, int c);

int optflag = 0;

int main(int argc, char* argv[])
{
    int opcao;
    static char opcoes[] = "nl";
    int opterr = 0;

    if(argc = 0 )
            break;
    }

    cvDestroyWindow("capture");
}

/**
 * Operação: Negativa
 *
 * Inverte-se a intensidade luminosa de cada pixel da imagem.
 * Expressão::
 *
 *
 * Uma imagem f(x,y,i), que possui uma faixa de
 * cores variando de [0,L-1], a negativa é dada por:
 * 		g(x,y,i) = (L-1) - f(x,y,i)
 *
 * 		Onde:
 *  			f(x,y,i) 	é a imagem de entrada,
 * 				x,y			são as coordenadas do pixel
 * 				i			é o canal
 *
 * @param 	IplImage*		Imagem de entrada
 * @return 	IplImage*		Imagem de saída
 */
IplImage* negativeImage(IplImage* img)
{
    int j,i;
	int temp1, temp2, temp3;

	/**
	 * Pega os valores da imagem de entrada
	 */
	int height 	= img->height;
	int width 	= img->width;
	int step 	= img->widthStep;
	int channels= img->nChannels;
	uchar *data = (uchar*) img->imageData;

    /**
     * Aqui vamos varrer os pixels da imagem.
     * No for externo percorremos a altura e no
     * interno a largura.
     */
	for(i=0; i < height; i++)
	{
		for(j=0; j = 0 )
            break;
   }

   cvDestroyWindow("capture");
}

/**
 * Aplica uma transformação logarítmica à cada ponto de uma imagem.
 * Foi utilizada a seguinte expressão:
 * 			g(x,y,i) = c.Log(1+f(x,y,i))
 */
IplImage* logarithmImage(IplImage* img, int c)
{
	int height 	= img->height;
	int width 	= img->width;
	int step 	= img->widthStep;
	int channels= img->nChannels;
	uchar* data = (uchar*) img->imageData;
	int i,j;

	for(i=0; i < height; i++)
	{
		for(j=0; j < width;j++)
		{
            /**
             * Aplicamos a fórmula
             */
			data[i*step + j*channels] 	= c*log(1 + data[i*step + j*channels]);
			data[i*step + j*channels+1] = c*log(1 + data[i*step + j*channels+1]);
			data[i*step + j*channels+2] = c*log(1 + data[i*step + j*channels+2]);
		}
	}
	return img;
}

Bom, o código está comentado. Para uma boa compreensão recomendo que veja na documentação a estrutura IplImage, se ainda não estiver claro pode perguntar.
Compile com:
$ gcc -o exemplo exemplo.c -lhighgui
se não encontrar a biblioteca use:
$ gcc -o exemplo exemplo.c -lhighgui -I/caminho/onde/compilou/sua/biblioteca

Esse foi só um examplo simples, nos próximos posts quero mostrar algumas coisas mais avançadas. Se você ainda não sabe o que se pode fazer com essa biblioteca veja um dos videos abaixo:

Real Time pixel based Motion Detector – OPENCV

Controlando o mouse a distancia. Estilo Minority Report

Face Detection:

http://www.youtube.com/watch?v=V7UdYzCMKvw&feature=related

Eye Tracking

Face based Authentication

Isso são só alguns exemplos. É uma área da computação que ainda está começando mais com certeza vai revolucionar a maneira como o homem interage com o computador. Será no estilo Spielberg.

Até a próxima.

Uma pequena introdução

RC4 é um algoritmo de criptografia de fluxo muito conhecido e respeitado. Foi desenvolvido por Ron Rivest para a empresa RSA Data Security, portanto é privado, mas em 1994 foi postado anonimamente uma versão do algoritmo compativel com o original. Esta versão é conhecida como ARCFOUR ou ARC4 (Alleged RC4).

Você quer saber quais protocolos utilizam RC4?

• Secure Socket Layers (SSL/HTTPS)
• WEP
• WPA
• BitTorrent
• Microsoft Point to Point
• Secure Shell
• etc

Bom antes de ver o code tem um pré-requisito:

Xor Encription Algorithm

A criptografia moderna é dividida basicamente em criptografia simétrica e assimétrica. RC4 é um algoritmo de criptografia simétrico. Os algoritmos simétricos podem ser divididos em algoritmos de blocos e algoritmos de fluxo.
Nos algoritmos simétricos de bloco um tamanho fixo deve ser cifrado de cada vez. Por exemplo, se o algoritmo cifra blocos de 128 bits, somente ocorrerá a cifragem se a mensagem tiver exatamente este tamanho. Ele é mais usado em transações em que os pacotes possuem tamanho fixo. Eles podem ser usados em quaisquer outras aplicações também, mas para cifrar mensagens menores que o tamanho do bloco ele necessita completar a mensagem com um cabeçalho, também chamado de padding.

Os algoritmos de fluxo podem cifrar a mensagem bit-a-bit não importando assim o tamanho da mensagem. O RC4 é um algoritmo simétrico de fluxo, então vamos entender um pouco esse funcionamento.
Num algoritmo de fluxo, os bits de uma mensagem em texto plano são combinados com simples operações de Xor contra uma cadeia de bits pseudo-aleatórios (pseudorandômicos), também chamados keystream.
O Xor está no centro da maioria dos algoritmos modernos, ele sozinho é um tipo de criptografia. Vamos lembrar como funcionam os operadores lógicos AND, OR, NOT e XOR:

& (AND)
Os bits que estão ativos tanto em $a quanto em $b são ativados.

01000 & 00100 = 00000
01000 & 00000 = 00000
10111 & 01010 = 00010
11111 & 11001 = 11001

| (OR)
Os bits que estão ativos em $a ou em $b são ativados.

01000 | 00100 = 01100
01000 | 01100 = 01100
10111 | 01010 = 11111
11111 | 11001 = 11111

~ (NOT)
Os bits que estão ativos em $a não são ativados, e vice-versa.

~ 01000 = 10111
~ 10111 = 01000
~ 11111 = 00000
~ 11001 = 00110

^ (xor)
Os bits que estão ativos em $a ou em $b, mas não em ambos, são ativados.

01000 ^ 10111 = 11111
11111 ^ 01000 = 10111
10111 ^ 01010 = 11101
00010 ^ 00000 = 00010
00010 ^ 11111 = 11101

Bom, atentem ao xor, também chamado de “ou exclusivo”, ele possui as propriedades de comutatividade ,associatividade e principalmente reversividade.
Comutatividade:
A ^ B = B ^ A
Associatividade:
A ^ (B ^ C) = (A ^ B) ^ C
Reversividade:
(A ^ B) ^ A = B

A característica mais importante do Xor é a reversibilidade. Se fizermos um xor entre A e B, resultando C e depois apĺicarmos um xor entre C e A retornará B.
Exemplo simples do uso:

chave = segredo
Mensagem = hello
Em ASCII decimal fica:
chave = (115)(101)(103)(114)(101)(100)(111)
mensagem = (104)(101)(108)(108)(111)
Em Binário fica:
chave = 1110011 1100101 1100111 1110010 1100101 1100100 1101111
mensagem = 1101000 1100101 1101100 1101100 1101111

Agora vamos cifrar cada caracter da mensagem com o respectivo da chave, isto pode ser feito de qualquer maneira lógica, mas vamos fazer um a um mesmo:

mensagem ==>        criptografia        ==>   cifrado =>  ASCII
   h          =>    1101000 ^ 1110011  ==>  0011011 = [ESCAPE]
   e          =>    1100101 ^ 1100101  ==>  0000000 = [NULL]
   l          =>    1101100 ^ 1100111  ==>  0001011 = [VERTICAL TAB]
   l          =>    1101100 ^ 1110010  ==>  0011110 = [RECORD SEP]
   o          =>    1101111 ^ 1100101  ==>  0001010 = [LINE FEED]

A mensagem hello foi cifrada e (nesse caso) não é nem visivel, pois os equivalentes em ASCII são caracteres de controle ou vazios. Para descriptografa-la basta fazer o mesmo processo, iterar os caracteres da mensagem cifrada novamente operando em xor com a chave. Criptografia de xor simples como essa não é segura, mas se bem implementada pode se tornar muito dificil de ser quebrada. Se a mesma chave for usada em várias mensagens é possivel quebrá-la com análise de frequencia. Vale muito a pena dar uma olhada nisso.
Mas se a chave for randomica e de tamanho igual ou maior que a mensagem a criptografia de xor é muito segura, podendo até mesmo ser INQUEBRÁVEL (pelo menos teóricamente, rsrs).
Mas como codar isso? Muito simples:

/**
  * Linguagem: C
  * Escolha uma chave super aleatória, como
  * essa minha oO
  */
unsigned char key[] = {
	0x45,0x73,0x73,0x61,0x20,
	0xe9,0x20,0x61,0x20,0x6d,
	0x69,0x6e,0x68,0x61,0x20,
	0x63,0x68,0x61,0x76,0x65,
	0x20,0x73,0x75,0x70,0x65,
	0x72,0x20,0x73,0x65,0x63,
	0x72,0x65,0x74,0x61,0x20,
	0x3a,0x29, 0x00
};

/**
 * E agora o grande algorítitmo
 */
char *encryptDecrypt(char input[], char *output)
{
	int i;
	char *c = output;

	for(i = 0;i<strlen(input);i++)
	{
		*c++ = (input[i] ^ key[i]);
	}
	*c++ = '';

	return output;
}

Note que, como falei, o Xor possui a propriedade de reversibilidade, portanto podemos usar a mesma função para encriptar e desencriptar.

Mas esse foi o esquenta, agora vamos ver o RC4 de perto.

RC4

RC4 ou ARC4 utiliza o modelo de Vernam Cipher. Esse modelo é hoje caracterizado como um stream cipher, criptografia de fluxo. Este modelo é baseado numa chave simétrica, conhecida por ambos os lados do canal de comunicação. Essa chave é passada para um gerador de números pseudo aleatório (PRNG) que irá gerar uma outra chave que posteriormente irá cifrar a mensagem.

O algoritmo do RC4 pode ser dividido em duas partes:
Key-Scheduling Algorithm – KSA e
Pseudo-Random generation algorithm – PRGA

KSA

Essa parte do algoritmo, como todos os algoritmos de criptografia, é muito fácil rsrs, somente inicializamos um array de estado S e realizamos diversas permutações baseando-se no array da chave secreta.
Que permutação é essa?
Vamos por partes, primeiro prenchemos um array unidimensional S de tamanho 256 com quaisquer valores. Oficialmente ele é preenchido de 0..255.

/**
 * Language: PHP
 */
$S = array();
for($i=0;$i<256;i++)
    $S[$i] = $i;

Tendo uma chave $key prenchemos um outro array $K com essa chave:

$key = array(
    0x01, 0x23, 0x45, 0x67, 0x89, 0xAB, 0xCD, 0xEF
);

$K = array();
for($i=0;$i<256;$i++)
      $K[$i] = ($key[$i % count($key)]);

Reparem que a atribuição é modular, isso para preencher o array K com a chave mesmo se ela for menor que 256, evitando o estouro do buffer da variavel $key.
Agora a permutação inicial, o importante do KSA.
Os passos do algoritmo são os seguintes:
1 – Inicializa uma variável ($j) com 0;
2 – Inicia-se um loop for de 0 à 255;
3 – Para cada iteração do loop somamos à $j seu próprio valor.
4 – Para cada iteração do loop somamos à $j o valor do indice atual de S, ou seja $S[$i].
5 – Para cada iteração do loop somamos à $j o valor do indice atual de K, ou seja $K[$i].
6 – Aplicamos uma operação modular 256 à $j. [ $j (mod 256) ]
7 – Invertemos os valores de $S[$i] e $S[$j].

Pronto. Esse é o KSA do RC4. Serve somente para embaralhar o array de estado S com a chave K. Este algoritmo como demonstrado acima não é um padrão e diversas outras criptografias o implementam diferente realizando funções diferentes. Por exemplo, em TEA o KSA simplesmente divide a chave de 128 bits em quatro arrays de 32 bits, em DES ele divide uma chave de 56 em duas de 28 bits, etc.
Vamos ao código:

$j = 0;
for($i=0; $i<256; $i++)
{
     $j = ($j + $S[$i] + $K[$i]) % 256;
     swap($S[$i], $S[$j]);
}

É só isso mesmo…
Note que os passos 3,4,5 e 6 foram feitos na mesma linha. Na última linha do for chamamos a função swap. E mais uma vez o Xor, a função swap também é um algoritmo, mais conhecido como Xor Swap. Ele simplesmente consegue trocar os valores de duas variáveis sem necessitar de armazenamento temporário. A função é assim:

function swap(&$n1, &$n2)
{
      $n1 = $n1 ^ $n2;
      $n2 = $n1 ^ $n2;
      $n1 = $n1 ^ $n2;
}

/**
  * Se não fosse o método acima, teríamos que fazer algo como:
  * $temp = $n1;
  * $n1 = $n2;
  * $n2 = $temp;
  */

Pronto. Esse foi o KSA.

PRGA

O gerador de números pseudo aleatórios é um algoritmo que irá iterar no array de estado S para gerar uma sequencia de números aproximadamente independente um do outro. O algoritmo do PRGA pode também trabalhar conjuntamente com a cifragem, ele permutando os valores e gerando o byte que será usado na cifragem (com Xor) na mensagem. Após todas as iterações teremos como saída um stream de bytes aleatórios de mesmo tamanho da mensagem que queremos cifrar (isso pode variar).
Algorítmo:
1 – Inicializamos duas varíaveis ($i e $j, por exemplo) com 0.
2 – Iniciamos o loop de cifragem da mensagem.
3 – Incrementamos em 1 o valor de $i e aplicamos o módulo 256.
4 – Incrementamos o valor de $j com $S[$i] e aplicamos módulo 256.
5 – Invertemos os valores de $S[$i] e $S[$j].
6 – Armazenamos o valor de $S[($S[$i] + $S[$j]) % 256].

O passo 6 do algoritmo é o byte que será usado na cifragem. Vamos codar:

$i = 0;
$j = 0;
$output = array();
for($t = 0; $t<count($message);$t++)
{
	$i = ($i + 1) % 256;
	$j = ($j + $S[$i]) % 256;
	swap($S[$i], $S[$j]);
	$output[$t] = $S[($S[$i] + $S[$j]) % 256];
}

Pronto, esse é o PRGA.

Cifrando a mensagem

Assim:

$message = "Hello World";
$cipher = array();
for($i=0;$i<strlen($message);$i++)
     $msg[$i] = ord($message{$i});
for($i=0;$i<count($msg);$i++)
     $cipher[$i] = $output[$i] ^ $msg[$i];

Fim. Algoritmo criado com sucesso. hehe
Mas como dividi bem pra explicar tem muitas partes que poderiam ser otimizadas, por isso estou disponibilizando uma classe pronta para uso:

class Orion_RC4
{
	/**
	 * Recomenda-se uma chave de pelo menos 128 bits
	 * RC4 com chave menor que 40 bits são facilmente quebráveis.
	 * @var string 	- Chave usada para cifrar a mensagem
	 */
	private $_key = array();

	/**
	 * Array de estado // permutações
	 * @var array 	- Array de permutações
	 */
	private $S = array();

	/**
	 * Array com a chave de permutação
	 * @var array 	- Chave
	 */
	private $K = array();

	public function __construct($key = false)
	{
		if(!empty($key))
			$this->setKey($key);
	}

	/**
	 * Ajusta a chave como uma string
	 * $rc4->setKey('MinhaChaveSuperSecretaaaaaaaaa');
	 * @param $key 	string
	 * @return object
	 */
	public function setKey($key = '')
	{
		if(strlen($key) <= 6)
			throw new Exception("The key length is too small");

		$this->_key = array();
		for($i=0;$i<strlen($key);$i++)
			$this->_key[] = ord($key{$i});
		return $this;
	}

	/**
	 * Ajusta a chave a partir de um array hexadecimal
	 * $rc4->setKeyHex(array(
	 *		0x75, 0x85, 0x65, 0x23, 0x25,
	 *		0x12, 0x14, 0x99, 0x55, x045
	 * ));
	 * @param $key 	array
	 * @return object
	 */
	public function setKeyHex(array $key)
	{
		$this->_key = array();
		foreach($key as $k)
			$this->_key[] = $k;
		return $this;
	}

	/**
	 * O algoritmo para encriptar e desencriptar é o mesmo
	 * mas é muito chato chamar o método encrypt para
	 * desencriptar algo né?
	 * Por isso tem um alias no método Orion_RC4::desencrypt()
	 * @param $message	string
	 * @param $key	string
	 */
	public function encrypt($message, $key = false)
	{
		$msg = array();
		if(is_string($message))
			for($i=0;$i<strlen($message);$i++)
				$msg[$i] = ord($message{$i});
		elseif(is_array($message))
			$msg = $message;
		else
			throw new Exception("Invalid type of message, should be a string");

		return implode('', array_map('chr', $this->rawEncrypt($msg, $key)));
	}

        public function desencrypt($message, $key = false)
	{
		$this->encrypt($message, $key);
	}

	/**
	 * Encripta a mensagem com o algoritmo ARCFOUR (RC4)
	 * Não há restrições quanto a base dos valores do array
	 * $message, pois ocorrerá uma permutação cíclica.
	 * Se os valores do array $message forem caracteres, será
	 * utilizado a representação numérica deles (ASCII).
	 * @param 	$message	array			- Mensagem de entrada
	 * @param 	$key 		string | array	- Key
	 * @return 	array
	 */
	public function rawEncrypt(array $message, $key = false)
	{
		if(!empty($key))
			if(is_string($key))
				$this->setKey($key);
			elseif(is_array($key))
				$this->setKeyHex($key);
			else
				throw new Exception("Invalid Type of key.");

		$this->init();

		$i = 0;
		$j = 0;
		$output = array();
		for($t = 0; $t<count($message);$t++)
		{
			$i = ($i + 1) % 256;
			$j = ($j + $this->S[$i]) % 256;
			self::swap($this->S[$i], $this->S[$j]);
			$output[$t] = $this->S[($this->S[$i] + $this->S[$j]) % 256] ^ $message[$t];
		}

		return $output;
	}

	/**
	 * Inicializa o algoritmo
	 * Key Scheduling Algorithm - KSA
	 * @param void
	 * @return void
	 */
	private function init()
	{
		/**
		 * KSA
		 * Inicializa o array a ser permutado
		 */
		$this->S = array(
	0,  1,  2,  3,  4,  5,  6,  7,  8,  9, 10, 11, 12, 13, 14, 15,
	16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31,
	32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47,
	48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62, 63,
	64, 65, 66, 67, 68, 69, 70, 71, 72, 73, 74, 75, 76, 77, 78, 79,
	80, 81, 82, 83, 84, 85, 86, 87, 88, 89, 90, 91, 92, 93, 94, 95,
	96, 97, 98, 99,100,101,102,103,104,105,106,107,108,109,110,111,
	112,113,114,115,116,117,118,119,120,121,122,123,124,125,126,127,
	128,129,130,131,132,133,134,135,136,137,138,139,140,141,142,143,
	144,145,146,147,148,149,150,151,152,153,154,155,156,157,158,159,
	160,161,162,163,164,165,166,167,168,169,170,171,172,173,174,175,
	176,177,178,179,180,181,182,183,184,185,186,187,188,189,190,191,
	192,193,194,195,196,197,198,199,200,201,202,203,204,205,206,207,
	208,209,210,211,212,213,214,215,216,217,218,219,220,221,222,223,
	224,225,226,227,228,229,230,231,232,233,234,235,236,237,238,239,
	240,241,242,243,244,245,246,247,248,249,250,251,252,253,254,255
	);
		if(count($this->_key) == 0)
                throw new Exception("Deve ajustar a chave antes de encriptar.");
		for($i=0;$i < 256;$i++)
			/**
			 * Preenche o array K com a chave
			 */
			$this->K[$i] = $this->_key[$i % count($this->_key)];

		/**
		 * Permutação inicial
		 */
		$j = 0;
		for($i=0; $i<256; $i++)
		{
			$j = ($j + $this->S[$i] + $this->K[$i]) % 256;
			self::swap($this->S[$i], $this->S[$j]);
		}
	}

	/**
	 * Xor Swap. Trocar valores de duas varíaveis sem usar
	 * armazenamento temporário.
	 */
	public static function swap(&$n1, &$n2)
	{
		if(!is_int($n1) && !is_int($n2))
			throw new Exception('ERROR: invalid type.');
		$n1 = $n1 ^ $n2;
		$n2 = $n1 ^ $n2;
		$n1 = $n1 ^ $n2;

		return;
	}
}

Para testar simplesmente faça:

$rc4 = new Orion_RC4("S14YYeQ1FA732hEe3uT31C4fSiXHrQ98");
$cipher = $rc4->encrypt("Orion Framework");
print $cipher."<br>";
print $rc4->desencrypt($cipher);
/**
 * Isso irá imprimir
 * x¶¼%-º¥ˆ¼$Xž­
 * Orion Framework
 */

Bom é isso, você pode copiar a classe aqui ou aqui.
O RC4 está no coração dos algoritmos mais modernos de criptografia e por ser bem simples é uma ótima forma de estudar essa área da computação que as vezes nos parece tão obscura.

Até mais.

ObjectModels

Isto não tem relaçao com os padrões de Modelos de Objetos, como, Java Object Model ou Document Object Model, trata-se de uma nomenclatura do framework Orion.

Introdução

Quando se utiliza a técnica de desenvolvimento ORM (Mapeamento Objeto-Relacional), cada tabela do banco de dados é representada por uma classe (Model) e os campos da tabela são objetos. Assim, o banco de dados, juntamente com todo o projeto, possuem o paradigma orientado à objetos. Os objetos do banco de dados, portanto, possuem todas as caracteristicas dos objetos nativos da linguagem.

ObjectModels para o Orion Framework são objetos abstratos, que podem ser herdados por muitos outros objetos mais específicos e reduzindo muito a programação e manutenção dos Models.

Detalhes

Imagine que precisamos criar um simples banco de dados para uma escola. Esse banco de dados será formado, entre outras, pelas tabelas “Student” e “Teacher”.

Veja a estrutura das tabelas Student e Teacher: O Orion utiliza o Doctrine ORM, esse ORM utiliza arquivos YAML para geração do schema do banco de dados :

# Models/Student.php
Student:
  columns:
    name:
      type: string(255)
      notnull: true
   nr_register:
      type: string(14)
      notnull: true
   course_id:
      type: integer
      notnull: true
    birth:
      type: date
      notnull: true
    address:
      type: string(255)
      notnull: true
    district:
      type: string(255)
    nr:
      type: integer
    city_id:
      type: integer
    state_id:
      type: integer
    country_id:
      type: integer

# Models/Teacher.php
Teacher:
  columns:
    name:
      type: string(255)
      notnull: true
    birth:
      type: date
      notnull: true
    language_id:
      type: integer
    address:
      type: string(255)
      notnull: true
    district:
      type: string(255)
      notnull: true
    nr:
      type: integer
    city_id:
      type: integer
    state_id:
      type: integer
    country_id:
      type: integer

Como estamos falando de objetos, podemos ver que o objeto “Student” e o objeto “Teacher” possuem muitas semelhanças e é nessas semelhanças que se baseia esse recurso do Orion. Objetos são estruturas hierárquicas, que respeitam propriedades como Herança, Encapsulamento, etc. Esta hierárquia pode ser vista nas tabelas acima, onde as propriedades (campos) “name, birth, address, district, nr, city_id, state_id, country_id” são comuns aos dois objetos. Isso mostra que esses dois objetos herdam propriedades de um outro objeto abstrato, que chamaremos de “PersonTemplate”. O sufixo Template é necessário para criar objetos abstratos no Doctrine. Veja as propriedades deste objeto:

# Models/PersonTemplate.php
PersonTemplate:
  columns:
    name:
      type: integer
    birth:
      type: date
    address:
      type: string(255)
    district:
      type: string(255)
    nr:
      type: string(255)
    city_id:
      type: integer
    state_id:
      type: integer
    country_id:
      type: integer

Então os objetos Student e Teacher herdam as propriedades de PersonTemplate. Assim podemos notar uma significativa redução de código:

# Models/Student.php
Student:
  actAs: [PersonTemplate]
  columns:
    nr_register:
      type: string(14)
      notnull: true
    course_id:
      type: integer
      notnull: true
# Models/Teacher.php
Teacher:
  actAs: [PersonTemplate]
  columns:
    language_id:
      type: integer

Pronto. Agora para todos os outros objetos necessários ao projeto, como “Clients”, “Functionary”, etc, podem simplesmente herdam as propriedades do objeto abstrato PersonTemplate para receberem automáticamente as propriedades de uma pessoa.

Quanto mais estruturado estiver o projeto, mais organizado e rápido será o desenvolvimento. Ainda no exemplo anterior, o objeto abstrato PersonTemplate possue as propriedades “address, nr, city_id, state_id, country_id” que também podem estar presentes num outro objeto, “Company” por exemplo, assim, poderíamos abstrair essas propriedades e criar um novo objeto abstrato AddressTemplate.

Assim teríamos:

PersonTemplate:
  actAs: [AddressTemplate]
... _outras propriedades_
Company:
  actAs: [AddressTemplate]
... _outras propriedades_

O Orion Framework vai possuir muitos objetos abstratos para os mais variados projetos, bastando apenas extende-los em seus models.

Até mais.

A quem interessar pode fazer o download aqui.

Até mais.