O conceito de orientado a eventos é amplo. Pode ser do lado do cliente ou do lado do servidor.
Em aplicações WEB, os eventos do lado do cliente são baseados em JS ou plug-ins ou JAVAAPPLET Basicamente, se for um plug-in ou JAVAAPPLET, não pertence à categoria de HTML. usados são na verdade Não são muitos, no máximo são operações básicas como envio de FORM ou cliques em links, então falar sobre eventos não tem sentido.
O verdadeiro significado de orientado a eventos não está na programação visual, mas em seu conceito, assim como OO. Orientado a eventos é na verdade uma extensão do OO e seu protótipo original é o mecanismo de mensagem. Mas o driver de evento encapsula a mensagem em uma função que pode ser chamada, que é semelhante à função de retorno de chamada na API. Você mesmo pode definir o conteúdo de execução dessas funções. A programação visual separa essas funções, define parâmetros (principalmente objetos prontos) e permite que você escreva seu próprio código e use esses parâmetros (na verdade, esses objetos) para fazer algo.
Portanto, é perfeitamente possível que o PHP seja orientado a eventos, principalmente devido ao design do framework. Para criar um chamado driver de evento visual como o VB, você deve ter um ambiente de desenvolvimento integrado de suporte, incluindo uma série de funções como design de página, codificação de eventos, compilação e transcodificação. Na verdade, aqueles orientados a eventos como o NET apenas encapsulam alguns elementos ou controles da WEB comumente usados, como botões, caixas de texto, etc., para que você possa ter uma interface visual para projetar. Depois de compilada, ainda é um texto como este. , basta converter seu código de evento em JS ou código do lado do servidor. Para PHP, o principal motivo é que o IDE não é rico o suficiente e não há mecanismo de pré-compilação, então o código final enviado ainda é o código PHP final, em vez de uma mistura de código de recurso NET e código de evento (geralmente um código ASP documento que esteja em conformidade com a especificação XML Contém código HTML não padrão). Portanto, o PHP ainda não consegue alcançar a chamada programação orientada a eventos no sentido estrito na mente de todos, mas na verdade é completamente sem problemas.
Se você estiver interessado, você pode visitar a página oficial do www.php.net para dar uma olhada no PRADO, um framework PHP orientado a eventos escrito por um amigo chinês (Qiang Xue). recebeu muitos votos e é altamente recomendado. Consulte http://www.zend.com/php5/contest . Depois de ler seu código-fonte, você entenderá o que é o driver de evento do PHP. Mas acho que nesse sentido, como o PHP não possui mecanismo de pré-compilação e depende muito de OO (embora o código seja escrito em PHP5), esse framework é um pouco volumoso, complicado de usar e pouco escalável. No entanto, os conceitos são muito bons e algumas das ideias resolveram problemas que me intrigavam há muitos dias. Deixe-me apresentar brevemente esta estrutura abaixo.
O framework é escrito em ZDE e PHP5. Possui documentação detalhada, uma estrutura muito clara e comentários suficientes. O código é muito fácil de ler, indicando que o nível de codificação do autor é muito alto. O autor afirmou claramente que este framework se refere aos conceitos de ASP.NET e Borland Delphi.
Esta estrutura é muito forte na verificação (não que existam módulos como login de verificação), muito robusta e é quase impossível ter quaisquer brechas diretas que possam ser penetradas de fora. Ela introduz o conceito de limitação de arquivos. , ele resolve efetivamente o gargalo de eficiência na verificação em larga escala. O único problema com esse método de verificação é que a produção do arquivo de especificação em si é mais trabalhosa (é claro, o uso de ferramentas é outra questão, no entanto, uma vez feito (). o próprio arquivo de especificação com formatos e especificações), a verificação é feita naturalmente pelo framework sem a necessidade de chamadas humanas todas as vezes. Seus eventos também podem ser definidos no arquivo de especificação (acho que isso não é necessário, na verdade, seu arquivo de especificação é um pouco semelhante ao arquivo de definição FORM em DELPHI ou VB, mas é um texto simples escrito em XML). visualização. Quanto ao orientado a eventos, a estrutura possui um conjunto integrado de fluxos de eventos básicos semelhantes ao NET. Você pode personalizar esses eventos em diferentes estágios. Na verdade, para ser franco, isso significa redefinir essas funções OnXXX e usar parâmetros em um. dado formulário. Você também pode adicionar seus próprios eventos. Por exemplo, ao definir seu próprio componente, defina as funções de evento e os parâmetros que o componente pode ter no arquivo de especificação. ao usar o componente - mas acho que esse método é muito complicado e requer uma grande quantidade de arquivos XML para serem lidos e analisados. Embora seja muito rigoroso e seguro, é um pouco excessivo e não utiliza totalmente a flexibilidade do próprio PHP. . Minha ideia é usar algo semelhante ao DELPHI. Ao atribuir identificadores de função ou usar os recursos da função de retorno de chamada do C, você pode definir eventos a qualquer momento e em qualquer lugar enquanto escreve o código e ainda ser capaz de identificar claramente o remetente e o tipo do evento e ter. garantias de segurança suficientes sem a necessidade de máquinas. Ele efetivamente força cada componente a ter apenas determinados eventos, tornando a modificação e expansão do código muito conveniente. É claro que, ao trabalhar em grandes projetos, são necessárias definições rigorosas, mas mesmo assim, a forma como o framework trata os eventos é um tanto antiquada.
Acho que seu modelo é uma ideia melhor. Seu modelo é um pouco semelhante ao arquivo ASP do NET antes da compilação (não estou familiarizado com o ASP NET, mas entendo alguns princípios), mas a forma como funciona é um arquivo FORM semelhante ao DELPHI. é um conceito muito bom. A única desvantagem é que não é muito conveniente usar um editor geral WYSIWYG como o DW, porque vários componentes mutuamente exclusivos podem ser combinados em um modelo ao mesmo tempo e decidir quais deles exibir apenas. durante o tempo de execução.
Quando olho para o código deste framework, ainda descubro que ele possui alguns itens muito fracos. O mais importante é o problema do caminho. A escalabilidade é muito baixa. Deve ser mais adequado para hosts dedicados. Não há nada que você possa fazer em relação a alguns hosts restritos (restrições de diretório ou restrições de permissão) e não há medidas de lembrete correspondentes. e nenhuma interface relacionada). Ele usa um mecanismo complicado chamado assetService para o caminho de determinados recursos ou arquivos. O objetivo é determinar o caminho do arquivo. O próprio autor também disse que se este serviço for utilizado, o consumo do sistema aumentará significativamente. emprestado de O conceito de biblioteca de ativos no FLASH permite especificar o caminho arbitrariamente, mas deve ser verificado novamente todas as vezes, o que não vale o ganho. Minha abordagem é fixar vários caminhos principais, e seus subdiretórios podem ser arbitrários, o que equilibra de forma abrangente a contradição entre os dois. Devido à falta de consideração das questões do caminho, a estrutura é impotente com configurações de idioma, modelos personalizados, etc. Se você deseja traduzir um projeto, é concebível que os procedimentos sejam complicados, a carga de trabalho seja enorme e seja fácil de traduzir. cometer erros. Este é o problema mais sério da estrutura.
De modo geral, o conceito, o design e o código desta estrutura são absolutamente de primeira linha. É claro que sempre há lacunas, mas isso não nos impede de estudar e aprender. Não li todo o seu código, apenas alguns programas principais e algumas instruções, mas posso ver claramente sua estrutura e ideias. Admiro profundamente o autor, mas também lamento profundamente as deficiências. Não importa o que aconteça, é definitivamente um bom trabalho para estudar código PHP orientado a eventos. Portanto, altamente recomendado!