Inicio - SETI
Como já mencionado, o IHM será implementado utilizando a tecnologia Servlets/JSP através dos seguintes frameworks:
A implementação do IHM das aplicações respeitará os princípios propostos pelo framework Struts, padrão de desenvolvimento MVC2.
Geralmente, busca-se agrupar as ações em classes que herdam da DispatchAction ou DispatchActionSupport, utilizando-se do Spring. Esta prática evita muitas classes à gerenciar para manutenibilidade. O número de declarações à realizar no arquivo struts-config.xml também é reduzido. Todavia, em certas situações não é possível agrupá-las, geralmente quando o retorno das ações não é o mesmo. Neste caso é preferível escrever ações clássicas do Struts, ou seja, uma classe Action ou ActionSupport, utilizando-se do Spring, por ação com um método execute único.
Deverá ser utilizado por padrão formulários dinâmicos do Struts, do tipo DynaActionForm, somente mapeado no arquivo de configurações. No caso de formulários muito complexos poderão ser criadas classes de formulário padrão do tipo ValidatorForm.
Um mesmo formulário poderá ser reutilizado por várias ações. Mas não deverá ser feito caso a mutualização exija esforços especiais ou se os diferentes formulários forem sucetíveis à sofrer alterações no futuro, é preferível diferir os formulários mesmo que sejam muito parecidos.
Todos os nomes lógicos deverão ser centralizados no arquivo de configuração do Struts em constantes de interface no lado Java, afim de vincular o mínimo estes valores lógicos no resto do código fonte. Este princípio não se aplica aos nomes que não sejam utilizados como referência no código Java.
Para isto, criar interfaces dedicadas às constantes da camada cliente para fazer com que as actions às implementem (i.e. via uma action pai da aplicação):
Não deve-se hesitar em sobrecarregar os diferentes componentes do Struts (Servlet, Action, Forms) para facilitar a evolução, como por exemplo:
Para os controles da camada de apresentação deverá ser utilizado o plugin Struts Validator que organiza as validações e automatiza as mais utilizadas.
Deverá ser criado um validador específico à aplicação para reunir as funções de validação particulares que serão utilizadas várias vezes. Poderá servir para definir novos tipos de validação para o plugin Struts Validator (deverá ser declarado no validator-rules.xml e utilizado no validation.xml).
Utilizar o atributo format das taglibs para formatar datas, valores monetário, dentre outros tipos de máscaras. Para formatações específicas utilizar o padrão Decorator GoF sobre os JavaBeans e/ou taglibs.
Evitar ao máximo escrever código Java nas JSP. Utilizar no lugar as taglibs do Struts e DisplayTag. Se houver alguma necessidade específica que necessite do código Java, uma nova tag específica deverá ser criada fazendo parte das taglibs específicas da aplicação.
As partes visuais que aparecem de maneira recorrente nas páginas devem ser transformados em factories, sendo pela utilização de taglibs, seja pela inclusão de outras páginas JSP. Pode-se recorrer às inclusões estáticas e/ou dinâmicas de JSP. Note que a multiplicação de inclusões estáticas pode conduzir à problemas técnicos ligados ao tamanho do código Java gerado e necessidade de recompilação das JSP pai incluídas para recompilar uma JSP filha.
Para facilitar o reuso das JSPs deve-se utilizar o plugin Struts Tiles com a definição de templates dos módulos da aplicação.
Deverá ser respeitada a identação do código nas JSP.
Os objetos colocados na sessão deverão ser serializáveis (implementar a interface Serializable) para permitir a serialização das sessões pelo servidor.
O acompanhamento das sessões será realizado por cookies. Logo não é indispensável prever o modo URL rewriting (sobreescrita da URL).
O código da parte de apresentação (servlet, actions e JSPs) deve suportar multi-threading. Em conseqüência, não devem manipular variáveis de instância.
 |
Utilização do Struts
A arquitetura MVC2 do Struts propõe estruturar a camada Cliente em três elementos, a Visão que é implementada pelas páginas JSP utilizando Tiles, o Controle da navegação aonde o elemento central é o ActionServlet que garante a rota das requisições dos clientes aos objetos ActionForm validando o dados digitados com o Struts Validator. As requisições validadas serão encaminhadas pelo Controle até um objeto Action que irá se encarregar de efetuar o tratamento requisitado. Este tratamento consiste em acessar o Modelo, ou seja, a representação interna do dados manipulados. Os resultados da requisição serão retornados ao Controle para serem mostrados em uma JSP utilizando o Tiles. |
A implementação do IHM das aplicações respeitará os princípios propostos pelo framework Struts, padrão de desenvolvimento MVC2.
- um servlet único para canalizar as requisições
- as actions para realizar os tratamentos
- os formulários para recuperar os dados digitados
- as JSP para definir a apresentação das páginas
Geralmente, busca-se agrupar as ações em classes que herdam da DispatchAction ou DispatchActionSupport, utilizando-se do Spring. Esta prática evita muitas classes à gerenciar para manutenibilidade. O número de declarações à realizar no arquivo struts-config.xml também é reduzido. Todavia, em certas situações não é possível agrupá-las, geralmente quando o retorno das ações não é o mesmo. Neste caso é preferível escrever ações clássicas do Struts, ou seja, uma classe Action ou ActionSupport, utilizando-se do Spring, por ação com um método execute único.
Deverá ser utilizado por padrão formulários dinâmicos do Struts, do tipo DynaActionForm, somente mapeado no arquivo de configurações. No caso de formulários muito complexos poderão ser criadas classes de formulário padrão do tipo ValidatorForm.
Um mesmo formulário poderá ser reutilizado por várias ações. Mas não deverá ser feito caso a mutualização exija esforços especiais ou se os diferentes formulários forem sucetíveis à sofrer alterações no futuro, é preferível diferir os formulários mesmo que sejam muito parecidos.
Todos os nomes lógicos deverão ser centralizados no arquivo de configuração do Struts em constantes de interface no lado Java, afim de vincular o mínimo estes valores lógicos no resto do código fonte. Este princípio não se aplica aos nomes que não sejam utilizados como referência no código Java.
Para isto, criar interfaces dedicadas às constantes da camada cliente para fazer com que as actions às implementem (i.e. via uma action pai da aplicação):
- uma para os nomes de redirecionamento Struts (forwards)
- uma para os nomes dos parâmetros e atributos do request ou da session
- uma para os códigos de mensagens internacionalizadas
- outras para as outras constantes (diversas)
Não deve-se hesitar em sobrecarregar os diferentes componentes do Struts (Servlet, Action, Forms) para facilitar a evolução, como por exemplo:
- A extenção do ActionServlet para realizar a inicialização personalizada das aplicações (sobrecarregando o método « init » do Servlet).
- A extenção do Action para agregar os métodos comuns à um conjunto de ações (ao nível de aplicação, ao nível do plano funcional) e mascarar a implementação do desenvolvedor funcional (recuperar ou fixar o usuário corrente, por exemplo).
- A extensão do ValidatorForm para adicionar as funcionalidades específicas de verificação de números flutuantes em função da língua, entre outros. Note que para o caso de validações, é preferível desenvolver uma classe de validação dedicada.
Para os controles da camada de apresentação deverá ser utilizado o plugin Struts Validator que organiza as validações e automatiza as mais utilizadas.
Deverá ser criado um validador específico à aplicação para reunir as funções de validação particulares que serão utilizadas várias vezes. Poderá servir para definir novos tipos de validação para o plugin Struts Validator (deverá ser declarado no validator-rules.xml e utilizado no validation.xml).
Utilizar o atributo format das taglibs para formatar datas, valores monetário, dentre outros tipos de máscaras. Para formatações específicas utilizar o padrão Decorator GoF sobre os JavaBeans e/ou taglibs.
JSP
Para maior legibilidade, sempre utilizar JSP ao invés de gerar código HTML à partir do código Java, exceto casos em que isto seja realizado em uma taglib utilizada nas JSPs.Evitar ao máximo escrever código Java nas JSP. Utilizar no lugar as taglibs do Struts e DisplayTag. Se houver alguma necessidade específica que necessite do código Java, uma nova tag específica deverá ser criada fazendo parte das taglibs específicas da aplicação.
As partes visuais que aparecem de maneira recorrente nas páginas devem ser transformados em factories, sendo pela utilização de taglibs, seja pela inclusão de outras páginas JSP. Pode-se recorrer às inclusões estáticas e/ou dinâmicas de JSP. Note que a multiplicação de inclusões estáticas pode conduzir à problemas técnicos ligados ao tamanho do código Java gerado e necessidade de recompilação das JSP pai incluídas para recompilar uma JSP filha.
Para facilitar o reuso das JSPs deve-se utilizar o plugin Struts Tiles com a definição de templates dos módulos da aplicação.
Deverá ser respeitada a identação do código nas JSP.
Outros
Limitar o número e o tamanho dos objetos colocados na sessão.Os objetos colocados na sessão deverão ser serializáveis (implementar a interface Serializable) para permitir a serialização das sessões pelo servidor.
O acompanhamento das sessões será realizado por cookies. Logo não é indispensável prever o modo URL rewriting (sobreescrita da URL).
O código da parte de apresentação (servlet, actions e JSPs) deve suportar multi-threading. Em conseqüência, não devem manipular variáveis de instância.