Você está aqui: Zend Framework ::: MVC (Model View Controller) ::: Zend_Controller |
Saiba mais sobre o Zend_Controller do Zend FrameworkQuantidade de visualizações: 7687 vezes |
O Zend_Controller é o coração do sistema MVC do Zend Framework. MVC é o padrão Model-View-Controller (Modelo-Visão-Controlador) e seu objetivo principal é separar as regras de negócios das regras de apresentação nas aplicações web. O Zend_Controller_Front implementa o padrão FrontController, no qual todas as requisições feitas pelo usuário são interceptadas por um controlador de frente e direcionadas para Action Controllers individuais. Estes Action Controllers respondem às requisições baseadas na URL requisitada. Desta forma, temos vários Action Controllers em um controlador, e cada um é responsável por tratar uma URL diferente. O Zend_View é o sistema de templates para visualização (a parte visão do MVC) e é totalmente baseado em PHP. Isso significa que, ao contrário de Smarty ou PHPTAL, todos os templates de views são escritos em PHP. Para facilitar, o Zend_View fornece um sistema de plug-ins auxiliares que permite a criação de códigos de exibição diferenciados. Este sistema foi projetado para permitir a inserção de outros sistemas de template, tais como o Smarty. O fluxo de trabalho do Zend_Controller envolve uma série de componentes, e um bom entendimento, tanto do fluxo quanto dos componentes envolvidos, é crucial para o desenvolvimento de aplicações web MVC usando o Zend Framework. Basicamente nós temos os seguintes processos: a) O Zend_Controller_Front gerencia todo o fluxo de trabalho do sistema Zend_Controller. Ele é uma interpretação do padrão FrontController. O Zend_Controller_Front processa todas as requisições recebidas pelo servidor web e, baseado no padrão destas requisições, as delega para os ActionControllers (Zend_Controller_Action). b) O Zend_Controller_Request_Abstract (também chamado de Request Object) representa o ambiente de requisição e fornece métodos para atribuir ou obter os nomes dos controladores e ações e quaisquer outros parâmetros de requisição. Adicionalmente o Zend_Controller_Request_Abstract mantém um registro em relação se a ação que ele contém já foi ou não despachada pelo Zend_Controller_Dispatcher. Extensões ao objeto de requisição abstrato podem ser usadas para encapsular todo o ambiente de requisição, permitindo aos roteadores obter informações a partir do ambiente de requisição de forma a definir os nomes dos controladores (controller) e das ações (action). Por padrão, o Zend_Controller_Request_Http é usado, o que permite acesso a todo o ambiente de requisição HTTP. c) O Zend_Controller_Router_Interface é usado para definir rotas. Roteamento é o processo de examinar o ambiente de requisição para determinar qual controller e qual action daquele controller deverá receber a requisição. Este controller, action e parâmetros opcionais são então colocados no objeto de requisição para serem processados pelo Zend_Controller_Dispatcher_Standard. O roteamento ocorre somente uma vez: quando a requisição é inicialmente recebida e antes que o primeiro controller seja despachado. O roteador padrão, Zend_Controller_Router_Rewrite, obtém a URI final como especificado no Zend_Controller_Request_Http e a decompõem em controller, action e parâmetros baseado na informação do caminho da URL. Como um exemplo, a URL http://localhost/clientes/editar/454 seria decodificada para usar o controller clientes, a action editar e forneceria o valor 454 (talvez o id do cliente a ser editado). d) O Zend_Controller_Dispatcher_Interface é usado para definir despachadores. Despachar é o processo de retirar o controller e a action do objeto de requisição e mapeá-los a um arquivo de controlador (ou classe) e método de ação na classe controladora. Se o controlador ou ação não existir, o despachador se encarrega de pesquisar controladores e ações padrões. O real processo de despachar consiste em instanciar a classe controladora e chamar o método de ação nesta classe. Diferente do roteamento, que ocorre somente uma vez, o processo de despachar ocorre em um laço (loop). Se o status da atividade de despacho no objeto de requisição for reiniciado em qualquer ponto, o laço será repetido, chamando a action que estiver definida no objeto de requisição no momento. A primeira vez que o laço finaliza em decorrência do valor true sendo fornecido para o status de serviço de despacho do objeto de requisição, o processo de despachar estará concluído. O despachador padrão é Zend_Controller_Dispatcher_Standard. Ele define controladores como MixedCasedClasses (nomes compostos começando em letras maiúsculas) terminando com a palavra Controller e os métodos de ação como camelCasedMethods (nomes compostos mas letras maiúsculas somente a partir da segunda palavra) terminando com a palavra Action: ClienteController::excluirAction(). Neste caso, o controller seria cliente e a ação seria excluir. OBSERVAÇÃO IMPORTANTE: Convenções para o uso de letras maiúsculas e minúsculas - Uma vez que nós, humanos, somos historicamente inconsistentes em manter o uso adequado de letras maiúsculas e minúsculas quando estamos digitando os links, o Zend Framework normaliza a informação de caminhos para usar somente letras minúsculas. Isso afetará, é claro, a forma como damos nomes aos nossos controllers e actions, ou ainda, como nos referimos a eles em links. Se você quiser que seus controladores ou ações tenham nomes consistindo de múltiplas palavras MixedCasedWords ou camelCasedWords, terá que separar estas palavras na URL usando "-" ou "." (o caractere a ser usado pode ser configurado). Como exemplo, se quisermos chamar a action CadastroClienteController::cadastrarClienteAction, teremos que nos referir a ela usando /cadastro-cliente/cadastrar-cliente ou /cadastro.cliente/cadastrar.cliente. e) O Zend_Controller_Action é o componente controller de ação base. Cada controller é uma classe única que extende a classe Zend_Controller_Action e deve conter um ou mais métodos action. f O Zend_Controller_Response_Abstract define uma classe de resposta base usada para coletar e retornar respostas a partir dos controllers de ação. Ela coleta tanto os cabeçalhos quando o conteúdo do documento a ser retornado para a camada de visão. A classe de resposta base padrão é Zend_Controller_Response_Http, que é adequada para o uso em um ambiente HTTP. Resumindo, o fluxo de trabalho de Zend_Controller pode ser descrito da seguinte forma: Uma requisição é recebida pelo Zend_Controller_Front. Este, por sua vez, chama Zend_Controller_Router_Rewrite para determinar qual controller (e qual action deste controller) ele deverá despachar a requisição. O Zend_Controller_Router_Rewrite então decompõe a URI afim de definir os nomes do controller e da action presentes na requisição. O Zend_Controller_Front então entra em um laço de despacho. Ele chama o Zend_Controller_Dispatcher_Standard e fornece a este a requisição e o encarrega de despachá-la para o controller e action especificados na requisição (ou usar os padrões). Depois que o controller finaliza seu trabalho, o controle retorna para o Zend_Controller_Front. Se o controller indicar que outro controller deve ser despachado resetando o status de despacho da requisição, o laço continua e outro despacho é efetuado. Em caso contrário o processo termina. |
Link para compartilhar na Internet ou com seus amigos: |
Vamos testar seus conhecimentos em Fundações |
Sondagem à Percussão (SPT) e Rotativa (RQD) Um boletim de sondagem SPT está indicando uma camada de solo residual de granito de 4m com N variando de 3 a 8 golpes. Atingido os 4m, verificou-se que o solo é impenetrável à percussão. O engenheiro solicitou que fizesse outro ensaio ao lado daquele (2m) e o perfil obtido foi de uma camada de solo variando de 3 a 25 golpes até a profundidade de 8m. O que o engenheiro pretendeu comprovar, realizando outro ensaio logo ao lado do primeiro? A) A tentativa foi de comprovar que o solo era de péssima qualidade. B) A tentativa foi de comprovar que se tratava de um solo com uma camada de menor resistência logo abaixo. C) A tentativa foi de provar que se tratava de argilas de consistência mole. D) A tentativa foi de comprovar que no solo residual de granito podem ocorrer matacões. E) A tentativa foi de comprovar que o ensaio SPT não é eficiente para solos residuais. Verificar Resposta Estudar Cards Todas as Questões |
Vamos testar seus conhecimentos em Python |
Qual declaração de variável vai provocar um erro em Python? A) minhaNota = 4.65 B) minha_nota = 4.65 C) Minha_nota = 4.65 D) minha-nota = 4.65 E) MinhaNota = 4.65 Verificar Resposta Estudar Cards Todas as Questões |
Vamos testar seus conhecimentos em Hidrologia |
Assinale a alternativa que apresenta uma justificativa para a importância dos rios: A) A manutenção do equilíbrio ambiental local. B) A disponibilidade somente de água potável. C) A ausência de grandes eventos de inundação. D) O desgaste da superfície das rochas ígneas. E) O aumento da temperatura de forma pontual. Verificar Resposta Estudar Cards Todas as Questões |
Vamos testar seus conhecimentos em Engenharia Civil - Instalações Hidráulicas Prediais |
Materiais empregados para instalação de água fria e esgoto Em terminais de pias e acessórios embutidos na parede, onde são rosqueadas mangueiras e conexões, é indicada a aplicação de joelhos reforçados, em que a rosca é metálica, embutida sob pressão no PVC. A identificação dessa conexão é por um anel azul em sua face. Em relação ao joelho convencional, que é todo em PVC, a vantagem é: A) estética, uma vez que a face do joelho proporciona um acabamento rente ao azulejo superior à comum. B) econômica pois elimina uma série de outros componentes e conexões. C) o sistema de engate rapido por meio de utilização de anel de vedação junto à rosca. D) o fato de que, com o joelho reforçado, o risco de acontecer trinca resultante de aperto é menor. E) que fica exposta, eliminando o encaixe na alvenaria, diferentemente das comuns. Verificar Resposta Estudar Cards Todas as Questões |
Vamos testar seus conhecimentos em Fundações |
Questões de Concurso Engenharia Civil - Fundações COPEL - No estudo do subsolo para projeto de fundações, o número de golpes dados com um peso padrão, caindo em queda livre, de uma altura constante, necessários para a penetração de um amostrador padrão à profundidade de 30cm é denominado: A) Índice coesivo. B) Índice SPT. C) Carga morta. D) Índice de resistência à penetração. E) Carga aparente. Verificar Resposta Estudar Cards Todas as Questões |
Veja mais Dicas e truques de Zend Framework |
Dicas e truques de outras linguagens |
Códigos Fonte |
Software de Gestão Financeira com código fonte em PHP, MySQL, Bootstrap, jQuery - Inclui cadastro de clientes, fornecedores e ticket de atendimento Diga adeus às planilhas do Excel e tenha 100% de controle sobre suas contas a pagar e a receber, gestão de receitas e despesas, cadastro de clientes e fornecedores com fotos e histórico de atendimentos. Código fonte completo e funcional, com instruções para instalação e configuração do banco de dados MySQL. Fácil de modificar e adicionar novas funcionalidades. Clique aqui e saiba mais |
Controle de Estoque completo com código fonte em PHP, MySQL, Bootstrap, jQuery - 100% funcional e fácil de modificar e implementar novas funcionalidades Tenha o seu próprio sistema de controle de estoque web. com cadastro de produtos, categorias, fornecedores, entradas e saídas de produtos, com relatórios por data, margem de lucro e muito mais. Código simples e fácil de modificar. Acompanha instruções para instalação e criação do banco de dados MySQL. Clique aqui e saiba mais |
Linguagens Mais Populares |
1º lugar: Java |