SILVIO COSTA MOREIRA UTILIZAÇÃO DO STRUTS FRAMEWORK NO DESENVOLVIMENTO DE UM GERENCIADOR DE EVENTOS

SILVIO COSTA MOREIRA UTILIZAÇÃO DO STRUTS FRAMEWORK NO DESENVOLVIMENTO DE UM GERENCIADOR DE EVENTOS Palmas 2006

i SILVIO COSTA MOREIRA UTILIZAÇÃO DO STRUTS FRAMEWORK NO DESENVOLVIMENTO DE UM GERENCIADOR DE EVENTOS Monografia apresentada como requisito parcial para a obtenção de notas nas disciplinas de Trabalho de Conclusão de Curso em Sistemas de Informação I e II do curso de Sistemas de Informação, orientado pelo Profº. Fernando Luiz de Oliveira Palmas 2006

ii SILVIO COSTA MOREIRA UTILIZAÇÃO DO STRUTS FRAMEWORK NO DESENVOLVIMENTO DE UM GERENCIADOR DE EVENTOS Monografia apresentada como requisito parcial para a obtenção de notas nas disciplinas de Trabalho de Conclusão de Curso em Sistemas de Informação I e II do curso de Sistemas de Informação, orientado pelo Profº. Fernando Luiz de Oliveira Aprovada em Julho de 2006 BANCA EXAMINADORA Profº. M.Sc. Fernando Luiz de Oliveira Centro Universitário Luterano de Palmas Prof. M.Sc. Fabiano Fagundes Centro Universitário Luterano de Palmas Profª. Cristina D Ornellas Filipakis Centro Universitário Luterano de Palmas Palmas 2006

iii AGRADECIMENTOS À Deus por te me dado a vida, a minha familia; aos meus pais: Salomão Barbosa Moreira e Raimunda Ires costa Moreira por ter me dado oportunidade de chegar até aqui; aos meus irmãos: Viviane Costa Moreira, Fabiane Costa Moreira, Saulo Costa Moreira, Alinne Costa Moreira e Lidianne Costa Moreira; aos meus sobrinhos: Isabella, Samuel, Emanuel, João Paulo e Gabriel, por terem me dado espiração para buscar novos horizontes; aos meus tios, primos, cunhados. Aos professores que no decorrer deste curso me transmitiram conhecimento, ao professor Fernando Luiz de Oliveira que me orientou na conclusão desse trabalho. Enfim, colegas de sala que se tornaram parte da minha vida, aos funcionários da biblioteca do CEULP/ULBRA-TO que me ajudaram a encontrar bibliografias necessarias para o desenvolvimento deste trabalho.

iv SUMÁRIO LISTA DE FIGURAS...V LISTA DE TABELAS... VI 1 INTRODUÇÃO...10 2 REVISÃO DE LITERATURA...12 2.1 PADRÕES DE PROJETOS...12 2.1.1 Vantagens de Usar Padrões de Projetos...13 2.2. ARQUITETURA MVC...14 2.3 ARQUITETURA MODELO 2...16 2.4 FRAMEWORKS...17 2.5 STRUTS FRAMEWORK...18 2.5.1 Componentes do Struts...20 2.5.2 Frameworks do Struts...26 3 MATERIAIS E MÉTODOS...32 3.1 LOCAL E PERÍODO...32 3.2 MATERIAIS...32 3.2.1 Fontes Bibliográficas...32 3.2.2 Hardware...33 3.2.3 Software...33 3.2.4 Instalação e Configuração das Ferramentas Utilizadas...33 3.3 METODOLOGIA...39 4 RESULTADOS E DISCUSSÃO...41 4.1 VISÃO GERAL DO SISTEMA DE GERENCIAMENTO DE EVENTOS...41 4.2 DIAGRAMA DE CLASSE DO SISTEMA...41 4.3 ARQUITETURA DO SISTEMA...43 4.3.1 Camada Visão...44 4.2.2 Camada Modelo...52 4.2.3 Camada Controle...54 4.3 CONSIDERAÇÕES SOBRE A UTILIZAÇÃO DO STRUTS FRAMEWORK...58 5 CONSIDERAÇÕES FINAIS...60 6 REFERÊNCIAS BIBLIOGRÁFICAS...62 ANEXOS...63

v LISTA DE FIGURAS Figura 1: Funcionamento do MVC (HUSTED, DUMOULIN, FRANCISCUS & INTERFELDT, 2004)... 15 Figura 2: Diagrama de funcionamento do Modelo 2 Modificada (SPIELMAN, 2002)... 17 Figura 3: Mapeamento de uma requisição no struts-config.xml... 21 Figura 4: Código Java que define uma ação... 22 Figura 5:Formulário de cadastro... 23 Figura 6: Classe Java que estende o componente ActionForm... 23 Figura 7: Configuração de um ActionForm no struts-config.xml... 24 Figura 8: Implementação da camada controle (HUSTED, DUMOULIN, FRANCISCUS & INTERFELDT, 2004)... 25 Figura 9: Inserção de páginas... 27 Figura 10: Arquivo de configuração tiles-defs.xml... 28 Figura 11: Configuração do Tile no struts-config.xml... 28 Figura 12: Inserções de páginas dentro de uma outra... 29 Figura 13: Criação de regras de validação no arquivo validator.xml... 31 Figura 14: Estrutura de pastas do Struts... 34 Figura 15: Arquivo de configuração web.xml... 36 Figura 16: Exemplo de um arquivo.properties... 39 Figura 17: Configuração do arquivo de mensagens... 39 Figura 18: Diagrama de classes... 42 Figura 19: Diagrama de funcionamento do Struts... 43 Figura 20: Página de cadastro de evento... 45 Figura 21: Arquivo de definição de layout do framework Tiles... 46 Figura 22: Código do formulário de cadastro de evento... 48 Figura 23: Regras de Validação... 49 Figura 24: Arquivo de mensagens... 52 Figura 25: Classe Evento... 54 Figura 26: Arquivo de configuração struts-config.xml... 55 Figura 27: Classe java cadastrareventoaction.java... 57

vi LISTA DE TABELAS Tabela 1: Tecnologias Java e componentes utilizados na estrutura do Struts (HUSTED, DUMOULIN, FRANCISCUS & INTERFELDT, 2004)... 19 Tabela 2: Principais arquivos de configuração do Struts (HUSTED, DUMOULIN, FRANCISCUS & INTERFELDT, 2004)... 20 Tabela 3: Bibliotecas de tags oferecidas pelo Struts (HUSTED, DUMOULIN, FRANCISCUS & INTERFELDT, 2004)... 20 Tabela 4: Validações prontas oferecidas pelo Validator (HUSTED, DUMOULIN, FRANCISCUS & INTERFELDT, 2004)... 30 Tabela 5: Configurações dos elementos... 38 Tabela 6: Cronograma das atividades... 40

vii RESUMO O desenvolvimento de software orientado a objetos não é uma tarefa simples, pois requer experiências que são adquiridas através de prática e estudos. Com o intuito de amenizar esse trabalho foram desenvolvidos padrões de projeto (design patterns) que são soluções utilizadas, testadas e que possuem sua eficácia comprovada para resolver determinados problemas no processo de desenvolvimento de softwares. Existe uma variedade de padrões de projeto, cada um com a sua metodologia. A arquitetura de desenvolvimento MVC (Model-View-Controller) utiliza alguns padrões de projetos, tais como Observer, Composite View, Strategy, Factory Method e Decorator. Esses padrões são utilizados para implementar sua metodologia, assim como a arquitetura Modelo 2, que é uma variação do MVC, adaptado para ser utilizado na web. Alguns métodos/técnicas implementam ou utilizam estas arquiteturas, tal como o Structs Framework, que se caracteriza por ser um framework que auxilia a construção de aplicações web seguindo o paradigma da orientação a objetos. Este trabalho tem por objetivo apresentar os conceitos que envolvem esta tecnologia, apresentando seus benefícios através da implementação de um sistema gerenciador de eventos. Palavras-chaves: Padrões de Projeto, MVC, Modelo 2, Struts Framework

viii ABSTRACT The development of software oriented to objects it isn't a simple assignment, because to require experience that are acquired with practice and studies. With the intention of to decrease this work were developed design patterns that are used solutions, tested and that to possess your proven effectiveness to solve determined problems in the process of the development of the software. There are a variety of the design patterns, each one with your methodology. The architecture of development MVC (Model-Wiew Controller) it uses some design patterns, such as Observer, Composite View, Strategy, Factory Method e Decorator. Those patterns are used to implement your methodology, like this how the architecture Model 2, that it is a variation of the MVC, adapted to be utilized in the web. Some methods/techniques to implement or use these architectures, such as the Structs Framework, that if characterize for being a framework that aids the construction of applications of web followed the orientation paradigm to objects. This work has by objective to present the concepts that involve this technology, showing your benefit fhrough of the formation of the a manager system of the events. Keywords: design patterns, MVC (Model-Wiew Controller, Model 2, Struts framework

10 1 INTRODUÇÃO Padrões de projeto são soluções encontradas por projetistas experientes no processo de desenvolvimento de softwares orientado a objetos, que são submetidas a um processo de testes para comprovar sua eficácia na resolução de um determinado problema. Cada padrão de projeto apresenta uma metodologia, que orienta os projetistas a utilizarem técnicas testadas e aprovadas por um grupo de especialistas, evitando, assim, que se perca tempo na resolução de um determinado problema. A expansão do paradigma orientado a objeto impulsionou a utilização de padrões de projeto no processo de desenvolvimento de software, sendo que é indispensável a aplicação dos mesmos no desenvolvimento de projetos de grande porte (GAMMA, 2004). Existe uma variedade de padrões de projetos, como o Composite View, Strategy, Factory Method, Decorator, Façade, entre outros. A arquitetura MVC utiliza alguns desses padrões de projetos em sua implementação. Esta arquitetura divide o sistema em três camadas: Model (Modelo), View (Visão) e Controller (controle) (SPIELMAN, 2002). Desta forma, o MVC possibilita fazer a separação da interface do código que implementa a lógica de negócios da interface. A primeira camada (Visão) é a responsável por apresentar a interface gráfica do sistema. A segunda (Modelo) possui o objetivo de abrigar os dados fundamentais do sistema. Por fim, a terceira camada (Controle) é a responsável por gerenciar as ações do usuário. Tendo como base o MVC, surgiram algumas outras arquiteturas. Dentre essas arquiteturas se destaca o Modelo 2, criado pela Sun, que se caracteriza por oferecer uma metodologia similar ao MVC, mas com algumas modificações para o desenvolvimento de sistemas orientado a objetos no ambiente web em Java. Com a finalidade de dar suporte ao desenvolvimento de sistema web, usando as tecnologias servlet e Java Server Pages (JSP), e tendo como base a arquitetura Modelo 2, foram desenvolvidos vários frameworks: Struts, Spring, Java Server Faces, WebWork,

11 entre outros. Dentre estes frameworks, merece destaque o Struts, pois foi o primeiro framework a dar suporte a implementação do Modelo 2 e que, por isso, é o mais utilizado (ALUR, CRUPI, MALKS, 2001). Este framework oferece uma variedade de recursos de fácil utilização, possui uma grande quantidade de material disponível, o que facilita a sua compreensão e aprendizado. O Struts caracteriza-se por auxiliar a construção de sistemas web através do fornecimento de um conjunto de componentes (classes e interfaces) e frameworks que facilitam a implementação e acelera o processo de desenvolvimento. O presente trabalho tem a finalidade de apresentar os conceitos envolvendo o desenvolvimento de sistema web utilizando o Struts Framework, assim como apresentar os recursos oferecidos por essa ferramenta, demonstrando sua utilização através do desenvolvimento de um sistema gerenciador de eventos, implementado com o auxílio dessa ferramenta. Para tanto, este trabalho está estruturado da seguinte forma: no capítulo 2 são apresentados os conceitos referentes a padrões de projeto, arquitetura MVC, arquitetura Modelo 2, frameworks e a ferramenta Struts. No capítulo 3 são apresentados os materiais e métodos utilizados nos estudos da ferramenta e os recursos de hardware e software utilizados para desenvolver esse trabalho. O capítulo 4 apresenta os resultados obtidos com o estudo, assim como a utilização da ferramenta. E, por fim, no capítulo 5 são apresentadas as considerações finais acerca deste trabalho.

12 2 REVISÃO DE LITERATURA Para que os propósitos desse trabalho fossem atingidos, foram realizados pesquisas e estudos envolvendo os conceitos referentes à utilização de Struts Framework no desenvolvimento de sistemas web, usando as tecnologias servlet e JSP. Estes estudos são necessários para fornecer uma fundamentação teórica para uma melhor compreensão do objetivo desse trabalho, no que se refere à utilização de Struts Framework. 2.1 Padrões de Projetos Padrões de projetos é uma forma padrão de se relacionar um problema a uma possível solução dentro do processo de desenvolvimento de software. Permite documentar um problema que ocorre freqüentemente, assim como a sua solução, para que se possa fazer uso desses conhecimentos em projetos futuros. Um padrão de projeto é composto por quatro elementos que são: nome, problema, solução e conseqüência (GAMMA, 2004). O nome serve para identificar o padrão e, geralmente, são usadas uma, duas ou três palavras. Já o problema descreve quando aplicar o padrão, bem como sua explicação e seu contexto. A solução é a descrição de como aplicar um padrão. Por fim, as conseqüências são os resultados alcançados com a utilização do padrão: vantagens e desvantagens. Segundo ALUR, CRUPI & MALKS (2001), um padrão de projeto refere-se a uma idéia que foi útil para resolver um determinado problema prático e que, provavelmente, será útil em outros. Um padrão de projeto possui as seguintes características (ALUR, CRUPI, MALKS, 2001): são escritos em um formato estruturado; evitam a reinvenção de soluções; existem vários níveis de abstração;

13 sofrem melhoria contínua; são artefatos reutilizáveis; expressam a melhor prática para resolução de um problema. Um padrão de projeto é como uma receita, uma fórmula que descreve a melhor forma de solucionar um problema. Existe uma variedade de padrões de projetos, tais como (GAMMA, 2004): Abstratc Factory: fornece uma interface para a criação de família de objetos relacionados ou dependentes sem especificar suas classes concretas; Adapter: converte a interface de uma classe em outra interface esperada pelos clientes; Builder: separa uma abstração da sua implementação, de modo que as duas possam variar independentemente; Strategy: define uma família de algoritmos, encapsula cada um deles e os faz intercambiáveis; Decorator: atribui responsabilidade adicional a um objeto dinamicamente; Observer: define uma dependência um-para-muitos entre objetos, de modo que, quando um objeto muda de estado, todos os seus dependentes são automaticamente notificados e atualizados; Além dos padrões de projetos citados acima, existem vários outros que apresentam uma metodologia de desenvolvimento de software orientado a objetos. Estes padrões podem ser utilizados diretamente, ou de forma indireta, através da utilização de uma arquitetura de desenvolvimento, que se baseia ou utiliza diversos tipos de padrões. 2.1.1 Vantagens de Usar Padrões de Projetos Padrões de projetos oferecem uma metodologia simples para implementação de um software, garantindo a qualidade do produto desenvolvido, pois têm a sua eficiência comprovada em projetos anteriores. Segundo GAMMA (2004), com a utilização de

14 padrões de projetos no desenvolvimento de software, os projetistas do mesmo tendem a obter várias vantagens, tais como: tornam mais fácil a reutilização de um projeto; ajudam a escolher alternativas de projetos que tornam um sistema reutilizável, evitando alternativas que comprometam a reutilização; melhoram a documentação e a manutenção de sistemas ao fornecer uma especificação explícita de interações de classes e objetos subjacentes; ajudam os projetista a obter um projeto mais rápido. Portanto, projetar software orientado a objetos seguindo uma metodologia de um padrão de projeto garante a qualidade e os requisitos que um software orientado a objetos tem que ter. 2.2. Arquitetura MVC A arquitetura MVC tem como estratégia de desenvolvimento a divisão de uma aplicação em três camadas: Model (Modelo), View (Visão) e Controller (Controle). Segundo Gamma (2004), antes do padrão MVC os projetos tendiam a agrupar essas camadas. No entanto, com o intuito de aumentar a flexibilidade e a reutilização dos sistemas, o MVC passou a separar essas camadas, separando a visão do modelo, oferecendo um protocolo para inserção/notificação (subscribe/notify) entre eles (GAMMA, 2004). Esse protocolo deve garantir que uma visão reflita o estado atual do modelo, ou seja, quando o modelo sofrer uma modificação, esse protocolo deve comunicar as alterações feitas para as visões que estão acessando o modelo. Ao utilizar essa arquitetura, os projetos tendem a oferecer uma maior confiabilidade permitindo o desenvolvimento de produtos reutilizável e de fácil manutenção. A Figura 1 apresenta o diagrama de funcionamento do MVC.

15 Modelo Alteração do estado Notificação Consulta do Estado Seleção da exibição Visão Controle Ações do Usuário Figura 1: Funcionamento do MVC (HUSTED, DUMOULIN, FRANCISCUS & INTERFELDT, 2004) Analisando a Figura 1, observa-se que todas as ações executadas pelo usuário são gerenciadas pela camada controle. Quando há uma alteração no modelo, o mesmo deve notificar as visões que estão conectadas a ela. Após a notificação, a camada visão deve consultar o modelo a fim de recuperar o estado atual do modelo. A seguir serão apresentados alguns detalhes de cada uma destas camadas: Visão: camada responsável por abrigar a interface gráfica da aplicação. Promove o acesso e modificação dos dados contidos na camada modelo. Possui as seguintes características: representa a camada de interface do usuário e recebe as entradas dos dados e exibe os resultados (GAMMA, 2004). Modelo: camada responsável por abrigar a lógica do negócio, os dados fundamentais da aplicação e as regras do negócio que controlam o acesso e modificações feitas nesses dados. Possui as seguintes características: modela os dados da aplicação e o comportamento por tráz do processo de negócio, controla o armazenamento dos dados e gerencia a criação de novos dados (GAMMA, 2004). Controle: camada responsável por atender as ações realizadas pelo usuário através da camada visão. É esta camada que recebe as requisições feitas pelo usuário, faz a interpretação dessa requisição para acessar a camada modelo e realizar as alterações.

16 2.3 Arquitetura Modelo 2 Para o desenvolvimento de aplicações web, tendo como base a linguagem de programação Java, os desenvolvedores têm a disposição duas tecnologias. A primeira refere-se ao servlet Java e a segunda ao Java Server Pages (JSP). Estas tecnologias possuem arquiteturas que orientam os desenvolvedores no processo de desenvolvimento. Segundo Husted, Dumoulin, Franciscus & Interfeldt (2004), na especificação 0.92 Servlet/JSP foram definidas duas arquiteturas de desenvolvimento: Modelo 1 e Modelo 2. A arquitetura Modelo 1 define a utilização da tecnologia JSP. Neste modelo o navegador acessa diretamente as páginas JSP, que por sua vez acessam as classes da camada modelo. O Modelo 1 promove a mistura de códigos provenientes da camada modelo com o código referente à interface gráfica da aplicação. É o modelo mais usado pelos desenvolvedores devido à facilidade na sua implementação (HUSTED, DUMOULIN, FRANCISCUS & INTERFELDT, 2004). Porém, as aplicações desenvolvidas conforme esse modelo são de difícil manutenção, reutilização e comprometem o trabalho em equipe, pois não há uma separação do código entre as camadas. Já a arquitetura Modelo 2 define a utilização das tecnologias servlet e JSP no desenvolvimento de aplicações web. Husted, Dumoulin, Franciscus & Interfeldt (2004), definem o Modelo 2 como uma arquitetura que usa os servlets e as páginas JSP juntos na mesma aplicação. Na arquitetura definida pelo Modelo 2 as páginas JSP ficam responsáveis por apresentar os dados aos usuários e os servlets têm a responsabilidade de acessar os dados e controlar o fluxo navegacional (HUSTED, DUMOULIN, FRANCISCUS & INTERFELDT, 2004). Na prática, o Modelo 2 é uma adequação do MVC para o desenvolvimento de aplicações web, pois não seria viável implementar uma aplicação web usando o protocolo de inserção/notificação que liga a camada modelo à camada visão definida no MVC em uma aplicação web, porque o protocolo utilizado na comunicação de dados em aplicações web é o HTTP (HUSTED, DUMOULIN, FRANCISCUS & INTERFELDT, 2004). Esse protocolo não estabelece uma conexão entre o cliente e o servidor. Sendo assim, seria difícil implementar o protocolo de inserção/notificação definido no MVC. A Figura 2 apresenta o diagrama de funcionamento do Modelo 2.

17 Figura 2: Diagrama de funcionamento do Modelo 2 Modificada (SPIELMAN, 2002) Como é mostrado na Figura 2, o servidor web direciona todas as requisições feitas pelo cliente para um servlet presente na camada controle que, por sua vez, é responsável por acessar as classes da camada modelo e apresentar a resposta a essa requisição através de uma página JSP contida na camada visão. Por ser assim, as aplicações desenvolvidas conforme definido pela arquitetura Modelo 2 facilitam a manutenção, reutilização e o trabalho em equipe. Porém são complexas de serem implementadas. A seção seguinte aborda os conceitos acerca de frameworks. 2.4 Frameworks Um frameworks é um conjunto de componentes (classes e interfaces) que trabalhão junto para solucionar um determinado problema de software. A principal finalidade de um framework é prover o seu reuso em outros projetos, diminuindo a complexidade na implementação de softwares. Segundo Gamma (2004), um frameworks dita a arquitetura de sua aplicação, ou seja, define a estrutura geral, sua divisão em classes e objetos e, conseqüentemente, as responsabilidades entre si, assim como a forma de colaborarem e o fluxo de controle. Lima (2006) identifica um framework pelas seguintes características: é composto por múltiplas classes ou componentes, cada um devendo prover uma abstração de um conceito particular; define como as abstrações trabalharam juntas para resolver um problema;

18 seus componentes são reusáveis; organiza padrões em alto nível. Existem vários frameworks disponíveis, como, por exemplo: Struts, WebWork, Spring, Vraptor Java Server Faces. Todos estes são baseados na arquitetura Modelo 2. Porém, existem outros mais específicos, que implementam apenas alguns padrões, ou outras arquiteturas, ou até mesmo que possuem outras finalidades. Dentre os frameworks citados, destaca-se o Struts, pois é o mais utilizado pelos projetistas de aplicações web Java devido a sua simplicidade, recursos oferecidos e a grande quantidade de material disponível na Internet ou em livros. Este framework é baseado nas tecnologias Servlet e JSP, e será abordado na próxima seção. 2.5 Struts Framework O Struts foi idealizado por Craig R. McClanahn e desenvolvido com a colaboração de um grupo de 30 desenvolvedores voluntários. Atualmente, a organização responsável por sua atualização é a Apache Software Foundation 1. Este framework é caracterizado por ser open-source (código aberto) e gratuito, ou seja, não se paga nenhuma taxa para sua aquisição e utilização, e tem como finalidade prover uma estrutura para o desenvolvimento de aplicações web, usando Servlet e JSP, baseado na arquitetura definida pelo Modelo 2. O Struts oferece um componente controlador chamado ActionServlet para controlar o fluxo navegacional da aplicação. O controlador é auxiliado por outros componentes, tais como ActionMappings, Action, ActionForm, ActionForward, entre outros, para acessar os dados, sejam eles provenientes de uma requisição HTTP ou de um Sistema de Gerenciamento de Bando de Dados (SGBD) na camada modelo. Outra característica é que disponibiliza bibliotecas de tags para apresentação, captação e manipulação de dados nas páginas JSP e frameworks que facilitam algumas tarefas de implementação como validação de dados e criação do layout das páginas. Utilizando o Struts, é possível desenvolver páginas internacionalizadas, ou seja, em vários idiomas, apenas criando e mantendo arquivos com extensão.properties, responsável por conter todos os textos, labels e mensagens apresentadas em uma página. 1 Maiores informações podem ser obtidas em: http://jakarta.apache.org/struts

19 O Struts disponibiliza os componentes necessários para implementação da camada controle e o integra com outras tecnologias, tais como Java Server Pages (JSP), bibliotecas de tags (Tag Libraries), JavaBeans, JDBC, entre outras; para prover a camada modelo e a visão. Estas tecnologias são usadas nas camadas dando suporte ao Struts, onde o JSP e as bibliotecas de tags são usados na camada visão para inserção e apresentação dos dados. Já o JavaBeans é utilizado na camada modelo para gerenciar os dados da aplicação. Portanto, para aplicar o Struts no desenvolvimento de uma aplicação web é necessário ter um mínimo de conhecimento dessas tecnologias. A Tabela 1 apresenta as camadas, assim como as tecnologias Java e componentes do Struts empregadas em cada uma delas na estrutura do Struts. Tabela 1: Tecnologias Java e componentes utilizados na estrutura do Struts (HUSTED, DUMOULIN, FRANCISCUS & INTERFELDT, 2004) Camada Visão Camada Controle Camada Modelo Componentes do Struts Tecnologias Extensões da tag JSP Java Server Pages e outros veículos de apresentação fornecidos pelos desenvolvedores ActionForwards Classes ActionForm ActionMappings ActionServlet Classes Action ActionErros MessageResources Varias classes utilitárias, como Commons-Digester e Commons-BeanUtils GenericDataSource JavaBeans e outros serviços de dados e APIs fornecidas pelos desenvolvedores Além dos componentes e tecnologias citados acima, o Struts utiliza vários arquivos de configurações: struts-config.xml, mensagem.properties, entre outros. A Tabela 2 apresenta alguns arquivos de configuração do Struts, assim como uma breve descrição de cada um.

20 Tabela 2: Principais arquivos de configuração do Struts (HUSTED, DUMOULIN, FRANCISCUS & INTERFELDT, 2004) Camada Visão Camada Controle Mensagem.properties Armazena as mensagens localizadas e labels para que possa ser utilizado o recurso de internacionalização Struts-config.xml Armazenam as configurações padrões para os objetos do Controlador, que inclui as ações do usuário, as alterações do estado e as consultas do estado suportadas pelo modelo Para exibição e manipulação dos dados em páginas JSP contidas na camada visão, o Struts disponibiliza bibliotecas de tags: struts-html.tld, struts-bean.tld, struts-logic.tld. A Tabela 3 apresenta as bibliotecas de tags oferecidas pelo Struts, assim como uma breve descrição. Tabela 3: Bibliotecas de tags oferecidas pelo Struts (HUSTED, DUMOULIN, FRANCISCUS & INTERFELDT, 2004) Biblioteca de tags Finalidade struts-html.tld Extensão da tag JSP para os formulários HTML struts-bean.tld Extensão da tag JSP para lidar com os javabeans struts-logic.tld Extensão da tag JSP para testar os valores das propriedades Além do conhecimento básico das tecnologias utilizadas pelo Struts, é necessário aprender os conceitos que envolvem os componentes, arquivos de configuração e bibliotecas de tags contidos no Struts para o desenvolvimento de aplicações web, que se baseiam nessa arquitetura. Estes componentes serão apresentados a seguir. 2.5.1 Componentes do Struts O Struts (versão 1.2.8) é composto pelos seguintes pacotes: org.apache.struts.action, org.apache.struts.actions, org.apache.struts.confg, org.apache.struts.plugins, org.apache.struts.resouces, org.apache.struts.taglib, org.apache.struts.titles, org.apache.struts.upload, org.apache.struts.util e org.apache.struts.validator. Estes, por sua vez, são compostos por componentes e frameworks que possuem funções específicas.

21 Dentro do pacote action, por exemplo, encontram-se os componentes: ActionServlet, ActionMappings, Action, ActionForward e ActionForm, que são os componentes fundamentais para o desenvolvimento de uma aplicação com Struts, pois fornece os recursos necessários para a implementação da camada controle. Os outros pacotes oferecem componentes e framework adicionais como: framework de validação e o de criação de layout, componente para fazer upload de arquivos, entre outros recursos. Esta seção visa fazer uma breve descrição dos componentes fornecidos para o desenvolvimento de uma aplicação web com o auxílio do Struts Framework. 2.5.1.1 Componentes da Camada Controle ActionServlet é o componente controlador do Struts e, através do auxílio de outros componentes, implementa a camada controle, estando presente no pacote org.apache.struts.action do Struts. Esse componente permite centralizar todas as requisições e as respostas a essas requisições em um único ponto. Portanto, todas requisições feitas por um cliente através de um browser são direciona para esse componente. Para atender uma requisição, o ActionServlet é auxiliado pelos componentes: ActionMapping, Action, ActionForm, ActionForward e ActionErros, tendo por base o arquivo de configuração struts-config.xml. Neste arquivo encontram-se as configurações de componentes e mapeamentos de todas as requisições, ou seja, os passos a ser seguido para atendê-las. A Figura 3 apresenta o mapeamento de uma requisição dentro do arquivo de configuração struts-config.xml. 1. <action-mappings> 2. <action path="/cadastrar" type="br.silvio.palmas.evento.cadastraraction" name="formulario" scope="request validate="true" > 3. <forward name="sucesso" path="/sucesso.jsp" redirect="false" /> 4. <forward name="erro" path="/erro.jsp" redirect="false" /> 5. <action-mappings> Figura 3: Mapeamento de uma requisição no struts-config.xml

22 A primeira linha (da Figura 3) é apresentada a tag que abriga os mapeamentos das requisições. Na segunda linha é apresentada a tag que define uma ação com as suas propriedades. Já nas linhas 3 e 4 são apresentadas as tags que definem qual página da camada visão será apresentada como resultado da ação e, por último, na linha 5 é apresentada a tag de fechamento do mapeamento. O componente Action tem como finalidade fazer a ligação entre as requisições e a lógica do negócio. O ActionServlet seleciona uma classe de ação apropriada para cada requisição que acesse a camada modelo, cria um exemplo (se necessário), e chama o método execute() (SPIELMAN, 2002). Uma classe de ação é uma classe Java que é subclasse do componente Action e tem a capacidade de acessar classes da camada modelo, responsáveis por buscar ou alterar os dados, geralmente em um Sistema de Gerenciamento de Banco de Dados (SGBD). O Action é mapeado no struts-config.xml, dentro de uma tag Action-Mappings onde está configurado o caminho da classe que executa a ação e a(s) página(s) que mostrará(ão) os resultados dessa ação. Na linha 2 (da Figura 3) é apresentada a tag que configura uma ação. A Figura 4 apresenta o código de uma classe Java que é subclasse do componente Action. 1. public final class CadastrarAction extends Action { 2. public ActionForward execute(actionmapping mapping, ActionForm form, HttpServletRequest request, HttpServletResponse response) throws Exception { 3 ActionErrors errors = new ActionErrors(); 4. DadoFormulario formulario = (DadoFormulario) form; 5. evento ev = new evento(); 6. if (ev.adicionar(formulario)) 7. return mapping.findforward("sucesso"); 8. else { 9. return mapping.findforward("erro"); 10 errors.add(actionerrors.global_error, new 11 ActionError("error.senhaAntiga")); } } } Figura 4: Código Java que define uma ação Na linha 1 (da Figura 4) é apresentada a criação de uma classe de ação. As linhas 2, 3, 4, 5, 6, 7 e 8 apresentam o código que executa uma ação e retornar um ActionForward,

23 que guarda o caminho de uma página JSP, ao ActionServlet para que ele apresente-a como resposta a requisição. Nas linhas 3 e 4 (da Figura 3) estão configuradas as páginas de resposta, dependendo do retorno da classe de ação. O componente ActionForm é responsável por recolher os dados contidos em um formulário e, se necessário, validá-los antes de ser executada uma ação. Esse componente auxilia a classe de ação na captação dos dados digitados pelo usuário para que os mesmos sejam inseridos, geralmente, em um banco de dados na camada modelo. A Figura 5 ilustra um formulário para cadastrar dados. Figura 5:Formulário de cadastro Para fazer a captação dos dados quando o formulário for submetido é necessário criar uma classe Java subclasse do componente ActionForm. Nessa classe são criados os atributos, métodos gets e sets correspondentes aos campos do formulário. A Figura 6 apresenta esta classe Java, a qual será responsável por receber os dados do formulário da Figura 5. 1. public class DadoFormulario extends ActionForm { 2. private String nome, cidade; 3. public String getnome() { 4. return nome; 5. } 6. public void setnome(string nome) { 7. this.nome = nome; 8. } 9. public String getcidade() { 10. return nome; 11.} 12.public void setcidade(string cidade) { 13. this.cidade = cidade; 14. } 15. } Figura 6: Classe Java que estende o componente ActionForm

24 A Figura 6 apresenta o código que define uma classe Java que é subclasse do componente ActionForm. Esta classe é instanciada pela classe de ação para fazer a captação dos dados inseridos em um formulário. Na linha 4 (da Figura 4) é apresentada a instanciação da classe definida na Figura 6. Além da classe responsável por receber os dados provenientes de um formulário, deve ser feita também uma configuração no arquivo struts-config.xml. A Figura 7 apresenta o código de configuração de um formulário. 1. <form-beans> 2. <form-bean name="formulario" type="pacote.dadoformulario" > 3. </form-beans> Figura 7: Configuração de um ActionForm no struts-config.xml Na linha 1 (da Figura 7) é apresentada a tag de abertura de um elemento formbeans. Esse elemento abriga a configuração de um ou mais formulários. A linha 3 apresenta a tag que configura a classe que estende o componente ActionForm, responsável por captar os dados inseridos em um formulário. O componente ActionForward é responsável por indicar o caminho das páginas JSP ao ActinServlet para que ele execute um RequestDispatcher.forward() ou HttpServletResponse.sendRedirect(), que são métodos utilizados para transferir o controle a um JSP ou um servlet que, geralmente, contém as respostas das requisições a serem mostradas ao usuário. Esse componente é executado pela classe de ação após a validação e execução da ação. O ActionForward é configurado no arquivo de configuração strutsconfig.xml. Nas linhas 3 e 4 da Figura 3 é apresenta a tag que configura o ActionForward. Já nas linhas 7 e 9 da Figura 4 é apresentada a execução do ActionForward dentro de uma classe de ação. Por fim, o componente ActionErro é responsável por abrigar mensagens de erros ocorrida no processo de validação dos dados na classe de ação. Essas mensagens podem ser impressas em uma página JSP e apresentada ao usuário através de tags específicas definidas pelas bibliotecas de tags contidas no Struts. O ActionErro é definido em uma classe de ação. Nas linhas 3 e 10 da Figura 4 são apresentados os códigos que implementam esse componente em uma classe de ação.

25 Todos os componentes apresentados nos parágrafos anteriores trabalhão junto dando suporte a implementação da camada controle. Cada componente tem uma função específica dentro deste contexto. A Figura 8 ilustra a interação destes componentes para a implementação da camada controle. Figura 8: Implementação da camada controle (HUSTED, DUMOULIN, FRANCISCUS & INTERFELDT, 2004) Cada requisição HTTP é direcionado para ActionServlet que aciona outros componentes para auxiliá-lo na apresentação da resposta HTTP a essa requisição. Quando o ActionServlet recebe uma requisição, por exemplo, a submissão de um formulário JSP com dados para ser inserido na camada modelo, ele aciona o componente Action para acessar a classe na camada modelo. Este, por sua vez, aciona o componente ActionForm para fazer o recolhimento dos dados para que sejam inseridos no modelo. O Action tem como retorno um ActionForward. O componente ActionForward é o componente responsável por guardar o caminho de uma página JSP, que será repassado ao ActionServlet para que ele apresente-a como resposta. Todos esses processos são definidos no arquivo de configuração struts-config.xml, dentro da tag action-mappings. O ActionMapping representa a informação para que o ActionServlet saiba sobre o mapeamento de uma requisição particular (SPIELMAN, 2002). Quando o ActionServlet recebe uma requisição, ele consulta o ActionMapping para saber quais os passos a serem seguidos para atender a essa requisição.

26 2.5.1.2 Componentes da camada Modelo Os componentes da camada modelo têm como finalidade manter o estado de uma aplicação. Para acessar e mudar os objetos da camada modelo, o Struts faz o uso das tecnologias Java para promover o acesso aos dados em um banco de dados como, JavaBeans, JDBC e todas as APIs disponíveis que tenha essa finalidade. 2.5.1.3 Componentes da camada Visão O Struts utiliza as tecnologias JSP para prover a camada visão e oferece as bibliotecas de tags contidas no pacote org.apache.struts.taglib. Essas tecnologias e componentes dão suporte a criação de interfaces gráficas de uma aplicação web, assim como a captação e apresentação dos dados inseridos pelo usuário. As bibliotecas de tags oferecidas pelo Struts não são de uso obrigatório, mas facilitam a apresentação e manipulação de dados em uma página JSP (HUSTED, DUMOULIN, FRANCISCUS & INTERFELDT, 2004). 2.5.1.4 Configuração dos Componentes do Struts A configuração dos componentes do Struts é feita em arquivos XML. Os arquivos de configuração são: web.xml, struts-config.xml. Existem outros arquivos de configurações opcionais, para caso seja necessário utilizar alguns componentes ou framework adicionais do Struts, como: framework Tiles, que é usado para a construção de layout em páginas JSP; e o framework Validator, usado para fazer validações de dados enviados pelo usuário em páginas JSP. Todos os arquivos necessários para fazer a configuração dos componentes do Struts serão descritos na seção 3 deste trabalho. 2.5.2 Frameworks do Struts Além dos componentes citados nas seções acima, o Struts possui também os frameworks: Tiles e Validator. O primeiro é utilizado na construção do layout das páginas e o segundo é utilizado para validar os dados inseridos pelo usuário. Esses dois frameworks facilitam a implementação, diminuindo de forma sistemática a complexidade de criação do layout e da

27 validação de dados (HUSTED, DUMOULIN, FRANCISCUS & INTERFELDT, 2004). As seções seguintes apresentarão maiores detalhes acerca dos conceitos envolvidos por estes dois frameworks. 2.5.2.1 Framework Tiles A apresentação da informação em sistemas web é um dos requisitos importantes, pois é o responsável por fazer a interação com o usuário. Se essa apresentação não estiver bem definida pode comprometer a usabilidade do sistema. O Struts oferece o frameworks Tiles para auxiliar a criação do layout das páginas web. O framework Tiles é composto por componentes que proporcionam a criação do layout das páginas, permitindo a inserção de páginas dentro de outras, em locais específicos. A Figura 9 ilustra a inserção de páginas dentro de uma outra através do framework Tiles. Figura 9: Inserção de páginas Uma página é inserida dentro de outra através de tag definida pela biblioteca tags struts-tiles.tld, que deve estar configurada em um arquivo chamado tiles-defs.xml. Neste arquivo define-se a página que receberá as outras páginas. A Figura 10 apresenta o arquivo de configuração tiles-defs.xml.

28 1. <?xml version="1.0"?> 2. <!DOCTYPE struts-config PUBLIC "-//Apache Software Foundation//DTD Tiles Configuration 1.1//EN" "http://jakarta.apache.org/struts/dtds/tiles-config_1_1.dtd"> <!-- definição do Layout da página index.jsp --> 3. <tiles-definitions> 4. <definition name="abre.principal" path="/index.jsp"> 5. <put name="titulo" value="titulo da Página > 6. <put name="cabecalho" value="/cabecalho.jsp"/> 7. <put name="menu" value="/menu.jsp"/> 8. <put name="submenu" value="/submenu.jsp"/> 9. <put name="corpo" value="/corpo.jsp"/> 10. <put name="rodape" value="/rodape.jsp" /> 11. </definition> 12. <tiles-definitions> Figura 10: Arquivo de configuração tiles-defs.xml A linha 1 (da Figura 10) apresenta a definição da versão XML utilizada no arquivo. Já na linha 2 é especificado o DTD que regulamenta a criação de tags neste arquivo. Na linha 3 é apresentado a tag raiz do arquivo. A linha 4 apresenta a tag definition, que define a página que receberá as outras. As linhas 5, 6, 7, 8, 9 e 10 apresentam as tags que especificam o nome atribuído a cada uma das páginas, bem como a sua URL. Estas páginas podem ser inseridas na página referenciada na linha 4. A linha 11 apresenta a tag de fechamento da tag definition iniciada na linha 4 e na linha 12, fechamento da tag raiz do arquivo. Deve também ser feita uma configuração no arquivo struts-config.xml para utilizar o framework Tiles. A Figura 11 apresenta o código de configuração. <!-- abre a pagina principal da aplicação --> 1. <action path="/paginaprincipal" type="org.apache.struts.actions.forwardaction" parameter="abre.principal"/> <!-- Tiles Configuration --> 2. <plug-in classname="org.apache.struts.tiles.tilesplugin"> 3. <set-property property="definitions-config" value="/web-inf/tiles-defs.xml"/> Figura 11: Configuração do Tiles no struts-config.xml Na primeira linha (da Figura 11) é apresentada a tag action que possui a configuração da ação requisitada, e possui um parâmetro que identifica a página a ser

29 mostrada. Já na segunda linha é apresentada a tag que configura o framework Tiles e, por último, na linha 3, é apresentada a tag que indica o arquivo de configuração tiles-defs.xml. A Figura 12 apresenta o código de inserção das páginas definidas no arquivo de configuração tiles-defs.xml, dentro de uma página JSP, através das tags disponibilizadas pela biblioteca de tags struts-tiles.tld. 1. <%@ taglib uri="/web-inf/struts-tiles.tld" prefix="tiles" %> 2. <html> 3. <head> 4. <title><tiles:getasstring name="title"/></title> 5. </head> 6. <body > 7. <table border="0" cellpadding="0" cellspacing="0" width="740"> 8. <tr> 9. <td colspan="4"><tiles:insert attribute="cabecalho"/></td> 10. </tr> 11. <tr> 12. <td><tiles:insert attribute="menu"/></td> 13. <td><tiles:insert attribute="corpo"/></td> 14. <td><tiles:insert attribute="submenu"/></td> 15. </tr> 16. <tr> 17 <td colspan="4"><tiles:insert attribute="radape"/></td> 18. </tr> 19. </table> 20. </body> 21. </html> Figura 12: Inserções de páginas dentro de uma outra Na primeira linha (da Figura 12) é apresentada a tag que faz a referência à biblioteca de tags struts-tiles.tld. Já na linha 4 é apresentada a inserção de uma string através da tag <tiles:getasstring>, definida no arquivo de configuração tiles-defs.xml. Por fim, nas linhas 9, 12, 13, 14 e 17 são apresentadas as instruções para as inserções das páginas definidas no arquivo tiles-defs.xml, através da tag <titles: insert>. 2.5.2.2 Framework Validator Um sistema web recebe muitos dados inseridos pelos usuários. Para não receber dados inconsistentes, é necessário submetê-los a um processo de validação, onde são analisadas a consistências dos mesmos. Esse processo requer códigos que analisam item por item para

30 identificar se eles são validos ou não. Para diminuir a complexidade na validação dos dados, o Struts oferece um framework chamado Validator. O framewok Validator facilita a validação dos dados inseridos pelos usuários, diminuindo assim a sua complexidade, permitindo fazer a validação dos dados tanto do lado do cliente, como do lado do servidor. O framework Validator oferece os seguintes benefícios (HUSTED, DUMOULIN, FRANCISCUS & INTERFELDT, 2004): oferece validação do lado do cliente em JavaScript e validação no lado do servidor em arquivos XML ou em código Java; proporciona um único ponto de manutenção de código de validação; podem ser definidas validações através de expressões regulares ou em código Java; as validações compartilham o arquivo de mensagens.properties, onde é possível usar textos contidos nesse arquivo; existem ferramentas que oferecem uma interface gráfica para criação das validações. O Validator já possui algumas validações prontas, tais como: validação de e-mail, telefone, tipos de dados, entre outros. Essas validações estão dentro do arquivo de configuração validator-rules.xml. Se for necessário usar outras validações que não estão neste arquivo é possível criá-las. A Tabela 4 apresenta as validações contidas neste arquivo. Tabela 4: Validações prontas oferecidas pelo Validator (HUSTED, DUMOULIN, FRANCISCUS & INTERFELDT, 2004) Validação Finalidade Required Terá sucesso se o campo contiver qualquer caractere diferente de espaço em branco Mask Terá sucesso se o valor coincidir com a constante dada pelo atributo mask Range Terá sucesso se o valor estiver dentro dos valores definidos pelos atributos min e max ((value >= min) & (value <= max))) maxlength Terá sucesso se o comprimento do campo for menor ou igual ao atributo max minlength Terá sucesso se o comprimento do campo for maior ou igual ao atributo min byte, short, integer, long, float, double Terá sucesso se o valor puder ser convertido no primitivo correspondente Date Terá sucesso se o valor representar uma data válida. Um padrão poderá ser fornecido. creditcard Terá sucesso se o valor puder ser um número

31 Email válido de cartão de crédito. Terá sucesso se o valor puder ser um endereço de e-mail válido. Para fazer uso das validações contidas no validator-rules.xml é necessário criar regras de validações. As regras de validações são criadas no arquivo de configuração validator.xml. A Figura 13 apresenta a criação de regras de validação para um campo de um formulário no arquivo validator.xml. 1. <formset> 2. <form name="formulario"> 3. <field property="campo1" depends="required"> 4. <arg0 key="mensagemerro.campo1"/> 5. </field> 10. </formset> Figura 13: Criação de regras de validação no arquivo validator.xml A primeira linha (da Figura 13) apresenta a tag raiz do arquivo validator.xml. Já na segunda linha é apresentada abertura da tag dentro da qual se podem definir regras de validações para um determinado formulário. Na linha 3 é apresentada a tag que cria uma regra de validação para um determinado campo de um formulário. A linha 4 apresenta a tag que abriga a mensagem de validação que será apresentada ao usuário. Esta mensagem é definida no arquivo de mensagens.properties (arquivo responsável por abrigar mensagens que podem ser impressas nas páginas).

32 3 MATERIAIS E MÉTODOS Para o desenvolvimento desse trabalho foram utilizados diversos recursos bibliográficos, além de hardware e software que, aliados às orientações, permitiram a finalização do mesmo. 3.1 Local e Período Este trabalho foi desenvolvido durante o primeiro semestre de 2006, como parte da disciplina: Trabalho de Conclusão de Curso em Sistemas de Informação I e II. Os locais utilizados para sua elaboração foram os laboratórios de informática do curso de Sistemas de Informação, sendo que os mais utilizados foram os Laboratórios de Informática I e III, do Centro Universitário Luterano de Palmas. 3.2 Materiais Os recursos utilizados para o desenvolvimento deste trabalho foram disponibilizados pelo Curso de Sistemas de Informação do CEULP/ULBRA em seus laboratórios, tais como hardware e software licenciados. As demais ferramentas free foram adquiridas via Internet. 3.2.1 Fontes Bibliográficas Publicações Científicas;

33 Artigos; Site do STRUTS (STRUTS, 2006); Sites diversos. 3.2.2 Hardware Pentium III, 750 Mhz e 128 Mb de RAM (Disponível no laboratório); Pentium IV, 2.4 Ghz e 256 Mb de RAM (Disponível no laboratório); 3.2.3 Software Microsoft Windows 2000 Professional; Microsoft Office 2000 Professional; Microsoft SQL Server 2000 Internet Explorer 6.0; Acrobat Reader 7.0; Macromedia Dreamweaver MMX 2004; Macromedia Fireworks MMX 2004; Apache Tomcat 5.0.19; Eclipse 2.1.3 Jude UML 3.2.4 Instalação e Configuração das Ferramentas Utilizadas Esta seção visa auxiliar os desenvolvedores Java a utilizar o Struts framework para o desenvolvimento de sistemas web. Para tanto, as instruções de instalação e configurações da ferramenta Struts são descritas nas seções seguintes, passa a passo e com ilustrações.

34 3.2.4.1 Download do Struts Este trabalho utilizou a versão 1.2.8 do Struts e o seu download (struts-1.2.8-bin.zip) pode ser obtido através do link: <www.struts.apache.org/download.cgi>. 3.2.4.2 Instalação do Struts A instalação consiste na descompactação do arquivo do Struts em um diretório qualquer. Após a descompactação do arquivo, ele apresentará a seguinte estrutura de diretórios (Figura 14). Figura 14: Estrutura de pastas do Struts Na pasta lib encontram-se as bibliotecas de classes e frameworks, inclusive o Struts. A pasta webapps é composta por arquivos do tipo WAR, e contém: exemplos (struts-examples.war), documentação (struts-documentation.war) e uma aplicação modelo que serve de base para o desenvolvimento das novas aplicações (struts-blank.war). 3.2.4.3 Requisitos necessários para utilizar o Struts Para desenvolver aplicações com base no Struts é necessário ter as seguintes ferramentas: servidor web Servlet e JSP, como o Tomcat 2, por exemplo. 2 Disponível para download em: <http://java.sun.com/j2se>

35 Java 2 Platform Standard Edition (J2SE) 3. Editor de classe Java. Editor de páginas JSP. 2.3.2.3 Configuração do Struts 4 Sistemas desenvolvidos com auxílio do Struts são configurados através de arquivos de configurações: web.xml, struts-config.xml, mensagem.properties, entre outros. O web.xml é um arquivo XML que contém as configurações necessárias de um sistema. As configurações contidas nesse arquivo servem para mostrar ao servidor Servlet/JSP tudo o que ele precisa saber sobre um sistema. Neste arquivo são definidas várias configurações, tais como: componente do Struts ActionServlet, bibliotecas de tags que acompanham o Struts, parâmetros de inicialização, mapeamento de servlet, página principal da aplicação que por padrão é a index.jsp, entre outros. O web.xml já vem com as configurações padrões, mas se for necessário é possível definir novas configurações.. A Figura 15 apresenta o arquivo de configuração web.xml. 1. <?xml version="1.0" encoding="iso-8859-1"?> 2. <!DOCTYPE web-app PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.2//EN" "http://java.sun.com/j2ee/dtds/web-app_2_2.dtd"> 3. <web-app> <!-- Standard Action Servlet Configuration (with debugging) --> 4. <servlet> 5. <servlet-name>action</servlet-name> 6. <servlet-class>org.apache.struts.action.actionservlet </servlet-class> 7. <init-param> <param-name>config</param-name> 8. <param-value>/web-inf/struts-config.xml</param-value> 9. </init-param> 10. <init-param> 3 Disponível para download em: <http://jakarta.apache.org/> 4 Esta seção é baseada no capitulo 4 do livro Struts em Ação (HUSTED, DUMOULIN, FRANCISCUS & INTERFELDT, 2004)