UNIVERSIDADE DO VALE DO ITAJAÍ CENTRO DE CIÊNCIAS TECNOLÓGICAS DA TERRA E DO MAR CURSO DE CIÊNCIA DA COMPUTAÇÃO

Transcrição

1 UNIVERSIDADE DO VALE DO ITAJAÍ CENTRO DE CIÊNCIAS TECNOLÓGICAS DA TERRA E DO MAR CURSO DE CIÊNCIA DA COMPUTAÇÃO FRAMEWORK EM JAVA PARA DESENVOLVIMENTO DA CAMADA DE VISÃO PARA SISTEMAS WEB UTILIZANDO AJAX Área de Sistemas para Internet por Fábio de Matos André Luís Alice Raabe, Dr. Orientador Itajaí (SC), novembro de 2007

2 UNIVERSIDADE DO VALE DO ITAJAÍ CENTRO DE CIÊNCIAS TECNOLÓGICAS DA TERRA E DO MAR CURSO DE CIÊNCIA DA COMPUTAÇÃO FRAMEWORK EM JAVA PARA DESENVOLVIMENTO DA CAMADA DE VISÃO PARA SISTEMAS WEB UTILIZANDO AJAX Área de Sistemas para Internet por Fábio de Matos Relatório apresentado à Banca Examinadora do Trabalho de Conclusão do Curso de Ciência da Computação para análise e aprovação. Orientador: André Luís Alice Raabe, Dr. Itajaí (SC), novembro de 2007

3 DEDICATÓRIA Dedico o meu trabalho, primeiramente a Deus, a minha família e em especial a minha noiva pelo apoio dado a mim nesta jornada.

4 AGRADECIMENTOS Agradeço a Deus por colocar as pessoas certas no meu caminho e me dar forças nas horas em que mais precisei. Agradeço aos meus pais, Reni e Marlene por me ajudarem desde o inicio do curso, pelas palavras de incentivo para que eu continuasse nessa jornada e por toda a minha formação. Agradeço a minha noiva Helier por acreditar no meu potencial e me ajudar nos momentos difíceis que passei e estar sempre ao meu lado incentivado e me apoiando. Agradeço ao todos os professores que tive ao longo do curso, pelos conhecimentos que me passaram e que irei levar comigo para sempre. Dentre estes destaco o professor André, que me orientou neste trabalho e fez com que eu alcançasse mais essa vitória em minha vida. Obrigado.

5 SUMÁRIO LISTA DE ABREVIATURAS...iv LISTA DE FIGURAS...5 LISTA DE TABELAS...6 RESUMO...vii ABSTRACT...viii 1 INTRODUÇÃO PROBLEMATIZAÇÃO Formulação do Problema Solução Proposta OBJETIVOS Objetivo Geral Objetivos Específicos METODOLOGIA ESTRUTURA DO TRABALHO FUNDAMENTAÇÃO TEÓRICA WEB STANDARDS HTML DHTML XHTML XML DTD Esquemas (XML Schema) DOM CSS JAVASCRIPT O que se pode e o que não se pode fazer com o JavaScript Orientação a objetos em JavaScript AJAX MVC MODELO-VISÃO-CONTROLE TECNOLOGIAS SIMILARES ICEFaces Struts Google Web Toolkit Hibernate PROJETO MODELAGEM DO SISTEMA Requisitos Funcionais Requisitos Não Funcionais... 26

6 3.1.3 Regras de Negócio Diagrama de Classes Componentes Básicos Componentes Personalizados Telas Personalizadas IMPLEMENTAÇÃO Componentes Básicos Componentes Personalizados Tabela Menu Telas Personalizadas Formulário Lista Detalhe PROTÓTIPO Tela Inicial do Protótipo Telas de Cadastro do Protótipo CONCLUSÃO TRABALHOS FUTUROS REFERÊNCIAS BIBLIOGRÁFICAS...51 ANEXOS...53 iii

7 LISTA DE ABREVIATURAS AJAX API CSS DHTML DOM DTD EBNF GWT HTML JSP MVC ORM SGBD TCC UNIVALI XHTML XML XSD Asynchronous JavaScript and XML (JavaScript assíncrono e XML). Application Programming Interface (Interface de Programação de Aplicativos). Cascading Style Sheets (Folhas de estilo em cascata). Dynaminc Hypertext Markup Language (Linguagem de Marcação de Hipertexto Dinâmica). Document Object Model (Modelo de Objeto de Documentos). Definições de Tipos de Documentos. Extended Backus-Naur Form. Google Web Toolkit. Hypertext Markup Language (Linguagem de Marcação de Hipertexto). Java Server Pages. Model-View-Controll (Modelo-Visão-Controle). Object/Relational Mapping (Mapeamento Objeto Relacional). Sistema de Gerenciamento de Bando de Dados. Trabalho de Conclusão de Curso. Universidade do Vale do Itajaí. Extensible Hypertext Markup Language (Linguagem de Marcação de Hipertexto Extencível). Extensible Markup Language (Linguagem de Marcação Extencível). XML Schema Definition.

8 LISTA DE FIGURAS Figura 1. Documento XML simples contendo uma mensagem....9 Figura 2. Diferenças entre XML Schema e DTD...11 Figura 3. Hierarquia de Objetos do JavaScript Figura 4. Os Quatro principais componentes do Ajax Figura 5. Principais Componentes do padrão MVC...18 Figura 6. Tela de Demostração do ICEFaces...19 Figura 7. Tecnologia envolvidas no Struts...20 Figura 8. Uma visão detalhada da arquitetura do Hibernate...24 Figura 9. Diagrama de Pacotes...28 Figura 10. Diagrama de classes Componentes Básicos (a) Parte 1, (b) Parte 2, (c) Parte Figura 11. Diagrama de Classes Componentes Personalizados...32 Figura 12. Diagrama de Classes Tela Personalizadas...34 Figura 13. Tabela (Componente Personalizado). (a) Código fonte (b) Lista inicial. (c) Lista ao clicar no link Computação na linha Figura 14. Exemplo de um menu Figura 15. Criação de um formulário; (a) Código; (b) Formulário resultante...40 Figura 16. Diagrama de Seqüência - Criação de uma tela lista...41 Figura 17. Diagrama de Seqüência - Criação de uma tela de detalhe...42 Figura 18 - Tela Inicial do Protótipo...43 Figura 19. Código fonte para a criação do Menu...44 Figura 20. Tela de Cadastro de Curso. (a) Código para a criação da tela, (B) Tela de Cadastro...46 Figura 21. Tela de Cadastro de Turmas...47 Figura 22. Código fonte para a criação da tela Cadastro de Turmas...48

9 LISTA DE TABELAS Tabela 1. Classes do pacote Componentes Básicos...61 Tabela 2. Classes do pacote Componentes Personalizados...62 Tabela 3. Classes do pacote Telas Personalizadas...64

10 RESUMO MATOS, Fábio de. Framework em Java para Desenvolvimento da Camada de Visão para Sistemas Web Utilizando Ajax. Itajaí, f. Trabalho de Conclusão de Curso (Graduação em Ciência da Computação) Centro de Ciências Tecnológicas da Terra e do Mar, Universidade do Vale do Itajaí, Itajaí, Atualmente, o uso de web standards está se tornando cada vez mais comum entre os desenvolvedores de softwares para web. Contudo ainda há uma carência por parte dos desenvolvedores de um framework que os auxiliem no desenvolvimento de seus sistemas tornando esse processo mais rápido e fácil, principalmente na hora de realizar as manutenções. Pensando nessa dificuldade, foi proposto um framework de desenvolvimento web, com suas telas. O framework é composto por um conjunto de classes que permite ao usuário construir a interface do sistema utilizando componentes em Ajax ou utilizar um dos layouts pré-estabelecidos. Todo o framework é desenvolvido usando a tecnologia Java. Foi implementado um protótipo para consolidar o funcionamento e a importância do framework no desenvolvimento de sistemas Web.. Palavras-chave: AJAX. MVC. Framework.

11 ABSTRACT Nowadays web standards are becoming common among web software developers, butthere is still a lack of good frameworks to aid developers to rapidly develop application with easy maintenance. Concerning this problem, was proposed a web framework using ajax as interface technology. The framework is composed by a set of classes wich allow the user to create AJAX components on the interface or use pre-defined layouts. All the framework was developed in Java. Some tests were conducted to evaluate the correctness of the implementation. Keywords: AJAX. JAVA. MVC. Framework.

12 1 INTRODUÇÃO Atualmente os web standards estão se tornando cada vez mais comuns entre os desenvolvedores de sistemas para web. Visto que, web standards é um conjunto de normas, diretrizes, recomendações, notas, artigos, tutoriais e afins de caráter técnico, produzidos pelo W3C e destinados a orientar fabricantes, desenvolvedores e projetistas para o uso de práticas que possibilitem a criação de uma web acessível a todos, independentemente dos dispositivos usados ou de suas necessidades especiais. Segundo Weakley (2004), web standards significa muito mais que construir um site sem tabelas ou usar código válido. Um site projetado segundo as web standards deve estar em conformidade às standards (normas) (HTML, XHTML, XML, CSS, XSLT, DOM, MathML, SVG, etc) e seguindo as melhores práticas (código válido, acessível, semanticamente correto, etc). Contudo, ainda há uma carência por parte dos desenvolvedores de sistemas para web de uma metodologia ou frameworks que os auxiliem no desenvolvimento desses sistemas com mais rapidez e eficiência. Um exemplo de framework que não atende esses requisitos é o PHPLib-Univali utilizado na Intranet da Univali, onde apenas parte de sua estrutura é orientado a objeto. Ele não apresenta uma estrutura em camadas e sua interface não oferece nenhuma maneira de alteração de layout ou disposição de objetos na tela, além de funcionar apenas dentro de intranet da Univali. Isso se torna um problema quando um sistema deste tipo precisa ser migrado para outro local fora da intranet da Univali, o trabalho de reestruturação do código torna-se muito grande. Com o intuito de melhorar o processo de desenvolvimento de sistemas web, foi criado um framework para desenvolvimento de aplicações disponibilizando layouts de interfaces em Ajax. Isto permite padronizar o layout das telas e separar a interface do restante do sistema. Desta forma o programador apenas se preocupa com as regras de negócio do sistema. A idéia geral proposta foi desenvolver a camada de interface, deixando a camada de negócio e a camada de persistência para ser implementada pelo programador. Todo o framework foi desenvolvido em Java.

13 No contexto do desenvolvimento deste trabalho vale destacar três conceitos importantes: framework, MVC e Ajax. Framework, segundo Seára e Benitti (2006), é um conjunto de classes cooperantes que constroem um projeto reutilizável para uma classe específica de software e representam um conjunto abstrato para soluções de uma família de problemas relacionados. Conforme Larman (2004), framework é um conjunto de objetos extensível para funções relacionadas. Segundo Almeida (2001), o objetivo do MVC é separar dados ou lógica de negócios (Model) da interface do usuário (View) e do fluxo da aplicação (Control). A idéia é permitir que uma mesma lógica de negócio possa ser acessado e visualizada através de várias interfaces. Na arquitetura MVC, a lógica de negócio (chama-se de Modelo) não sabe de quantas nem quais interfaces estão exibindo seu estado. Segundo Nogueira, Prata e Velho (2004), o objetivo do MVC é a separação de código entre as camadas de visão e lógica de uma mesma funcionalidade. O modelo ou camada de persistência representa os dados e as regras que regem os acessos e atualização dos dados. A camada de visão acessa os dados através da camada de controle que por sua vez obtém os dados do modelo e com isso define como os dados devem ser apresentados. É responsabilidade da camada de visão manter a consistência quando os dados do modelo são alterados. Isto pode ser feito de duas formas: o modelo notifica a camada de controle, que por sua vez notifica a camada de visão que houve uma mudança ou a camada de visão pede ao modelo através da camada de controle a versão mais atualizada no momento da exibição. O controle mapeia interações com a apresentação em ações a serem realizadas pelo modelo. Baseado na interação do usuário e na resposta das ações realizadas pelo modelo, o controle responde selecionando uma apresentação apropriada. Ajax, segundo Paiva (2005), é um conjunto de tecnologias que trata uma requisição ou resposta de servidor com um documento XML DOM, baseado em uma série de métodos que possibilita que o browser possa realizar requisições e receber respostas do servidor sem que este tenha que atualizar (refresh) a tela. O framework proposto disponibilizará a camada de visão. Essa camada utiliza a tecnologia Ajax e fornece layouts padrões como lista, detalhe e cadastro, mas o programador poderá alterar 2

14 esses layouts como quiser, podendo criar um layout próprio. Além disso, foi disponibilizado uma biblioteca de componentes que utilizam Ajax para se comunicar assincronamente com o servidor e evitando o refresh de página durante a execução do sistema. A execução deste projeto de pesquisa se justifica em nível de Trabalho de Conclusão de Curso para o Curso de Ciência da Computação, uma vez que trata do desenvolvimento de uma solução computacional que faz uso de muitas tecnologias, conceitos e teorias relevantes a essa área. 3

15 1.1 PROBLEMATIZAÇÃO Formulação do Problema Com a popularização da internet é cada vez mais freqüente o uso de sistemas que executem pelo browser. Com isso os sistemas devem ser desenvolvidos de maneira rápida e que possibilite também uma rápida manutenção. Para que isso aconteça, os padrões de projeto são a melhor opção para que os sistemas sejam padronizados, diminuindo-se o tempo de desenvolvimento e detecção dos futuros erros. Os desenvolvedores de sistemas para web necessitam de um framework que diminua o tempo de desenvolvimento, seja confiável e que forneça um padrão de projeto que torne seu desenvolvimento e sua manutenção mais rápidos. Analisando os frameworks pesquisados neste TCC, verificou-se uma carência de produtos que possibilitem a programação seguindo o paradigma de programação em camadas e com interface usando Ajax, que se comunica assincronamente com o servidor e evita o refresh da tela, melhorando a performance do sistema Solução Proposta A solução proposta é um framework para desenvolvimento de sistemas web, disponibilizando a camada de visão. Essa camada utiliza Ajax para fazer a comunicação assíncrona com o servidor evitando que o sistema necessite carregar toda a página a cada requisição. O framework disponibiliza layouts prontos como lista, detalhe e cadastro, sendo que esses são extensíveis, possibilitando ao programador agregar novas funcionalidades aos mesmos. O framework também disponibiliza uma biblioteca de componentes que utilizam Ajax. Esses componentes podem ser utilizados para projetar novos layouts. 4

16 1.2 OBJETIVOS Objetivo Geral Desenvolver um framework para sistemas web utilizando Ajax, auxiliando o desenvolvedor a criar suas interfaces. O framework deverá conter uma biblioteca classes que auxiliarão o desenvolvedor a criar os componentes básicos HTML como o input, select, div, etc, além de componentes que servirão para a criação de telas pré-definidas como lista detalhe e cadastro e uma outra biblioteca de classes que cria componentes personalizados como lista e menu Objetivos Específicos Os objetivos específicos deste projeto são: 1) Pesquisar e descrever: 1. Padrões Web: 2. Ajax; 3. JavaScript; 4. MVC; 5. Soluções similares; 2) Realizar a modelagem do framework e implementação da camada de visão; 3) Realizar a modelagem e implementação de um protótipo; 4) Testar e validar a implementação e a utilidade/funcionalidade do framework no protótipo; 5) Documentar o framework e seu desenvolvimento. 5

17 1.3 Metodologia A metodologia para o desenvolvimento deste trabalho é composta por sete etapas. Na primeira etapa, foi realizado um levantamento bibliográfico de todas as tecnologias a serem utilizadas para a elaboração do projeto. A pesquisa foi baseada em livros, revistas científicas, artigos científicos publicados na internet. A segunda etapa consistiu em um levantamento de algumas tecnologias similares existentes, que serviram de base para a elaboração do projeto final. Com isso, pôde-se verificar funcionalidades que essas tecnologias não contemplavam e que podem ser agregadas ao projeto. Na terceira etapa foi realizada a modelagem do projeto utilizando a UML. Para isso, foi utilizado a ferramenta Enterprise Architect para a geração dos requisitos funcionais, requisitos não funcionais, regras de negócio e diagrama de classes. A quarta e última etapa consistiu na documentação de toda a pesquisa realizada e da modelagem do projeto de acordo com a norma NBR 6023/2002 e que resultaram no documento textual do TCC I. As estapas subseqüentes foram realizadas no TCC II, sendo que a quinta etapa caracteriza pela implementação da ferramenta baseado na modelagem já realizada. Na sexta etapa foi desenvolvido um protótipo de uma aplicação para testar e validar as funcionalidade, e por fim a sétima etapa do projeto foi realizado a redação da monografia do TCC II. 1.4 Estrutura do trabalho Este documento está estruturado em quatro capítulos. O Capítulo 1, Introdução, apresenta uma visão geral do trabalho. No Capítulo 2, Fundamentação Teórica é apresentada uma revisão bibliográfica sobre: Web Standards, JavaScript, Ajax, Mapeamento Objeto Relacional e MVC. Nesse capítulo, também é feita uma análise a respeito de frameworks existentes que utilizam o padrão MCV, Ajax e mapeamento objeto relacional. O Capítulo 3 apresenta o projeto detalhado do sistema a ser desenvolvido, incluindo sua especificação e a sua modelagem em UML. O capítulo também apresenta todo o desenvolvimento do framework e um protótipo que foi utilizado para realizar testes e validação. Concluindo, no Capítulo 4, apresentam-se as conclusões sobre o projeto e os trabalhos futuros que podem ser desenvolvidos. 6

18 2 FUNDAMENTAÇÃO TEÓRICA 2.1 Web Standards Para Vieira (2005), Web Standards significa servir o conteúdo web de forma correta e possibilitando que este conteúdo fique acessível a diversas pessoas independente de suas necessidades ou equipamentos utilizados. Escrever seu código HTML ou XHTML semanticamente correto é o primordial, utilizar as tags da linguagem com o seu real significado e não com sua aparência. Um site projetado segundo a Web Standards deve ser baseado em CSS (Cascading Style Sheets), atender a usabilidade e amigável aos mecanismos de busca HTML Segundo Goodman (2001), o HTML geralmente é visto como nada mais do que uma linguagem de formatação de documento, ou marcação. As tags (dentro de caracteres delimitadores < >) instruem um programa visualizador (o browser ou, mais genericamente, o cliente) a exibir pedaços de texto ou imagens. As melhorias recentes nos padrões publicados para HTML (HTML 4.0 e mais recentes) se empenham em definir de forma mais estreita a finalidade do HTML para atribuir contexto ao conteúdo, deixando a aparência para um padrão separado como as folhas de estilo DHTML O objetivo principal da DHTML (Dynamic HTML) é permitir que os scripts nos documentos controlem o conteúdo, a posição do conteúdo e a aparência do conteúdo em resposta a ação do usuário. Para esse fim, a organização W3C desenvolveu outro padrão para o posicionamento preciso de elementos HTML em uma página, como extensão do esforço para os padrões de CSS. A recomendação CSS-Positioning foi mais tarde agregada ao padrão CSS e agora ambos fazem parte da CSS Level 2. Com o posicionamento, pode-se definir um local exato na página onde um elemento deverá aparecer, se o item deverá ser visível e que ordem de empilhamento ele deverá ter entre todos os itens que possam ocupar o mesmo local (GOODMAN, 2001).

19 2.1.3 XHTML A XHTML (Extensible Hypertext Markup Language), segundo Deitel et al. (2003), pretende ser a sucessora da HTML. A versão atual da XHTML Recomendação XHTML 1.0 do W3C inclui elementos HTML 4 para a compatibilidade e para ajudar a quem trabalha com a web a fazer transição de HTML para XHTML. A XHTML é bem mais equipada do que a HTML para representar dados complexos na Internet. A maior parte do atual código HTML não é bem formatada porque os navegadores não verificam explicitamente os erros de marcação. A maioria dos navegadores acomoda os documentos HTML escritos incorretamente. O resultado é que o mesmo documento pode parecer diferente em cada navegador Web, dependendo da interpretação do código HTML incorreto. Com o surgimento da Web sem-fio e de outros equipamentos capacitados para trabalhar com a Web, o código HTML incorreto gera um problema de portabilidade. Dispositivos pequenos, como PDAs (Personal Digital Assistants) e telefones celulares digitais, têm quantidade de memória limitadas e não dispõem dos recursos extras necessários para processar a HTML escrita incorretamente. Os documentos destinados a esses dispositivos devem ser bem-formatados para garantir o processamento uniforme (Deitel et al., 2003). A XHTML tira proveito da sintaxe escrita em XML para assegurar a boa formação. Embora os elementos XHTML sejam quase idênticos aos elementos HTML, existem algumas diferenças notáveis. Todas as marcas de XHTML devem estar em letras minúsculas; um documento com marcas em letras maiúsculas é invalido. Todas as marcas iniciais de XHTML (por exemplo, <p>) devem ter uma marca final correspondente (por exemplo, </p>). As marcas vazias (isto é, que não tem marcas de finalização) devem ser terminadas com o caractere de barra normal ( / ). Portanto, a marca <br> em HTML torna-se a marca <br/> em XHTML. (Ibidem). Os documentos XHTML obedecem a uma das três DTDs (Definições de Tipos de Documentos) escrita, tradicional ou de conjunto de frames. A DTD escrita é utilizada quando um documento implementa a apresentação de conteúdo com CSS. Utiliza-se a DTD tradicional quando um documento contêm elementos apresentacionais (por exemplo, informações de fonte e de cor) incorporados nos elementos XHTML. A DTD de conjunto de frames é utilizada quando uma janela de navegador é particionada com frames HTML (Deitel et al., 2003). 8

20 2.1.4 XML Segundo Deitel et al.(2003), a XML é uma tecnologia para criar linguagem de marcação que descreve dados de qualquer tipo de uma forma bem estruturada. Diferentemente da HTML, que limita o autor do documento ao uso de um conjunto fixo de marcas, a XML permite que os autores do documento descrevam dados de forma mais precisa através da criação de novas marcas, conforme a Figura 1. Os documentos XML são geralmente armazenados em arquivos de texto que terminam com a extensão.xml, embora isso não seja um requisito da XML. Qualquer editor de texto pode ser usado para criar um documento XML. Muitos pacotes de softwares também permitem que os dados sejam armazenados como documentos XML. Figura 1. Documento XML simples contendo uma mensagem. Fonte: Deitel et al. (2003). Para Décio (2000), XML tem como propósito fundamental a descrição de informações. Essa capacidade é extremamente importante para armazenamento, recuperação e transmissão de informações. A XML permite colocar em um mesmo lugar dados e metadados, ou seja, uma descrição desses dados. XML estabelece um formato textual que pode ser facilmente entendido quando olhado diretamente (como, por exemplo, por meio de um editor de textos), ao invés de usar um formato binário ou seqüencial DTD Segundo Deitel el al. (2003), a DTD (Definição de Tipos de Documentos) é que define a estrutura de um documento (ou seja, elementos, atributos, etc, são permitidos no documento), e são definidas através da gramática EBNF (Extended Backus-Naur Form). Se o documento estiver de acordo com a DTD, ele é chamado de válido. Se o documento não estiver de acordo com a DTD, mas estiver sintaticamente correto, ele é bem formatado, mas não é válido. Se o documento estiver sintaticamente correto, ele é bem formatado. 9

21 Para Décio (2000), DTDs são usados para definir assim os chamados vocabulários. Cada vocabulário estabelece quais elementos são aplicáveis em uma determinada circunstância. Cada ramo de atividade que envolve transferência de informações tem um grande potencial para o uso de DTDs. DTDs podem ser pequenas, como os usados para descrever tabela em banco de dados, até muito grandes, como aquelas que são usadas em publicações de livros Esquemas (XML Schema) Segundo Deitel et al. (2003), esquemas são utilizados para validar documentos XML. Os esquemas podem ser usados com analisadores sintáticos validadores. Os XML Schemas(Esquemas) expressam vocabulários compartilhados e permitem que as máquinas realizem as regras feitas pelo desenvolvedor. Fornecem meios definindo a estrutura, o índice e a semântica do XML original mais detalhadamente. O XML Schema foi aprovado como uma recomendação da W3C em 2 maio 2001 e uma segunda edição que incorpora muitas erratas foi publicada em 28 outubro 2004 (W3C, 2007). Segundo Maia (2005), O propósito de um XML Schema é definir os blocos de construção permitidos em um documento XML com uma grande vantagem, o suporte a tipos de dados. Outra grande vantagem do XML Schema é ser escrito em XML. Na Figura 2, pode-se ver um exemplo de XML e um comparativo entre a DTD e o XML Shema deste XML. 10

22 Figura 2. Diferenças entre XML Schema e DTD Fonte: Adaptado de Maia (2005). 11

23 2.1.5 DOM Os documentos XML, quando sintaticamente analisados, são representados como estrutura hierárquica de árvore na memória. Essa estrutura de árvore contém os elementos do documento, seus atributos e o conteúdo. A XML foi projetada para ser uma tecnologia dinâmica um programador pode modificar o conteúdo da estrutura de árvore, o que essencialmente permite ao programador acrescentar dados, removê-los, consultá-los, e oferece-los de uma maneira similar a um banco de dados. O W3C fornece uma recomendação padrão para a construção de uma estrutura de árvore na memória para documentos XML, denominada DOM (Document Object Model) da XML. Qualquer analisador que segue essa recomendação é chamado de analisador baseado no DOM. Cada elemento, atributo, seção CDATA, etc., em um documento XML, é representado como um modelo de árvore DOM (DEITEL et al., 2003). Ainda segundo Deitel et al. (2003), um analisador baseado no DOM expõe (ou seja, torna disponível) uma biblioteca para uso em programas denominada API (Aplication Programming Interface) que permite que os dados em um documento XML sejam acessados e modificados pela manipulação dos nodos em uma árvore DOM CSS Segundo Deitel et al. (2003), o CSS permite que você especifique o estilo dos elementos da página (espaçamento, margens, fonte, etc.) separadamente da estrutura de seus documentos (cabeçalhos de seção, corpo do texto, links, etc.). Essa separação da estrutura da apresentação permite maior facilidade de gerenciamento e torna mais fácil efetuar mudanças no estilo de seus documentos. Para Décio (2000), CSS é uma linguagem que define regras pelas quais um browser exibirá um documento HTML ou XML. Basicamente, ao invés de se definir cor, letra e outros atributos na tag de abertura HTML, cria-se um documento separado que define como cada tag deve ser apresentada. CSS é uma linguagem de descrição, e não de programação. Pode-se definir estaticamente os atributos da cada tag, mas não tem como alterar essa definição dependendo do contexto. 12

24 2.2 JavaScript A linguagem JavaScript é empregada no computador cliente e pode ajudar a transformar uma máquina de conteúdo estático em uma experiência atraente, interativa e inteligente (GOODMAN, 2001). Segundo Ramalho (2000), JavaScript é uma linguagem que se integra ao documento HTML. Não se pode criar um programa em JavaScript e executá-lo sem um browser. É uma linguagem interpretada, ou seja, o código fonte sempre é traduzido para uma linguagem que o computador entenda na hora que for executado. Ela é baseada em objetos, o que significa que o programador pode utilizar objetos predefinidos ou então criar classes que satisfaçam suas necessidades. Inicialmente nascido sob o nome LiveScript, essa linguagem foi desenvolvida em paralelo com o software de servidor da web da Netscape. A linguagem deveria servir a duas finalidades, mas com a mesma sintaxe. Uma finalidade era como uma linguagem de scripting que os administradores do servidor da web pudessem usar para controlar o servidor e conectar suas páginas a outros serviços, como banco de dados de back-end e motores de consulta para os usuários pesquisarem informações (RAMALHO, 2000). No lado do cliente em documento HTML, os autores poderiam empregar scripts escritos nesta mesma linguagem para melhorar as páginas da web de várias maneiras. Por exemplo, um autor poderia usar a LiveScript para certificar-se de que as informações que um usuário insere em um formulário sejam do tipo correto. Em vez de forçar o servidor ou banco de dados a realizar a validação de dados, o computador do usuário trata de todo o trabalho de cálculo (RAMALHO, 2000). No início de dezembro de 1995, um pouco antes do lançamento formal do Navigator 2, a Netscape e a Sun anunciaram que a linguagem de scripting daí por diante seria conhecida como JavaScript (RAMALHO, 2000). Antes do anúncio, a linguagem já estava relacionada ao Java de algumas maneiras. Muitos dos elementos básicos de sintaxe da linguagem de script foram remanescências do estilo C e C++. Para o scripting no cliente, a linguagem foi idealizada para finalidades muito diferentes do Java essencialmente para funcionar como uma linguagem de programação integrada aos documentos HTML, em vez de uma linguagem para a escrita de applets que ocupam uma área retangular fixa na página. (GOODMAN, 2001). 13

25 2.2.1 O que se pode e o que não se pode fazer com o JavaScript Segundo Goodman (2001), usa-se JavaScript para os seguintes tipos de soluções: Fazer com que a página da Web responda ou reaja diretamente a interação do usuário com elementos do formulário e links de Hipertexto; Controlar a navegação por vários frames, plug-ins ou applets Java com base na escolha do usuário no documento HTML; Pré-processar dados no cliente antes do envio a um servidor; Alterar o conteúdo e os estilos nos browsers modernos dinamicamente e instantaneamente em resposta à interação com o usuário. O JavaScript não poderá realizar qualquer uma das seguintes ações: Configurar ou apanhar as configurações de preferências do browser, características da aparência da janela principal, botões de ação e impressão; Iniciar uma aplicação no computador cliente; Ler ou gravar arquivos ou diretórios no computador cliente ou servidor; Enviar secretos dos visitantes do site Orientação a objetos em JavaScript O JavaScript é uma linguagem baseada em objetos. Isso quer dizer, de uma forma bem simples, que ele trata todos os elementos de uma página Web como um objeto. Objetos normalmente são agrupados de acordo com seu tipo ou finalidade. A linguagem JavaScript possui objetos que são automaticamente criados e permite que sejam criados objetos. Quando um documento é carregado no browser, ele cria um certo número de objetos JavaScript com propriedades e valores ajustados pelo conteúdo do documento. Esses objetos respeitam uma hierarquia que reflete a estrutura de página HTML (RAMALHO, 2000), conforme a Figura 3. 14

26 Figura 3. Hierarquia de Objetos do JavaScript. Fonte: Adaptado de Ramalho (2000). 2.3 Ajax Segundo Crane, Pascarello e James (2007), Ajax não é uma tecnologia única. Em vez disso, é uma coleção de quatro tecnologias que se completam. Essas tecnologias são: JavaScript, CSS, DOM e XMLHttpRequest. Ajax dá vazão a uma grande quantidade de potenciais não realizados nas tecnologias dos navegadores Web. O Google e alguns outros dos principais competidores estão utilizando o Ajax para aumentar as expectativas do público em geral sobre o que um aplicativo Web pode fazer. Segundo Paiva (2005), o XMLHttpRequest, trata uma requisição ou resposta do servidor como um documento XML DOM. Este objeto contém uma série de métodos que possibilita que o browser possa realizar requisições e receber respostas do servidor sem que este tenha que atualizar a tela. O principal problema resolvido com AJAX é a substituição da tela escondida ou hidden frame, tecnica esta que era implementada como solução para a realização de uma requisição sem 15

27 refresh da página principal (em conexões lentas, esse processo de refresh tem um tempo de resposta muito grande, pois toda a página tem que ser recarregada no Browser). Segundo Crane, Pascarello e James. (2007), o JavaScript é utilizado para montar o aplicativo, definindo o fluxo de trabalho do usuário e a lógica de negócio do aplicativo. A interface com o usuário é manipulada e atualizada com o JavaScript através do DOM, redesenhando e reorganizando continuamente os dados apresentados aos usuários e processando suas interações baseadas no mouse e no teclado. O CSS fornece a aparência e comportamento (look and feel) consistentes para o aplicativo. O objeto XMLHttpRequest (ou uma série de mecanismos semelhantes) é utilizado para conversar com o servidor assincronamente, confirmando as solicitações dos usuários e buscando dados atualizados enquanto o usuário trabalha. A Figura 4 mostra como essas tecnologias se encaixam com o Ajax. Figura 4. Os Quatro principais componentes do Ajax. 16

28 Fonte: Crane, Pascarello e James. (2007). Ainda segundo Crane, Pascarello e James (2007), todas essas tecnologias já estão préinstaladas na maioria dos navegadores web diponíveis, como o Microsoft Internet Explorer, a família de navegadores Mozila/Gecko, incluindo o Firefox, Mozila Suite, Netscape e Caminho, o navegador Opera, o Safari da Apple e o Konqueror, do Unix KDE. As implementações dessas tecnologias são diferentes em relação a alguns detalhes e irão variar de uma versão para outra, mas essa situação foi amenizada nos últimos anos e há maneiras de lidar de modo claro com a incompatibilidade dos navegadores. 2.4 MVC Modelo-Visão-Controle Segundo Crane, Pascarello e James. (2007), o MVC (Model-View-Controler) é uma maneira de descrever uma boa separação entre a parte de um programa que interage com o usuário e a parte que faz o trabalho pesado, processamento numérico ou outro objeto de negócio do aplicativo. O padrão MVC identifica três papeis que um componente no sistema pode desempenhar. O modelo (Model) é a representação do domínio do problema do aplicativo, aquilo com que ele trabalha. A visão (View) é a parte do programa que interage com o usuário, apresentando para ele formulários de entrada, imagens, textos ou componentes. A visão não precisa ser gráfica. Em um programa baseado em voz, por exemplo, os prompts falados são a interface (Crane, Pascarello e James, 2007). A principal regra do MVC é que a visão e o modelo não devem conversar entre si. Aparentemente é um programa bem disfuncional, mas é aqui que o controlador (Controler) entra. Quando o usuário pressiona um botão ou preenche um formulário, a visão informa isso ao controlador. O controlador então manipula o modelo e decide se as alterações no modelo requerem uma atualização da visão. Se requererem, informa à visão como alterar a si mesma (Crane, Pascarello e James, 2007). A vantagem desse padrão é que o modelo e a visão permanecem fracamente acoplados, isto é, um não conhece o outro profundamente, conforme pode ser observado na Figura 5. 17

29 Visualização 4. Atualiza Visualização 1. Interação Controlador 3. Notifica alterações 2. Modifica Modelo 2.5 Tecnologias similares Figura 5. Principais Componentes do padrão MVC Fonte: Crane, Pascarello e Jame. (2007). Nesta seção são apresentadas frameworks de desenvolvimento web desenvolvidos em Java e que possuem visão em Ajax ou programação em camadas ou ambos ICEFaces ICEFaces é um framework para desenvolvimento de aplicações utilizando Ajax. Feito totalmente em Java EE, ele utiliza a tecnologia JavaServerFaces (JSF) para modelar seus componentes, e não utiliza nenhum componente específico de certos browsers, tornando a aplicação portável para vários browsers, além de ser gratuito, possui seu código fonte aberto (ICESOFT TECHNOLOGIES INC, 2006). A Figura 6 apresenta uma aplicação desenvolvida utilizando o ICEFaces. 18

30 Figura 6. Tela de Demostração do ICEFaces. Fonte ICEsoft Technologies Inc (2006) Struts Segundo Husted et al. (2003), o Struts é um framework gratuito, de código fonte aberto, que auxilia a construção de aplicações para a Web. Ele é construído em Java, e sua principal utilidade consiste numa camada de controle flexível baseada nas tecnologias Java Servlets, JavaBeans, ResourceBundles e XML. O Struts favorece o desenvolvimento de aplicações seguindo o paradigma MVC. É fornecido um componente Controller e se integra a outras tecnologias para oferecer suporte aos componentes Model (como JDBC, EJB s, etc.), e View (como JSP, XSLT, etc.). Segundo Goetten (2007), o Struts foi criado por Craig R. McClanahan e doado para a fundação Apache em É uma implementação de código aberto do modelo MVC-2, bem similar ao MVC, com pode-se ver na Figura 7. 19

31 Figura 7. Tecnologia envolvidas no Struts. Fonte Goetten (2007). Segundo Costa (2007), o Struts pode ser dividido em três componentes: Model, View e Controller. 1. Componentes Model: Os componentes Model englobam dois conceitos: a lógica de negócio da aplicação e seu estado. 2. Componentes View: Os componentes View representam a visão da aplicação, ou seja, a maneira como o sistema interage com o usuário. Nessa camada, o Struts oferece suporte a dois importantes aspectos: internacionalização (disponibilizar o sistema em idiomas diferentes) e construção de interfaces JSP através de tags customizadas. Segundo Costa (2007), para permitir a internacionalização, é necessário que se crie, sob o diretório WEB-INF/resources da aplicação, um arquivo chamado ApplicationResources.properties, que conterá mensagens para a linguagem padrão do seu servidor. As mensagens são colocadas nos arquivos através de strings simples, como: 20

32 app.cliente.nome=nome do cliente: Para possibilitar que se crie mensagens em outras linguagens, é necessário criar o arquivo ApplicationResources_xxx.properties, onde xxx será o nome ISO da linguagem a ser utilizada. Segundo Costa (2007), outro importante recurso é a disponibilidade de tags customizadas (custom tag s) do Struts, que permitirá, além da utilização dos arquivos de internacionalização, uma série de funcionalidades, que, na grande maioria dos casos, dispensará a utilização de código Java dentro da página (aliás, esse é um dos objetivos da arquitetura MVC, pois o fluxo de controle e lógica de negócio da aplicação não devem estar na camada de visão). Além disso, a extensibilidade de Java permite que o próprio desenvolvedor crie suas próprias custom tag s, que, aliás, é uma tarefa bastante simples. As custom tag s do Struts são divididas em cinco bibliotecas: html: permite a criação e manipulação integrada de formulários HTML com o Struts; logic: permite a criação de estruturas de condição e repetição, além da administração do fluxo da aplicação; bean: permite a criação e manipulação de JavaBeans 1 dentro da página; nested: permite a definição de modelos de objetos aninhados e a capacidade de representá-los e administrá-los; template: permite a criação de modelos dinâmicos de páginas JSP que compartilham de um formato comum. 3. Componentes Controller Os componentes Controller são responsáveis pelo fluxo da aplicação. O principal componente Controller do Struts é a ActionServet, que é uma extensão de Servlet, exercendo o papel de controlador principal da aplicação. Sua principal função é fazer o mapeamento das requisições do servidor (COSTA,2007). 1 Segundo a Sun Microsystems(2007), A tecnologia de JavaBeans é a arquitetura componente para a plataforma de Java padrão (J2SE). Os JavaBeans são componentes reutilizáreis de software que podem ser utilizados para montar facilmente aplicações sofisticadas. 21

33 Ainda na camada controller, o Struts oferece para os chamados ActionForm beans, ou mais comumente chamados, form-beans. Form-beans são classes Java que estendem ActionForm e se integram a um formulário de entrada de dados em sua aplicação. O conceito dos form-beans é simples: são JavaBeans que contém uma propriedade para cada campo de seus formulários HTML, com seus respectivos métodos getters e setters. Os form-beans não implementam qualquer método, exceto reset e validate, servindo para limpar o conteúdo do formulário e validar seus dados, respectivamente (COSTA,2007) Google Web Toolkit Segundo o Google(2007), o Google Web Toolkit (GWT) é um framework open source desenvolvido em Java para construção de aplicações utilizando Ajax como o Google Maps e Gmail independente do browser utilizado. Com o GWT, o desenvolvedor pode escrever sua aplicação totalmente na línguagem de programação de Java, e o compilador de GWT converte suas classes de Java para Javascript e HTML. O desenvolvimento de aplicações utilizando o GWT é dividido em três etapas: 1. Utiliza alguma ferramenta para desenvolvimento de aplicações em Java, para escrever a aplicação utilizando as bibliotecas fornecidas pelo GWT; 2. Utilize o compilador Java-to-JavaScript para compilar as classes e gerar os arquivo HTML e JavaScript que será utilizado no servidor web; 3. Testar a aplicação nos diversos tipos de navegadores. Segundo o GWT Brasil (2007), através do GWT uma aplicação pode ser completamente desenvolvida em uma única página HTML. Com acesso a banco de dados e efeitos visuais bastante interessantes. Através do framework, não será necessário escrever uma única linha de javascript, tudo é feito através do compilador fornecido, que traduz o código Java para Javascript. Nem toda a API do Java foi traduzida para javascript devido a limitações do próprio javascript. Apesar das limitações a API do GWT é bastante completa possibilitando ainda diversas oportunidades de extensões. 22

34 Uma aplicação escrita em GWT é basicamente dividida em duas partes: Cliente: É o local onde o compilador traduz o código Java para Javascript. Nesse local ocorrem as maiores limitações. Dispõe-se apenas de algumas classes da API java como por exemplo os tipos básicos da linguagem. A maior parte do código escrito no lado do cliente é derivada dos componentes, Widgets, fornecidos pela API. As classes disponibilizadas no pacote com.google.gwt.user.client.ui contém os componentes gráficos. Servidor: Na parte do servidor a liberdade é total, inclusive para usar as novas funcionalidades da API 5.0 do Java. Toda a estrutura de acesso a banco de dados e qualquer outra tecnologia deve permanecer no servidor Hibernate Segundo Bauer e King (2005), o Hibernate é uma ferramenta que mapeia o objeto/relacional para o ambiente Java. O termo mapeamento de objeto/relacional (ou ORM - Object/Relational Mapping) se refere a técnica de mapear uma representação de dados de um modelo de objeto para dados de modelo relacional com o esquema baseado em SQL. O Hibernate não cuida somente do mapeamento de classes em Java para tabelas de banco de dados (e de tipos de dados em Java para tipos de dados em SQL), como também fornece facilidades de consultas e recuperação de dados, podendo também reduzir significantemente o tempo de desenvolvimento gasto com a manipulação manual de dados no SQL e JDBC. O objetivo do Hibernate é de resolver para o desenvolvedor 95% das tarefas de programação relacionadas aos dados comuns de persistência (HIBERNATE, 2005). Para utilizar o Hibernate, é preciso criar arquivos XML relacionando os objetos da aplicação com as tabelas do banco de dados. Cada arquivo XML corresponde a uma classe da aplicação e consequentemente a uma tabela no banco de dados. Neste arquivo é feito o mapeamento dos atributos da classe com as colunas da tabela no banco de dados. 23

35 Para realizar o processo de inserção, atualização e recuperação de dados no banco de dados, é preciso utilizar uma classe chamada SessionFactory (disponibilizada pelo Hibernate). O Hibernate possui também, um arquivo de configuração no formato XML chamado hibernate.cfg. Esse arquivo deve estar junto com os arquivos da aplicação e serve para configurar o Hibernate em relação a Pool de conexão, tipo de driver JDBC a ser utilizado para a conexão com o banco de dados, entre outros. (HIBERNATE, 2005). Na Figura 8, pode ser visto a arquitetura do Hibernate e como ele interage com a aplicação e o banco de dados. Figura 8. Uma visão detalhada da arquitetura do Hibernate Fonte: Hibernate (2005). Algumas definições dos objetos do diagrama: SessionFactory (org.hibernate.sessionfactory): Composto de identidades compiladas para um único banco de dados. Uma fábrica para Session e um cliente de ConnectionProvider. Pode conter um cachê opcional de dados (segundo nível) reutilizáveis entre transações, no nível de processo ou cluster; 24

36 Session (org.hibernate.session): Objeto de vida curta, representando uma conversação entre o aplicativo e o armazenamento persistente. Cria uma camada sobre uma conexão JDBC. É uma fábrica de Transaction. Possui um cachê obrigatório (primeiro nível) de objetos persistentes, usado para navegação de objetos e pesquisa de objetos pelo identificador; Objetos persistentes e coleções: Objetos, de vida curta, contendo estado persistente e função de negócios. Esses podem ser JavaBeans, onde a única coisa especial sobre eles é que são associados a (exatamente uma) Session. Quando a Session é fechada, eles são separados e liberados para serem usados dentro de qualquer camada da aplicação; Objetos e coleções transientes: São instâncias de classes persistentes que ainda não estão associadas a uma Session. Eles podem ter sido instanciados pela aplicação e não persistido (ainda) ou eles foram instanciados por uma Session que foi encerrada; Transaction (org.hibernate.transaction): Objeto de vida curta, usado pela aplicação para especificar unidades atômicas de trabalho. Abstrai o aplicativo de lidar diretamente com transações JDBC, JTA ou CORBA. Uma Session pode, em alguns casos, iniciar várias Transactions; ConnectionProvider (org.hibernate.connection.connectionprovider): Uma fábrica de (e combinações de) conexões JDBC. Abstrai a aplicação de lidar diretamente com Datasource ou DriverManager. Não exposto para a aplicação, mas pode ser implementado ou estendido pelo programador; TransactionFactory (org.hibernate.transactionfactory): Uma fábrica para instâncias de Transaction. Não exposta à aplicação, mas pode ser extendida/implementada pelo programador. 25

37 3 PROJETO Para este projeto foi utilizado a tecnologia Java para o desenvolvimento dos componentes com o uso de Servlets e JSP. Os componentes básicos utilizam-se de Ajax para fazer a comunicação assíncrona com o servidor e fazer validações. Para a criação das telas de lista e detalhe, foi utilizado XML para informar os dados a serem apresentados e XSLT para a criação do layout dessas telas. 3.1 Modelagem do Sistema A modelagem do sistema foi realizada com a utilização do paradigma de orientação a objetos. Para a modelagem UML foi utilizado o software Enterprise Architect. A seguir serão apresentados os requisitos funcionais, não funcionais, regras de negócio e diagrama de classes que foram utilizadas para a criação do framework Requisitos Funcionais RF01. O framework deverá permitir ao usuário criar novas telas; RF02. O framework deverá permitir ao usuário escolher layouts de telas préconfiguradas; RF03. O framework deverá permitir ao usuário alterar as telas pré-configuradas; RF04. O framework deverá oferecer componentes para a confecção de novas telas; RF05. Os componentes devem receber conteúdo dinamicamente Requisitos Não Funcionais RNF01. As telas deverão utilizar Ajax e JavaScript para atualizar o seu conteúdo; RNF02. O layout das telas deverá utilizar o padrão Tableless (sem tabelas), utilizando o CSS;

38 RNF03. Os componentes receberão o conteúdo a ser exibido através de um documento XML; RNF04. Os documentos XML serão validados através de um XML Schema; RNF05. O framework utilizará o padrão de projeto MVC; RNF06. Os componentes devem se comunicar assincronamente com o servidor utilizando o Ajax para fazer validações; RNF07. O framework deve ser compatível com o padrão do W3C. RNF08. O layout das telas de lista e detalhe deverá ser feita com a utilização de documentos XSLT Regras de Negócio RN01. As novas telas podem ser dotadas de componentes do framework ou de componentes básicos do HTML; RN02. A alteração das telas pré-configuradas referem-se a estender as classes e sobrescrever alguns de seus métodos Diagrama de Classes O diagrama de classes deste projeto está dividido em pacotes para melhor visualização. No primeiro pacote, chamado componentes básicos, estão as classes responsáveis por criar as tags HTML. No segundo pacote, denominado componentes personalizados, estão classes que criam componentes HTML personalizados. No terceiro pacote, chamado telas personalizadas, estão as classes responsáveis por criar as telas. A Figura 9 mostra como estão estruturados esses pacotes. 27

39 Figura 9. Diagrama de Pacotes Componentes Básicos O pacote componentes básicos, de acordo com a Figura 10, contém as classes que irão criar os componentes básicos do HTML, como campo text, checkbox, textarea, etc. O diagrama foi dividido em três partes para melhor visualização. No anexo I pode-se encontra o dicionário de dados com todas as classes e seus principais métodos. 28

40 (a) 29

41 (b) 30

42 (c) Figura 10. Diagrama de classes Componentes Básicos (a) Parte 1, (b) Parte 2, (c) Parte 3. 31

43 Componentes Personalizados O pacote componentes personalizados, de acordo com a Figura 11, contém as classes que criam componentes que serão tratados pelo Ajax para inserção de conteúdo dinâmico na tela, ou seja, é a partir destes componentes que serão criados as tags div do HTML, que o Ajax saberá onde inserir os conteúdos. Além das classes que compõem esse pacote, encontra-se na Figura 11 algumas classes do pacote componentes básicos que servem de base para a criação das classes do pacote componentes personalizados. No Anexo I encontra-se o dicionário de dados com todas as classes e seus principais métodos. Figura 11. Diagrama de Classes Componentes Personalizados Telas Personalizadas O pacote Telas Personalizadas, de acordo com a Figura 12, contém as classes que irão criar os modelos de layouts de telas como lista, detalhe e cadastro. Essas classes podem ser 32

44 estendidas para a criação de novos layouts. A criação da tela é composta pela união do arquivo XML com os dados e um documento XSLT que é obtido através de um Servlet. O JavaScript funde os dois arquivos resultando na tela final. No Anexo I encontra-se o dicionário de dados com todas as classes e seus principais métodos. 33

45 Figura 12. Diagrama de Classes Tela Personalizadas 34

46 3.2 Implementação A implementação do sistema foi feita utilizando a linguagem de programação Java, mais especificamente JSP e Servlets. Além do Java, foi utilizado JavaScript e Ajax para implementar a comunicação com o servidor e atualizar as páginas. Todo o layout das telas foi feito utilizando CSS Componentes Básicos Os componentes básicos são um conjunto de classes Java que tem como principal função criar as tags dos componentes HTML. As classes têm o mesmo nome das tags HTML para melhor compreensão. Todos os componentes possuem um método chamado gethtml() que retorna o código HTML que será enviado para o navegador. O componente Text possui métodos para fazer a validação do seu conteúdo com o servidor utilizando Ajax. Para fazer a validação, é necessário informar ao componente o endereço de uma página que retorna um arquivo XML contendo o status da validação e uma possível mensagem de erro. O componente por sua vez, utilizando o Ajax, envia o seu conteúdo para o endereço informado. O componente Select, possuí métodos para atualizar qualquer parte da tela assincronamente de acordo com o valor selecionado Componentes Personalizados Os componentes personalizados são um conjunto de classes Java que constroem os componentes HTML que não possui no HTML padrão Tabela Cria uma tabela semelhante à tabela HTML, a principal diferença é que cada linha da tabela pode expandir e receber um conteúdo dinamicamente utilizando Ajax. Esse conteúdo pode ser uma outra página da própria aplicação ou uma outra página qualquer. A Figura 13 mostra o resultado de uma página que ao clicar no curso, a linha se expande automaticamente mostrando o detalhe do registro. 35

47 (a) 36

48 (b) (c) Figura 13. Tabela (Componente Personalizado). (a) Código fonte (b) Lista inicial. (c) Lista ao clicar no link Computação na linha Menu Componente responsável por criar um menu na tela. O menu é composto por um painel superior onde pode-se escolher qual página será chamada e um painel de visualização onde serão apresentadas as páginas. O painel de visualização é populado assincronamente com o Ajax. A Figura 14 mostra um exemplo de um menu utilizando o componente Menu. (Localizado na parte superior da figura). 37

49 Figura 14. Exemplo de um menu Telas Personalizadas As telas personalizadas são um conjunto de classes que criam alguns tipos de telas como lista, detalhe e cadastro. Essas telas utilizam CSS para formatar o seu layout Formulário O componente do tipo formulário cria uma tag HTML do tipo form e dentro desta tag pode-se adicionar textos e componentes do framework. A classe Formulario trata a disposição desses elementos e executa automaticamente o método gethtml dos componentes adicionados a ele para construir a interface. Este possui um método chamado addcomponente, onde os componentes são adicionados ao formulário. Esse método é composto de três parâmetros: Componente: Neste parâmetro é informado o componente a ser adiciona do formulário (como um componente Text ou Select); Label: Neste parâmetro é informado um label que será apresentado junto como o componente adicionado. Posição: Indica onde estará localizado o label do componente adicionado. O valor desse parâmetro pode ser adquido das constantes TOP ou LEFT, onde posiciona o label em cima do componente ou a esquerda do mesmo respectivamente. 38

50 Mesma Linha: Este parâmetro é opcional e indica se haverá uma quebra de linha após o componente. Caso não seja informado o valor deste parâmetro, será inserido a quebra de linha. O formulário ainda possui uma funcionalidade que ao executar o submit envia os seus dados para a URL informada e insere o conteúdo de retorno da URL submit para o id especificado através do método setidupdateenviar. Abaixo, na Figura 15, pode-se observar a construção de um formulário. (a) 39

51 Figura 15. Criação de um formulário; (a) Código; (b) Formulário resultante (b) Lista O componente do tipo lista cria uma lista de elementos na tela com botões de controle como Novo, Alterar, Excluir e Voltar, sendo que o texto desses botões pode ser personalizado pelo desenvolvedor. Ainda a lista oferece a possibilidade de inserir novos botões de controle. A lista é populada por um XML especificado pelo método seturlxml. O componente junta esse XML com um XSLT que é obtido através do servlet Lista_xslt. Por sua vez esse servlet chama o método getxslt do componente lista, então o Ajax junta os dois documentos formando a lista. A Figura 16 mostra a seqüência de criação de uma lista. 40

52 Figura 16. Diagrama de Seqüência - Criação de uma tela lista Detalhe O componente detalhe herda as características da lista. A única diferença é o documento XSLT que é retornado para juntar com o documento XML para construir a interface. A Figura 17 mostra a seqüência de criação de um detalhe. 41

53 Figura 17. Diagrama de Seqüência - Criação de uma tela de detalhe 3.3 Protótipo Esta seção apresenta a interface de um protótipo desenvolvido utilizando o framework desenvolvido. O protótipo consiste em um sistema de gerenciamento de turmas de uma instituição de ensino. O sistema possui uma interface de cadastro e listagem de alunos, professores, disciplinas e uma tela onde o usuário pode criar uma turma de acordo com os alunos, professores e disciplinas cadastradas anteriormente. Esse protótipo possui uma interface onde o menu para a seleção das telas a serem visualizadas fica na parte superior da tela e lista as informações e exibe o formulário para a alterar essas informações na mesma tela Tela Inicial do Protótipo A Figura 18 exibe a tela inicial do protótipo. Essa tela é composta por um menu superior onde o usuário pode escolher qual tela será exibida. Essa tela será carregada abaixo do menu sem recarregar toda a página novamente. O componente menu encontra-se no pacote componentes personalizados do framework. 42

54 Figura 18 - Tela Inicial do Protótipo Para a criação do menu, foi necessário apenas informar qual seria o texto apresentado em cada menu e o endereço da página a ser apresentada como pode ser observado na Figura

55 Figura 19. Código fonte para a criação do Menu Telas de Cadastro do Protótipo Todas as telas de cadastro, exceto a de cadastro de turma, seguem o mesmo padrão. Elas possuem um formulário na parte superior, onde serão inseridos e alterados os registros e uma lista na parte inferior, onde serão visualizados os registros. Ao clicar sobre um registro da coluna código, o formulário será preenchido automaticamente com as informações deste registro e ficando habilitado para alterar o registro quando clicado no botão enviar. 44

56 Ao clicar em um registro da coluna de descrição, a lista sairá da tela, dando lugar a uma tela de detalhes do registro selecionado. Para inserir um novo registro, basta preencher o formulário e clicar sobre o botão enviar. A lista será atualizada com o novo registro. Todo o procedimento de atualização das telas é feita utilizando o Ajax. Na Figura 20, pode-se ver a tela de cadastro de curso, com um formulário na parte superior e a lista de cursos na parte inferior. O formulário tem os campos nome e período como sendo obrigatórios (como pode ser visto na linha 22 e 26 respectivamente), ou seja, o formulário não executará o submit até que esses campos sejam preenchidos. (a) 45

57 Figura 20. Tela de Cadastro de Curso. (a) Código para a criação da tela, (B) Tela de Cadastro (b) Na tela de castro de Turma, foi inserido ao invés de uma lista do pacote Telas Personalizadas, uma tabela do pacote Componentes Personalizados. Esse procedimento foi feito para que ao clicar sobre uma turma, a tabela se expandisse e mostrasse todos os alunos que fazem parte da turma, como pode ser visto na Figura