FreeFramePHP

January 18, 2011

Titulo do Projecto: FreeFramePHP

Última Versão: 1.0.0

Site Oficial: Ex http://taviroquai.sytes.net/Blog/web/

Licença: BSD

Líder do Projecto: taviroquai

Membros Actuais do Projecto: taviroquai

Descrição do Projecto:

FreeFrame é uma framework leve e minimalista para PHP5

* PHP5: http://php.net/ChangeLog-5.php

* RIA: PHP Framework para RIA (Rich Internet Application)

* Mustache para templates - http://mustache.github.com/

* ORM RedBeanPHP (com Legacy) integrada - http://redbeanphp.com/

* Segurança: ACLs - utilizadores, cargos e recursos

* Internacionalização: ficheiros de catalogo para mensagens (.ini),

* Caching: PHP APC ou custom ficheiros de cache

* Plugins

Download:

Dropbox

Dropbox (pacote com demos)

Update (20/01/2011): foram corrigidos alguns problemas e adicionados comentários às classes do core.

As classes Core e Core_Cache são agora estaticas.

O Core_Loader desapareceu para dentro do Core. Agora carrega-se outro component com

[s]$component [/s]= Core::load('HelloWorld');

sendo o Core::load() um proxy para instanciar componentes.

Update (23/01/2011):

Adicionados 3 wrappers para facilitar a API:

1. Pode-se obter a instancia de outro componente com $this->load($nomeComponente, $argumentos), um wrapper do Core::load(). Uma semelhança com o CodeIgniter. Bem simples

2. Pode-se obter logo o output de outro componente com $this->loadOutput($nomeComponente', $argumentos), um wrapper do anterior.

3. Pode-se obter a string da localização através de $this->translate($key), sendo $key a chave da string no ficheiro de localização .ini

Update (26/01/2011):

No demo do blog, adicionado um controlador .js (opcional) que demostra a facilidade com que uma aplicação pode funcionar sem javascript, ou com javascript, bastando para isso incluir apenas uma linha de código no <head>.

Update (30/01/2011):

Foram corrigidas algumas incoerencias a nivel de estética do código nos componentes CRUD da administração.

Adicionada a possibilidade de chegar directamente a um método público do componente. Exemplo: index.php?c=BlogDemo&m=viewLink

As keys "c" e "m" são configuraveis no ficheiro config.php;

Adicionada a possibilidade de fazer cache por componente;

Adicionada a opção de "saltar" as ACLs; desta forma todos os users têm acesso a todos os componentes (útil para pequenas aplicações que não requerem permissões).

Adicionado o script de instalação: /install/install.php

Adicionado RedBeanPHP Legacy. Agora funciona nas versões php > 5.2. Testei agora num alojamento partilhado.

Update (01/02/2011):

Adicionada pasta /Classes/Models para suportar subclasses do RedBean_SimpleModel chamadas pelo Fuse. Já se pode separar os models dos components.

Adicionado o método Core_Component::loadView() para facilitar o carregamento das views localizadas na pasta relativa "views/". Já se pode separar as views do componente.

Assim, para carregar uma view a partir de um componente basta usar: $this->loadView('nome_do_ficheiro.php').

A pasta para as views também é configurável no config.php.

Exemplo de uso das views:

$doc = $this->loadView('Document.php');
$doc->title	= $this->translate('DocTitle');
$out = $doc->render($this->loadTemplate('document.xhtml'));
$this->setOutput($out);

Update (05/02/2011):

Correcção sobre ACLs: Agora é possivel definir quais os roles condicionados pelas ACLs. Ou seja, se disser que o role admin não é condicionado então não são verificadas as ACLs para este role, embora seja possivel registar as regras e mais tarde tornar estes roles novamente condicionados pelas ACLs. Digamos que é uma camada global antes de verificar as ACLs.

Corrigido os ficheiros de localização .ini. Doble quotes para as string funcionam em todas as versões > 5.2.x

Update (08/02/2011

Refactoring da estrutura de pastas, mais familiar com outras frameworks. Incompativel com demos da versão anterior.

/
     config.php

     application/
          cache/
          classes/
               Controller/
               Model/
               View/
               Plugin/
          data/
          i18/
               en_US/
          templates/

     framework/
          classes/
          install/
          autoload.php
          freeframe.php

     web/
          controllers/
          images/
          js/
          index.php

Update (09/02/2011)

Multiplas bases de dados: agora já é possivel usar mais do que 1 base de dados.

Classe principal FF é singleton. FreeFrame é agora MVC. No entanto é possivel aceder à base de dados e fazer echo usando apenas o controlador... a separação fica ao critério do programador.

Agora é possivel encadeamento de métodos nas views (Method Chaining, Fluent Interfaces). Exemplo:

$template = FF_Template::factory	('PublicHome_Document');
$view       = FF_View::factory		('PublicHome_Document')
->setTemplate	($template)
->setTitle	($this->translate('DocTitle'))
->addScript	(URL . 'js/jquery-1.4.4.min.js')
->addScript	(URL . $this->resource_path . 'js/init.js')
return $view->render();

Update (12/02/2011)

Correções de bugs relacionados com a passagem de "component" para "controller".

Adição de pesquisa no backend dos controladores, pois o numero de controladores vai crescer bastante.

Melhores ACLs: agora um user pode pertencer a mais do que 1 role. Quando na verificação de permissões, se um usar pertencer a 2 ou mais roles, basta que um role tenha o acesso negado para resultar em DENY.

Update (13/02/2011)

Corrigido o nome das tabelas (lowercase) para funcionar tanto no Windows como Linux.

Update (27/02/2011)

Nova classe FF_Request. Permite fazer pedidos http dentro da aplicação. Útil para carregar outras páginas fora da framework.

Update (06/03/2011)

FF_Session: um wrapper para controlar as sessions e ser possivel estender.

FF_Session_RedBean: sessions pela base de dados.

Plugin_DBSession: basta ligar/desligar e usa as sessões por defeito do php ou base de dados.

PluginManager: um CRUD GUI para os plugins, tal como já existia para Locale, Role, User, Controller e ACL.

Um repositório SubVersion aqui: http://taviroquai.sytes.net/opt/svn/FreeFrame/

Correcção de N bugs

Update (11/04/2011)

Correcções para funcionar no PostgreSQL nomeadamente na classe Paginator.

Adicionadas opções para a escolha do nome das tabelas 'user' e 'role' uma vez que estas keywords estão reservadas no PostgreSQL.

melhorias por vir...

January 18, 2011

Também preciso de plugins... já temos plugins mas isto ainda está muito verde... à que melhorar... talvez o softclean me pudesse dar uma ajuda...

Ainda não dei uma olhada ao projecto, mas porquê eu para os plugins?

January 18, 2011

Ainda não dei uma olhada ao projecto, mas porquê eu para os plugins?

Ops... enganei-me... afinal é o scorch que está a frente do projecto SimpleEventsDrivenPHP e é esse tipo de arquitectura que quero meter nos plugins...

Scorch, és tu!

January 18, 2011

Hum, se quiseres podes usar a minha classe à vontade.

Eu ainda estava a pensar fazer uma versão 2, vamos ver se o tempo chega.

Se tiveres alguma dúvida, também te posso ajudar, embora agora esteja um pouco apertado de tempo (9º Ano)... 😳

January 18, 2011

Então é daí Mas pois, é o Scorch que lidera esse projecto, eu apenas o comentei e testei, e sugeri um exemplo com plugins.

O Dropbox está a dar 404. No entanto, infelizmente também não devo ter tempo para ajudar nalguma coisa, pois mais dois exames se avizinham....

January 19, 2011

Pois eu tinha mais ou menos a ideia de que 2 dois estavam de alguma forma envolvidos no projecto de PHP eventos mas já não tinha a certeza...

Anyway... já coloquei uma versão mais actual no dropbox. Corrigi uma série de coisas... mas ainda falta muita coisa...

Assim por alto, falta documentação, acabar os eventos para os plugins, excepções, criar um install, etc... etc... e quando isto estiver razoável meto no github...

Ya scorch, amanha vejo a tua classe

Ah! Isto talvez não funcione no windows ... quem testar no win coloque aqui os bugs...

January 19, 2011

Mete o .zip num servidor tipo rapidshare ou assim, não consigo sacar.

January 19, 2011

Adicionei um link em cima para o 4Shared.

January 20, 2011

Acerca dos eventos... actualmente tenho implementado o padrão "observer"... li aqui mais duas formas de fazer isto:

http://stackoverflow.com/questions/4471183/php-event-listener-best-practice-implementation

Talvez podesse implementar o Mediator usando a class do scorch, mas teria que haver alterações ou estender aquela classe... que dizes scorch?

January 20, 2011

Bem, a class é basicamente igual ao Mediator, não sei que alterações seriam necessárias. Btw, a classe foi feita mais com base no Mediator que no Observer.

January 20, 2011

The mediator can then keep track of which listening objects want to receive that event,[...]

Na tua classe posso registar a função que responde aos eventos, mas preciso registar o objecto e a função...

January 20, 2011

Pois, isso está a ser feito na versão 2.0, só que o tempo não é muito para criar algo apresentável.

February 4, 2011

Pips,

Antes de meter isto no github gostava que dessem uma vista de olhos e comentassem quanto ao que gostam ou não gostam desta plataforma.

Muito do código inicial foi re-escrito, mas agora está mais estável...

Alguns pontos chaves que são específicos do FreeFramePHP, embora similar a outras frameworks que há por aí...

1. Os requisitos para correr são os mesmos do RedBeanPHP

2. ORM incluido: RedBeanPHP. Não estou pensando em torná-la flexivel para encaixar outros ORMs... embora sei que isso seria bom para quem usa outros ORM.

3. Arquitectura por Components. Exemplo de um Componente:

<?php

/**
* HelloWorldDemo Component
*
* @author mafonso
*/
class HelloWorldDemo extends Core_Component {

public function  __construct() {
	;
}

/**
 * The default function got by $this->load() when requesting index.php?c=HelloWorldDemo
 *
 * @return string Returns the content generated
 */
public function index() {

	/*
	 * Use setOutput method to set what will be sent out
	 */
	$this->setOutput('<h1>Hello World</h1>');
}

/**
 * Html link for this component
 */
public function viewLink() {
	$html = sprintf('<a href="%s">HelloWorld</a>', URL . $this->uri);
	$this->setOutput($html);
}

}

4. Incluido Classe Mustache para Views e Templates. Exemplo de uso:

$view = 'Document.php';
$template = 'document.xhtml';

$doc = $this->loadView($view);
$doc->title     = $this->translate('DocTitle');
$this->setOutput($doc->render($this->loadTemplate($template)));

5. ACLs incluidas (mas não obrigatŕorias). Ao usar o método load() (proxy para instanciar) para carregar um componente, são verificadas as ACLs na base de dados.

Pode-se ainda passar argumentos (opcional).

$this->load('NomeDoComponente', $args);

6. Cache às páginas geradas. Por exemplo a página inicial do Blog tem este benchmark: 502856 bytes 0.061845 sec

Depois de colocar em cache (usando APC), tem este benchmark: 11060 bytes 0.000484 sec

7. Internacionalização. Para carregar os ficheiros de strings das línguas usa-se $this->loadLocale(). Para obter a string, usa-se $locale->translate():

$locale = $this->loadLocale('zh_CN.ini');
$locale->translate('HelloWorld');

8. jQuery incluido. Mas pronto... pode-se usar outra framework JS.

9. Ficheiro config.php onde se pode configurar quase tudo sem mexer no código ...

Um pequeno resumo da API. Apenas com estes métodos é possivel criar coisas bem simples e outras complexas:

// Sobre componentes
$this->load('NomeComponente'); // Para carregar outro componente (uma instancia)
$this->load('NomeComponente', $args); // Para carregar outro componente e passar um array() de argumentos
$this->args[$key]; // Para aceder aos argumentos passados
$this->loadOutput('NomeComponente'); // Para devolver logo o output por defeito daquele componente

//Agora um pouco de RedBean (ORM)
$carro = R::dispense('Carro'); //inicializa um objecto Carro
$carro->marca = 'Ford'; // Atribui uma propriedade marca
$id = R::store($carro); // Guarda o objecto carro e devolve um ID
$carro = R::load('Carro', $id); // Para carregar um objecto Carro através de um ID
$carro->apita(); // Usando um Model_Carro extends RedBean_SimpleModel pode-se criar métodos pŕoprios do modelo

// Sobre Views, Templates e Output
$view = $this->loadView('NomeClasse'); // Para carregar uma view
$template = $this->loadTempplate('NomeFicheiroHtml'); // Para carregar um ficheiro HTML
$output = $view->render($template); // Para devolver o output gerado pela View
$this->setOutput($output); // Para definir o output do componente actual

echo URL; // Constante que devolve a URL base
echo $this->uri; Devolve a query string para chamar o componente no browser. Exemplo: '?c=NomeComponente'

// e outros setters e getters...

Digam o que gostam e o que não gostam e que podia ser melhorado deste "produto português"

Obrigado.

February 4, 2011

O que não gostam .. Ui

February 4, 2011

Va la yoda, poe la aí o que não gostas... preciso de feedback com fundamento!

February 4, 2011

Não tenho muito a fundamentar, porque não a usei, mas como OOP não gosto, não faz sentido muita da sintaxe nem a forma como as coisas se processam.

February 4, 2011

Ok... vamos por partes...

Acerca da sintaxe, vou tentar explicar o porquê desta sintaxe...

$componente = $this->load('NomeComponente');

faz o mesmo que...

$componente = new NomeComponente();

Acontece que o $this->load() é um proxy para instanciar uma classe.

O mesmo acontece para $this->loadView(), $this->loadTemplate(), $this->loadOutput()...

O CodeIgniter é bastante usado e usa algo semelhante:

$this->load->model('NomeModel'); // Para carregar um model
$this->load->view('NomeView'); // Para carregar a view

Faz-te assim tanta diferença? Até se pode meter igual ao CodeIgniter

Acerca da forma como as coisas se processam... basicamente as outras frameworks usam um "router" para chegar aos controladores, tipo: http://maquina/aplicacao/?/controlador/funcao/

Aqui não é diferente... basta passar a query string index.php?c=NomeComponente&m=Metodo

o que com URL rewrite pode-se obter o mesmo ?/NomeComponente/NomeMetodo/

Portante é bastante similar a outras plataformas já existente... 🤔

Talvez depois de experimentar e perder um pouco de tempo (tal como o tempo necessário para aprender qualquer outra framework) seja mais facil digerir isto

February 4, 2011

CodeIgniter sucks

Acho que fazias bem em investigar melhor as outras frameworks, de modo a perceber o uso de certos conceitos e a ver mais exemplos de OOP.

http://kohanaframework.org/ (a que uso em tudo praticamente)

http://www.yiiframework.com/ (meh)

http://cakephp.org/ (meh)

.. and so on.

February 4, 2011

Não vou correr todas as features de todas as Frameworks... cada uma tem a sua forma de "carregar" as classes/ficheiros mas todas têm que o fazer... o que muda é a API e o consumo de memoria e performance. Se bem que essas frameworks que indicaste são bem mais maduras e têm muitas mais features (por vezes bem pesadas ) o que não se pode usar esse critério para comparar com esta plataforma. Há muitas coisas que se podem adicionar mas também não quero saturar a API. Quero manter isto o mais simples possivel...

Mas podemos comparar pequenos exemplos de funcionamento... por exemplo I18n:

Kohana, I18n é um helper e carrega as mensagens de uma lingua com:

$messages = I18n::load('xx-xx');

Para devolver uma tradução:

$hello = I18n::get('Hello friends, my name is :name');

A Yii, organiza os ficheiros por categorias e carrega uma instancia de um CLocale com:

 $locale = CLocale::getInstance($localeID)

Para traduzir:

Yii::t('Xyz.categoryName', 'message to be translated')

A CakePHP, para usar I18n, é necessário correr um comando na consola.

Para traduzir tem 3 funções... a mais utilizada __():

__('Posts')

Na FreeFramePHP, os componentes carregam por defeito o ficheiro de localização consuante a localização do user (faz todo o sentido). E ainda se pode carregar outras instancias da classe Core_Locale com:

$locale = $this->loadLocale('xx-xx');

Para traduzir:

echo $locale->t($key);

Bem parecido com o Kohana . Vejam a demonstração LocaleDemo.

Só precisava que vissem esta base e se a acham facil de utilizar e se se obtem bons resultados...

February 4, 2011

Bem, parece-me que não queres mesmo ajuda. Não quis comparar nada, apenas disse que os métodos que usas (e isso não está intrinsecamente ligado com features, que é meio irrelevante) não me cativam e não os acho práticos o suficiente para uma framework. Sou apologista da máxima que "a fazer, que seja por um bom motivo e sempre para o melhor" (a não ser que o intuito seja aprender, que é outro caso). Acho mesmo que devias experimentar as outras frameworks, do que vi por alto da tua, pareceu-me mais um remake do que anda por aí, não vi nada que me saltasse à vista como factor decisivo de uso (em termos de performance até ficou bem abaixo).

Se querias manter a framework simples, deves começar por desenhá-la em papel ou com outro método qualquer em que possas definir, sem ter de recorrer directamente ao código, aquilo que pretendes e o que achas essencial. O caso do jQuery, por exemplo, é lixo numa framework PHP, não faz qualquer sentido estar a incluir isso.

February 4, 2011

Antes de mais obrigado pelo teu feedback yoda. Era bom que mais pessoal se pronunciasse... Quero ajuda sim, acho que não me interpretaste bem...

Sou apologista da máxima que "a fazer, que seja por um bom motivo e sempre para o melhor" (a não ser que o intuito seja aprender, que é outro caso).

É verdade que isto começou por ser um exercício, um desafio, mas gostava de levar isto mais a sério.

Acho mesmo que devias experimentar as outras frameworks, do que vi por alto da tua, pareceu-me mais um remake do que anda por aí, não vi nada que me saltasse à vista como factor decisivo de uso (em termos de performance até ficou bem abaixo).

Pois lá está... parece que é difícil fugir ao padrão, e se reparares, acho que todas as Frameworks se repetem um bocado... basta olhar para aqui e vemos que variam pouco... algumas até dão bastante trabalho até ter tudo configurado para começar a trabalhar...

É, sem cache, também não estou muito satisfeito com a velocidade...

Se querias manter a framework simples, deves começar por desenhá-la em papel ou com outro método qualquer em que possas definir, sem ter de recorrer directamente ao código, aquilo que pretendes e o que achas essencial.

Achas mesmo que não está simples??? Tens o FreeFrame.php que recebe o request, pergunta à cache se tem a página, se não tiver passa para o Core que inicializa a base de dados, carrega o user e faz o dispatch do request... basicamente é isto não vejo complexidade nisto... a API também me parece simples... comparada com outras bem mais saturadas e complexas...

O caso do jQuery, por exemplo, é lixo numa framework PHP, não faz qualquer sentido estar a incluir isso.

Sim... o jQuery inicialmente não faz mesmo sentido inclui-lo na plataforma... mas lá está... mais cedo ou mais tarde acaba sempre por se ir buscar... mas sim tens razão quanto a isso.

O que achas que devia começar por melhorar?

February 4, 2011

Pois lá está... parece que é difícil fugir ao padrão, e se reparares, acho que todas as Frameworks se repetem um bocado... basta olhar para aqui e vemos que variam pouco... algumas até dão bastante trabalho até ter tudo configurado para começar a trabalhar...

Esse link está bastante desactualizado, algumas das frameworks que aí estão já suportam alguns dos pontos que aí não estão marcados, faltam um grande número de frameworks e há uma série de metodologias que não estão aí descritas, como HMVC e GLUE. Existem grandes diferenças entre essas frameworks, só testando algumas é que te vais aperceber disso.

É, sem cache, também não estou muito satisfeito com a velocidade...

Uma framework deve ter um tempo de resposta no mínimo aceitável sem ter de recorrer à cache, na minha opinião.

Achas mesmo que não está simples??? Tens o FreeFrame.php que recebe o request, pergunta à cache se tem a página, se não tiver passa para o Core que inicializa a base de dados, carrega o user e faz o dispatch do request... basicamente é isto não vejo complexidade nisto... a API também me parece simples... comparada com outras bem mais saturadas e complexas...

Há frameworks e frameworks. CodeIgniter, CakePHP e mais umas, têm propósitos comerciais por trás, o que leva a que sejam largamente divulgadas, consequentemente levando todo o tipo de pessoas ao seu uso e originando aquilo que na minha opinião é o início do fim de qualquer software, o saturar do mesmo com "merdices" plug-n-play. Uma framework devia, a mey ver, ter como objectivo único programadores com certo tipo de experiência, e não qualquer pessoa que queira fazer um site ou uma aplicação, ou no mínimo haver opção de escolha bem clara entre programadores e entusiastas / interessados. Actualmente existem opções para cada caso, o que não existe é a separação divulgada dessa forma (tirando alguns casos, como o Kohana que se recusa a criar documentação para a framework e a fazer código inútil, de forma a que só lá esteja quem realmente quer e pode).

Podes ver a tua framework como algo simples, mas na minha opinião não é. Em primeiro lugar, a nomenclatura que escolheste é, por um lado difícil de memorizar / entender (a escolha dos nomes certos faz parte da boa OOP), e por outro lado enganadora (ao usares nomes como Model, View e Component, com conceitos muito próprios e que facilmente levam a enganos a quem é recente à framework). Em segundo lugar, é boa prática, e acho recomendável, decidires-te por um workflow a seguir na framework (um método um pouco mais restrito mas que futuramente permita a compreensão por parte de qualquer pessoa sobre as aplicações que se fazem a partir dela), que é algo discutível .. mas quem escolhe usar uma framework já se limita por si só a certos parâmetros, portanto acho que o caso fica equilibrado.

Não tenhas receio de adicionar funcionalidades a isso, garante é que fica tudo íntegro, perceptível e que revele real utilidade em casos específicos na web.

February 4, 2011

Em adição, devo dizer que a maneira mais rápida que encontrei de aprender programação foi a ler software bem comentado (e não documentado). Ler código bem comentado ajuda imenso a perceber as razões por detrás das opções de cada ferramenta.

February 4, 2011

consequentemente levando todo o tipo de pessoas ao seu uso e originando aquilo que na minha opinião é o início do fim de qualquer software, o saturar do mesmo com "merdices" plug-n-play.

Uma framework devia, a mey ver, ter como objectivo único programadores com certo tipo de experiência, e não qualquer pessoa que queira fazer um site ou uma aplicação, ou no mínimo haver opção de escolha bem clara entre programadores e entusiastas / interessados.

Percebi o recado... eu sei que não é qualquer um que tem capacidade para fazer uma framework que seja "aceite" por um largo numero de programadores para servir como base de trabalho... e tu já te aventuraste a criar uma??? E as pessoas que criaram CodeIgniter, Kohana, CakePHP, Zend, etc... não achas que sentiram o inicio das suas criações como uma "aventura"??? Digo aventura porque no inicio não se sabe que sucesso ou aceitação irá ter e nessa fase inicial tudo pode ser "uma perca de tempo". Eu não fujo a regra... está a ser uma aventura

Em primeiro lugar, a nomenclatura que escolheste é, por um lado difícil de memorizar / entender (a escolha dos nomes certos faz parte da boa OOP), e por outro lado enganadora (ao usares nomes como Model, View e Component,

RedBean_SimpleModel é um Model... aceite por toda a comunidade que usa RedBeanPHP.

Document extends Mustache eu chamo de View porque contêm funções que lidam com a lógica da apresentação...

Create a view object

- https://github.com/bobthecow/mustache.php

Estou a chamar Component aquilo que é entendido normalmente como um Controller... Mas atenção que em MVC os Controllers são singleton... aqui não... aqui são instâncias de objectos cuja função é decidir o que fazer com o input (controlar).

Mas talvez deva chamar Controller em vez de Component... isto realmente não está claro...

A principal ideia que quero passar é a de que 1 componente pode delegar responsabilidades/acções a outros componentes.

Não tenhas receio de adicionar funcionalidades a isso

Sim... uns Helpers são sempre bem-vindos... e a parte de plugins que ainda não está muito funcional... mas já tenho um Plugin a funcionar: HtmlCompactor

Em adição, devo dizer que a maneira mais rápida que encontrei de aprender programação foi a ler software bem comentado (e não documentado). Ler código bem comentado ajuda imenso a perceber as razões por detrás das opções de cada ferramenta.

Já tens a ultima versão? As classes Core, Core_Cache, Core_Component, Core_Locale, Core_IPLugin e Core_Performance estão bem comentadas... e muito do código inicial, confuso, já não existe...

February 5, 2011

Acerca de chamar Componente ou Controlador... ou só Objecto... vejam lá se isto faz sentido...

Eu tenho um carro e quero apitar... faço o request http://maquina/aplicacao/?c=Carro&m=apitar

class Carro extends Core_Component {
    public function apitar() {
        $buzina = $this->load('Buzina');
        $buzina->apita();
    }
}

class Buzina extends Core_Component {
    public function apitar() {
        echo 'Beep!';
    }
}

Mas também posso pedir à Buzina para apitar, sendo 2 componentes independentes... http://maquina/aplicacao/?c=Buzina&m=apitar

Foi com base neste pensamento que chamei Component e não Controller...

Isto basicamente pode ser Chain-of-Responsability (ou Mediator) e o $this->load() faz o Dependecy Injection

Ha várias forma de fazer este comportamento... gosto deste artigo... http://www.scribd.com/doc/15461280/Command-Design-Pattern-Action-Delegate

Talvez com o nome Componente... o Iterator é o que faz mais sentido... Um componente manda uma mensagem a cada 1 dos N outros components para executar a acção x().

FreeFramePHP

Recommended Posts

taviroquai 55

Share this post

Link to post

Share on other sites

softklin 11

Share this post

Link to post

Share on other sites

taviroquai 55

Share this post

Link to post

Share on other sites

scorch 12

Share this post

Link to post

Share on other sites

softklin 11

Share this post

Link to post

Share on other sites

taviroquai 55

Share this post

Link to post

Share on other sites

yoda 135

Share this post

Link to post

Share on other sites

taviroquai 55

Share this post

Link to post

Share on other sites

taviroquai 55

Share this post

Link to post

Share on other sites

scorch 12

Share this post

Link to post

Share on other sites

taviroquai 55

Share this post

Link to post

Share on other sites

scorch 12

Share this post

Link to post

Share on other sites

taviroquai 55

Share this post

Link to post

Share on other sites

yoda 135

Share this post

Link to post

Share on other sites

taviroquai 55

Share this post

Link to post

Share on other sites

yoda 135

Share this post

Link to post

Share on other sites

taviroquai 55

Share this post

Link to post

Share on other sites

yoda 135

Share this post

Link to post

Share on other sites

taviroquai 55

Share this post

Link to post

Share on other sites

yoda 135

Share this post