1
G
Módulo
RIA, Extensions e
SOA (BPM e WS/RS)
.A
Este módulo introduz novidades das versões 5.5.x e 6.0.x do jCompany Developer
Suite, em áreas de grande impacto no desenvolvimento de sistemas atuais, tais
como:
o Rich Internet Application: incorporação de recursos Web 2.0 via jQuery, jQuery UI, jQuery
Plugins e jQuery UI Theme Roller, para máxima usabilidade.
o jCompany Extensions: mecanismos de extensão avançados que mesclam recursos de OO do
novo padrão CDI com complementos de Geração de Código do jCompany para formarem um
poderoso instrumento para arquitetos de software definirem novos padrões, do zero ou via
customizações dos disponíveis no jCompany.
o SOA - BPM: integração de referência com solução de Business Process Management (BPM),
trazendo padrões de interação de formulários corporativos desenvolvidos em jCompany com
motores externos de BPM, utilizando o jBPM.
o SOA - JAX-WS 2.0: uso de Web-Services tradicionais, com protocolo SOAP, WSDL, etc., através
de padrões Java EE robustos e de alta produtividade.
o SOA - JAX-RS 1.0: uso de RESTful Web-Services sobre HTTP, com tráfego JSON, XML ou
Text/Plain e também através de padrões Java EE robustos e de alta produtividade
2
Capítulo
Rich Internet Application
(RIA) com jQuery
1
A
22
RIA (Rich Internet Application) no jCompany
- Níveis de RIA no jCompany
Aplicações de Internet são consideradas "ricas" quando incorporam características e funcionalidades
mais típicas de softwares Desktop, ou mesmo superam recursos deste ambiente, como é o caso de
Mashups (recursos que mixam dados de aplicações de negócio e serviços externos, como Google Maps,
por exemplo). Soluções de RIA típicas transferem a maior parte do processamento da interface para o
navegador (Browser), porém preservando a maior parte dos dados e as regras de negócio no servidor de
aplicação.
Em lugar de radicalizar neste aspecto, passando totalmente os recursos de visão para a máquina cliente
(algo que traz também sequelas, como programação intensiva de Javascript ou linguagens menos
robustas e disseminadas relacionadas a Flash, por exemplo), o jCompany oferece um suporte gradual ao
uso de tecnologias RIA, em 3 níveis:
o
Basic: permite que se introduzam componentes de RIA em aplicações existentes, modo
organizado, compreensivo e performático - tanto em tecnologia JSF/Facelets quanto JSF/Tiles ou
mesmo Struts/Tiles, mais antigas. Alguns recursos embutidos e facilmente ativáveis são: autocomplete e seleção Popup modal para vinculados, máscaras mais flexíveis em campos, campos
com altura dinâmica (autogrow), Google Maps para endereços, dentre outros Widgets jQuery UI
como datepicker, introduzidos com a tecnologia Unobstrusive Javascript do jQuery, o que
dispensa alterações em aplicações existentes para serem ativados (pouco intrusivos).
o
Advanced: quando utilizando os novos leiautes via Facelets, o jCompany oferece o uso de Ajax
e jQuery mais refinado, complementando os recursos básicos acima com diversos outros:
redução quase total de submissões "não Ajax" (eliminação de recargas total do navegador),
substituições de trechos menores de formulários nas operações padrões de CRUD via Ajax
(maior performance), processamento do "conforto visual" (esconder itens de menu, abas ou
botões) "no cliente", sobre HTML estático, uso de Widgets jQuery UI para Tab-Folder, Menus e
outros componentes visuais.
o
Extremme (Versão Futura): leva praticamente toda a camada controle para o cliente,
eliminando a necessidade de JSF e outras tecnologias de "camada Visão no servidor",
basicamente operando com HTML estático + Javascript/Widgets e recursos de JAX-RS/AtomPublisher para operacionalizar os formulários - em uma arquitetura RIA mais purista ou extrema.
Importante: o RIA Extremme ainda não está disponível na versão 6.0, sendo prevista para
próximas grandes versões. A versão 6.0 tem foco na incorporação de tecnologias Java EE 6, mas
já traz diversas "partes" do RIA Extremme disponíveis, como JAX-RS 2.0/Atom via jCompany
Services e todos os recursos do RIA Advanced (é base para o RIA Extremme).
Neste capítulo iremos introduzir os recursos "Basic" e "Advanced" para um uso diligente e progressivo de
tecnologias RIA nas aplicações produzidas com jCompany. Isso evita armadilhas típicas de adoção
precoce de uma versão mais extrema, pavimentando caminho para um balanceamento mais maduro
destes recursos, na medida em que amadurecem no mercado.
- jQuery, jQuery UI, jQuery UI Theme Roller e jQuery Plugins
A principal tecnologia de "cliente RIA" adotada no jCompany é também a mais popular dentre as opções
conhecidas: o jQuery e sua arquitetura de Javascript "não intrusivo" ou "não obstrutivo". Esta
elegante e performática arquitetura tomou de assalto o mercado por utilizar um tipo de Design Pattern
"Decorator" para, sem intervenção em um documento HTML gerado (ou estático), introduzir
componentes ricos e poderosos no cliente, conhecidos como Widgets.
4
Capítulo G22
A arquitetura extensível do jQuery também produziu uma das comunidades mais vibrantes nesta área,
que já disponibiliza, literalmente, milhares de plugins (Widgets, utilitários, etc.) para reuso, gratuitos em
sua maioria - e facilmente incorporáveis ao jCompany, como veremos.
A opção por fazer RIA com Browsers e HTML/Javascript, ao menos como primeira opção, é também
natural já que se trata da plataforma mais exigida pelo mercado - e especialmente promissora com a
evolução recente do mercado de navegadores através do Chrome, HTML 5, etc.. Além disso, linguagens
de script como o Javascript estão mais populares e ganham presença mesmo em servidores e outras
engines como o Eclipse BIRT.
Finalmente, o jQuery foi laureado em uma avaliação do Gartner Group de Dezembro/2008 como uma das
tecnologias principais para RIA, dada sua arquitetura, comunidade, arquitetura elegante e aderente aos
padrões Web.
- JAX-RS/jBoss RestEasy e Atom Publishing Protocol (AtomPub)
A maior parte dos componentes RIA precisam comunicar-se com o servidor e devem fazê-lo via Ajax,
para o resultado esperado. A tecnologia de servidor para recepção de mensagens RIA adotada no
jCompany foi o JAX-RS (padrão Java EE 6) via jBoss RestEasy (implementação de referência do padrão
JAX-RS).
Portanto, serviços REST genericamente construídos estão disponíveis para servir dados para
componentes RIA, funcionando quaisquer que sejam os grafos de entidades ou propriedades envolvidos.
Estes serviços são automaticamente habilitados via declarações simples e servem dados nos formatos
Text-Plain, JSON e AtomPub. Os dois últimos são utilizados quando se pretende fazer todo o CRUD
(Incluir, Recuperar, Atualizar e Excluir) de agregações de objetos (Mestre/Detalhe/SubDetalhe) via REST,
o que será melhor abordado nos próximos capítulos.
Reutilizando componentes RIA "prontos para uso"
- Reutilizando componentes RIA integrados a componentes JSF
Componentes RIA "prontos para uso" no jCompany podem ser acionados através do uso de um novo
atributo "riaUsa" disponíveis em diversos componente JSF.
O desenvolvedor deve inserir a chamada ao componente com o seguinte padrão:
riaUsa="nomeComponenteRIA(parâmetro1='valorDoParâmetro1', etc.)".
Essas configurações permitem que o XHTML, ao ser compilado, busque o componente utilizado e o
renderize de maneira não obstrutiva. A Figura G22.1 mostra o exemplo da configuração RIA
autocomplete e seus parâmetros.
Figura G22.1. Configurações no riaUsa de um componente vinculado, para ativar o Widget "autocomplete".
Note que o Widget chama "autocomplete" e que recebe como argumento, neste caso, apenas uma "url"
(diversos outros argumentos podem estar disponíveis, conforme cada Widget). Apenas com esta
declaração, um complexo comportamento de "Auto Complete" será ativado no campo de descrição de
componentes "vinculado": a verificação de digitação, seguida por uma chamada Ajax/REST contra um
serviço genérico no padrão JAX-RS e por fim a apresentação do resultado ao usuário através de um
"combo dinâmico" que permite uma seleção dentre a lista de valores retornados, com filtro local, ao final
dos resultados.
No caso específico deste componente, argumentos como "mínimo de letras digitadas para a pesquisa",
"máximo de itens apresentados no combo", dentre outros, podem ser informados, conforme
documentação do próprio componente.
- Implementando recursos de "auto-complete" em vinculados
Vamos ver a facilidade para se incorporar recurso de auto-complete (típico de aplicações RIA,
popularizado pelo Google), em todos os componentes do tipo "vinculado" (listas Popup), de nossa
aplicação. A Figura G22.2 mostra um exemplo de auto-complete em um XHTML de manutenção que
seleciona "cargo", com explicações sobre como é possível se definir este recurso, para quaisquer outros
casos.
Rich Internet Application (RIA) com jQuery
Figura G22.2. Configuração para "auto-complete". O parâmetro "url" contém o caminho do serviço JAX-RS que
será utilizado para recuperar as informações e a propriedade "nome" será o parâmetro de pesquisa utilizado.
#1. O segredo para se ativar o auto-complete para qualquer caso é o parâmetro "url". Ele deve ser
fornecido incluindo as partes fixas abaixo e substituindo-se as variáveis entre colchetes, de
acordo com cada caso:
'/[nome do projeto]/soa/service/autocomplete.[nome da colaboração]?[nome do campo]'.
A Figura G22. mostra o resultado desta configuração do autocomplete.
Figura G22.3. Widget "auto-complete" funcionando em um projeto jCompany.
Vamos então aplicá-lo, customizando diversos elementos (total de caracteres digitados, máximo
retornado, etc.), para um caso de uso que implementamos na aplicação rhtutorial, ficando o
desenvolvedor incumbido de replicar esta implementação para os demais casos:
1.
Selecione o projeto rhtutorial, abra o diretório "src/main/webapp/WEBINF/fcls/unidadeorganizacional" para editar o arquivo "unidadeorganizacionalMan.xhtml".
A Figura G22.4 mostra o caminho até o XHTML de manutenção.
Figura G22.4. Caminho para o formulário a ser editado.
2.
Digite as propriedade "riaUsa" com parâmetros conforme abaixo, na tag "plcf:vinculado":
riaUsa="autocomplete(url='/rhtutorial/soa/service/autocomplete.unidadeorganizacionalman?q=nom
e', tamanhoMinimo='2', tamanhoLista='3')".
Note que os parâmetros "tamanhoMinimo" e "tamanhoLista" não foram usados anteriormente por
não serem obrigatórios. Eles tratam, respectivamente, do número mínimo de caracteres digitados
para que o autocomplete funcione e do número máximo de resultados que aparecerão no "combo
dinâmico" do auto-complete. A Figura G22.5 mostra as configurações feitas no XHTML de
manutenção.
Capítulo G22
Figura G22.5. Alterações feitas no XHTML de manutenção da lógica "unidadeorganizacional"
3.
Acesse a aplicação e verifique a funcionalidade do auto-complete. A Figura G22. mostra o vinculado
da lógica "Unidade Organizacional" com o componente "autocomplete" ativado.
Figura G22.6. Auto-complete sendo ativado com duas letras e mostrando apenas três resultados.
- Implementando uma "seleção auto-complete".
Esta é uma variação da funcionalidade acima, que também recupera dados de uma entidade através de
uma popup e auto-complete, mas sem requerer um vinculado como componente. Ela funciona de
maneira análoga ao vinculado, mas em campos texto comuns (plcf:texto), sem retornar uma chave
primária associada à descrição, como no primeiro caso. A Figura G22.7 mostra um exemplo deste tipo de
seleção caso quiséssemos buscar descrições de cidades de uma base para replicar no formulário (sem
Object-Id referenciando esta base).
Figura G22.7. Configurações no riaUsa de um projeto jCompany.
#1. O parâmetro "url" fornece para o componente RIA o caminho da lógica de seleção que será
recuperada.
#2. O parâmetro propSelPop fornece para a seleção o campo presente que fará a busca.
A Figura G22.8 mostra o resultado visual deste componente.
Figura G22.8. Widget "selecao" em um projeto jCompany.
Não iremos aplicar no rhtutorial por se tratar de um recurso com funções equivalentes às do vinculado (e
considerando que não existe caso aplicável).
- Implementando "autogrowtextarea" (altura dinâmica) em campos tipo "area".
Este outro plugin jQuery modifica a altura de um campo "area" do jCompany (texto com múltiplas linhas)
dinamicamente, em função de seu conteúdo. A Figura G22. mostra um exemplo deste plugin no XHTML
de manutenção.
Rich Internet Application (RIA) com jQuery
Figura G22.9. Configuração de "altura dinâmica" para campo "textarea"
#1. O parâmetro "tamanhoMaximo" estabelece o maior tamanho em caracteres que o campo pode
assumir.
A Figura G22. mostra um exemplo de "autogrowtextarea" funcionando em uma aplicação jCompany.
Figura G22.10. Widget "autogrowtextarea" em um projeto jCompany.
Este é um componente trivial. Procure componentes "area" na aplicação que desenvolvemos para ativar
este recurso nos locais desejados.
- Implementando múltiplos componentes RIA em um mesmo componente (datemask e datepicker).
O componente de "datepicker" (seleção de datas em calendário) possui diversos argumentos
interessantes e o "datemask" oferece apoio durante a digitação livre.
Para definir mais de um componente, como neste caso, separe-os com ponto e vírgula, conforme abaixo.
A Figura G22. mostra um exemplo de datemask e datepicker no XHTML de manutenção, com argumentos
customizados.
Figura G22.11. Configurações no riaUsa de um projeto jCompany.
A Figura G22. mostra o efeito da customização acima.
Figura G22.12. Componentes RIA "datemask" e "datepicker" em um projeto jCompany.
Agora vamos aplicar o componente "datemask" e "datepicker" no rhtutorial, aproveitando para fazer uma
pequena customização, como o número de meses que aparecem no calendário, para o caso de uso
padrão "funcionario", que implementamos na aplicação rhtutorial:
1.
Selecione o projeto rhtutorial, entre no diretório "src/main/webapp/WEB-INF/fcls/funcionario" e abra
o arquivo "funcionarioMdt.xhtml". A Figura G22.3 mostra todo o processo.
Capítulo G22
Figura G22.13. Caminho para o formulário a ser editado.
2.
Digite as propriedades riaUsa="datemask; datepicker(meses='3')" na tag "plcf:data". O novo
parâmetro inserido, "meses", indica quantos meses aparecerão no componente para o usuário
selecionar. A Figura G22.14 mostra o XHTML corretamente configurado.
Figura G22.14. Widgets "datemask" e "datepicker" configurados no XHTML de manutenção.
3.
Acesse a aplicação e verifique a funcionalidade do datepicker com a apresentação de 3 meses. Note
que o parâmetro "meses" mostra o mês atual e posteriormente os outros meses configurados. A
Figura G22.25 mostra o componente "datemask" e "datepicker" funcionando corretamente.
Figura G22.25. Widgets "datemask" e "datepicker" funcionando em "/funcionariomdt".
- Implementando "fckeditor" (edição multimídia) nas observações de funcionário.
Este outro plugin jQuery ativa o "fckeditor", editor que permite a gravação de texto em formato HTML em
campos área, podendo incluir formatações, links, etc., via edição visual! A Figura G22.36 mostra um
exemplo de Fckeditor no XHTML de manutenção.
Figura G22.36. Ativação de editor multimídia em campo texto
A Figura G22.47 mostra o resultado funcionando no antigo local onde somente texto era possível.
Rich Internet Application (RIA) com jQuery
Figura G22.47. Widget "fckeditor" em um projeto jCompany.
Agora vamos aplicar o componente RIA "fckeditor" com pequenas customizações no caso de uso padrão
"funcionario" do projeto rhtutorial:
1.
Selecione o projeto rhtutorial, entre no diretório "src/main/webapp/WEB-INF/fcls/funcionario" e abra
o arquivo "funcionarioMdt.xhtml".
2.
Digite, na tag "plcf:area", as seguintes propriedades: riaUsa="fckeditor(width='800',height='250')".
Os novos parâmetros fornecidos, width e height, correspondem respectivamente à largura e altura
da área em que estamos inserindo o componente RIA. Todo o processo é mostrado na Figura
G22.58.
Figura G22.58. XHTML de manutenção com componente riaUsa "fckeditor" configurado.
3.
Acesse a lógica funcionário e verifique o componente RIA "fckeditor" funcionando com a altura e a
largura estabelecidas, conforme 19.
Figura G22.19. Caso de uso padrão "funcionario" com "fckeditor" implementado no campo "observacao".
- Implementando um Mashup para exibição visual de endereço via Google Maps.
Mashups são conhecidos por "mixar" dados de várias fontes distintas para um resultado novo e
interessante. O exemplo mais conhecido é o de mixagem dos dados de endereço de uma aplicação
corporativa, antes restritos à sua exibição "textual", com a apresentação do mesmo com os recursos
multimídia do Google Maps.
A Figura G22. mostra um exemplo de configuração do componente Google Maps em um XHTML de
manutenção.
Capítulo G22
Figura G22.20. Configuração de "Mashup" para apresentação de endereço em um mapa do Google.
#1. O parâmetro mapa fornece o mapa inicial que será exibido, como default deve-se preencher
com "google-maps".
#2. O parâmetro "campo" deve conter campos de referência para a busca do endereço correto no
mapa. Note que podemos informar rua e número somente e algum resultado será retornado,
porém com chances de erro devido a duplicidades. Quanto mais precisos forem os campos (UF,
CEP, etc), melhores as chances de retorno da localização desejada.
#3. Elemento "div" que cria o botão e provê o espaço para efetuar a pesquisa e apresentar o mapa,
respectivamente.
A Figura G22.6 mostra o resultado final ativado no cadastro de funcionário.
Figura G22.6. Mapa exibindo endereço no Google Maps!
Agora que já entendemos como funciona o Mashup Google Maps, vamos aplicá-lo em um formulário do
rhtutorial:
1.
Selecione o projeto rhtutorial, entre no diretório "src/main/webapp/WEB-INF/fcls/funcionario" e abra
o arquivo "funcionarioMdt2.xhtml".
2.
Insira as seguintes propriedades do "googlemaps" na primeira tag "plcf:texto" do XHTML de
manutenção de componente:
riaUsa="googleMaps(mapa='google-maps', googleMapsKey=[CHAVE GERADA],
campo='corpo:formulario:enderecoResidencial_logradouro, corpo:formulario:
enderecoResidencial_numero, corpo:formulario:enderecoResidencial_bairro, corpo:formulario:
enderecoResidencial_cep, corpo:formulario:enderecoResidencial_uf ')". Note que a declaração deste
componente pode ser inserida em qualquer tag do formulário.
Rich Internet Application (RIA) com jQuery
3.
Insira o elemento "div" que irá gerar o botão de pesquisa do mapa no XHTML de manutenção,
conforme Figura G22.72.
Figura G22.72. Elemento "div" que renderiza o botão de pesquisa e a apresentação do mapa.
4.
Execute a aplicação rhtutorial e teste na aba "Endereco", o componente RIA criado.
- Implementando máscaras em textos com o componente RIA "textmask".
Este outro plugin jQuery permite que o desenvolvedor aplique diversos tipos de máscaras em campos
textos. Tal funcionalidade é útil ao desenvolvedor, pois permite que campos como "CPF" ou "CNPJ"
tenham suas características (pontos, underscore, etc) reproduzidas na aplicação. A Figura G22.8 mostra
um exemplo de "textmask" em um campo "cpf".
Figura G22.83. Widget "textmask" configurado para "cpf".
#1. O parâmetro "mask" fornece a máscara criada para a aplicação.
#2. Ao preencher o parâmetro "mask" os números que compõem a máscara devem ser
preenchidos com o valor nove. Isso indica que o valor alocado naquele espaço estará entre zero
e nove.
Agora vamos aplicar a máscara de CPF no campo de mesmo nome da aplicação "funcionario" do projeto
rhtutorial:
1.
Selecione o projeto rhtutorial, entre no diretório "src/main/webapp/WEB-INF/fcls/funcionario" e abra
o arquivo "funcionarioMdt.xhtml".
2.
Dentro da tag "plcf:texto", referente ao campo "CPF", insira a seguinte propriedade:
riaUsa="textmask(mask='999.999.999-99')". Note que a máscara criada é idêntica a usada em um
CPF.
3.
Acesse a colaboração de manutenção do funcionário, do projeto rhtutorial, e verifique no campo CPF
o comportamento do componente RIA. A Figura G22.9 mostra o componente .
Figura G22.9. Componente RIA "textmask".
4.
Note que o campo "CPF" agora exige uma "rolagem lateral" para a exibição completa do valor. Isso
ocorre porque inicialmente o campo "CPF" armazenaria 11 dígitos, e com a adição da máscara, o
valor passou a ser de 14 dígitos! Para adequar o tamanho do campo da tabela à quantidade de
dígitos com a máscara, basta alterar o tamanho do campo na entidade e proceder com a geração da
Capítulo G22
tabela novamente (menu Área Técnica, Geração de DDL/Esquema). A Figura G22.105 mostra a
aplicação funcionário com o campo "CPF" ajustado.
Figura G22.10. "textmask" funcionando após ajustes de tamanho.
Criando novos ou reutilizando outros componentes RIA
- Entendendo os padrões arquiteturais para incorporação de novos componentes RIA
Como dito na introdução deste capítulo, existem milhares de outros plugins jQuery disponíveis para
download livre na Web dentre Widgets e utilitários diversos, além dos citados na seção anterior. Com
tantas opções, uma das formas comuns de se deteriorar consideravelmente a compreensão (e, por
consequência, a manutenibilidade) de uma aplicação é incorporando-se um "punhado" destes
componentes RIA de maneira apressada e com critérios aleatórios, artesanais.
Como estes plugins normalmente envolvem arquivos de Javascript/bibliotecas, mídias, CSS e código
Javascript de Ativação, pode-se facilmente produzir um emaranhado de códigos de difícil leitura e em
diversas linguagens/markups diferentes ao longo de um projeto - um verdadeiro caos!
Em alguns casos estes novos componentes serão utilizados em apenas um formulário, mas o mais
comum é que um mesmo componente tenha potencial de reúso por diversos pontos da aplicação ou
mesmo da empresa. Por este motivo, é altamente recomendável que haja um padrão em nível
arquitetural, bem definido, para sua incorporação.
Para fazer frente a esta demanda, o jCompany provê, além dos componentes RIA prontos para uso que
vimos na seção anterior, uma arquitetura apropriada para se introduzir componentes RIA de
maneira compreensiva, produtiva e performática. Esta "mini-arquitetura" dentro da arquitetura
maior definida pelo jCompany estabelece padrões para acomodação de todos os componentes de um
novo plugin jQuery, bem como para seu código de ativação, utilizando convenções que facilitam também
a passagem de argumentos homologados de um Widget, de modo homogêneo.
Com esta arquitetura, pode-se incorporar dezenas de componentes RIA sem incorrer em aumento
excessivo da complexidade do código ou na introdução de problemas de performance, como downloads
excessivos de arquivos Javascript, de CSS ou de mídia. Este processo de incorporação é baseado nos
passos abaixo:
1.
Identificação e download do componente reutilizável (ou codificação de um novo componente "do
zero"). Para reuso, um excelente começo é pelo site http://plugins.jquery.com/.
2.
Distribuição dos arquivos envolvidos no componente, conforme seu tipo, em diretórios padrões da
aplicação. Os principais diretórios são:
CSS: [aplicacao]/res-plc/css/jquery/
Javascript do Componente: [aplicacao]/res-plc/javascript/jquery/
Mídia: [aplicacao]/plc/midia/jquery
Rich Internet Application (RIA) com jQuery
3.
Codificação do Javascript de ativação (unobstrusive) de modo genérico, seguindo os preceitos
abaixo:
o Selecionar dentre todos os argumentos possíveis do plugin aqueles argumentos mais comuns ou
que se pretende disponibilizar para a empresa utilizar, colocando-os entre #{} no Javascript de
ativação. Ex: "#{mask}" para receber um valor de máscara como utilizado no componente
"textmask".
o Salvar este pequeno trecho de javascript em um arquivo cujo nome define aquele a ser utilizado
no atributo "riaUsa", disponível em todas as principais tags JSF do jCompany.
Ex: textmask.js para que se use riaUsa="textmask(...)"
A Figura G22.14 mostra como exemplo o arquivo Javascript de ativação para o auto-complete.
o
Salvar este arquivo Javascript de acionamento no diretório padrão:
[aplicacao]/src/main/webapp/res-plc/javascript/un ("un" de unobstrusive).
o Ativação/Uso destes componentes em tags JSF, passando os argumentos entre parênteses,
conforme os exemplos que vimos.
Figura G22.116. Exemplo de código RIA Javascript.
#1. As variáveis entre "#{}" recebem os valores passados como argumento nas chamadas
declaradas em "riaUsa".
Veja exemplos dos códigos de ativação dos componentes homologados dentro do projeto
"jcompany_visao/res-plc/javascript/un". Perceba que o "id" é utilizado no padrão #{id} mas não precisa
ser passados nas chamadas do "riaUsa" - ele é substituído pelo jCompany pelo "id" do componente JSF
onde o "riaUsa" é declarado.
- Otimizando o download de CSS e Javascript
Imagine que cada componente RIA de um total de 30 reutilizados em uma aplicação corporativa tenha 5
arquivos em média: 1 CSS, 1 Javascript e alguns de mídia (png, gif, etc), além do Javascript de ativação.
Em certo momento da chamada desta aplicação pode-se demandar o download de mais de uma centena
de recursos em diversas chamadas HTTP, degradando a performance consideravelmente.
Para evitar esta escalada de degradação, a arquitetura do jCompany utiliza um recurso poderoso para
garantir o máximo de performance no uso de CSS, Javascript e Mídias, em um ambiente RIA:
1.
Um arquivo "plc.comuns.css" importa todos os arquivos "css" utilizados na aplicação em um único
ponto, garantindo que apenas um download de CSS será realizado em uma única conexão HTTP (há
algumas exceções, para os arquivos CSS trocados dinamicamente pelo usuário, específico de cada
pele).
2.
Outro arquivo "plc.comuns.js" importa todos os arquivos Javascript utilizados na aplicação, de forma
similar ao CSS.
3.
Além disso, o download dos dois arquivos acima ocorre uma única vez na vida da aplicação, graças a
diretivas de caching incluídos automaticamente pelo jCompany no header de cada resposta HTTP,
Capítulo G22
definindo um "max-age" para estes recursos que evitam sua recarga a cada requisição, por
exemplo. (exceto se o usuário clicar no "reload/refresh" do Browser)
Para preservar este mesmo ganho de performance em sua aplicação, o desenvolvedor deve
cadastrar todos os seus arquivos css (folha de estilo) e js (Javascript) nos seguintes facilitadores:
"app.comuns.js" e "app.comuns.css".
Esses arquivos possuem as mesmas funções do "plc.comuns.css" e do "plc.comuns.js". A Figura
G22.12 e a Figura G22.13 mostram os arquivos CSS e Javascript declarados, para um hipotético
componente "richWindow" que possua estes arquivos com mesmo nome:
Figura G22.127. Padrão de declaração de um arquivo CSS no "app.comuns.css".
#1. Função de importação padrão de códigos CSS.
#2. Indica que será inserida uma URL.
#3. Caminho de contexto, ou seja, ele irá pegar o caminho do projeto principal até as pastas em
que se encontram os arquivos CSS. No caso do rhtutorial, o contextPath representaria o
seguinte caminho: rhtutorial\src\main\webapp
#4. Caminho para o arquivo CSS do componente.
Figura G22.138. Padrão de declaração de um arquivo Javascript no "app.comuns.js".
#1. Indica que será escrito no documento um script. Declaração padrão Javascript.
#2. Início do script. Declaração padrão Javascript.
#3. Caminho do contexto, funciona de maneira análoga ao contextPath do "app.comuns.css".
#4. Caminho para o arquivo Javascript do componente.
#5. Fim do script.
É ainda importante que o desenvolvedor entenda e utilize corretamente o modo de execução de sua
aplicação, pois ela influirá decisivamente na maneira como estes arquivos serão servidos em requisições
HTTP.
Quando utilizamos as rotinas Maven de desenvolvimento, a aplicação final (WAR ou EAR) é "carimbada"
no "web.xml", com um parâmetro que indica para o framework que ela está executando "em modo de
desenvolvimento". Este parâmetro é o "modoExecucao=D" (default). Neste caso,nenhuma otimização é
feita, para facilitar a alteração e testes de CSS e Javascript. Já quando usamos alguma rotina de
"Liberação para Produção", este parâmetro é alterado para "modoExecucao=P", e o download de CSS e
Javascript é otimizado, conforme abaixo:
1.
Modo de Desenvolvimento ("modoExecucao=D"): a aplicação continua servindo todos os arquivos
declarados no "app.comuns.css" e no"app.comuns.js" em separado, bem como "plc.comuns.css" e
"plc.comuns.js". Isso viabiliza com que mudanças sejam prontamente liberadas por hot-deploy, por
exemplo.
2.
Modo de Produção ("modoExecucao=P"): com a aplicação neste modo, um "Filter" do jCompany
realiza uma leitura inicial de todos os arquivos CSS ou Javascript declarados, tanto em
"plc.comuns.*" quando em "app.comuns.*", e os serve para o Browser como um único arquivo,
reduzindo drasticamente o número de chamadas HTTP realizadas para se renderizar uma página.
Existe ainda um estado de "modoExecucao=T", utilizado principalmente pelo jCompany QA Suite, que
habilita facilitadores para testes funcionais e também usa a otimização para que possa ser averiguada em
um ambiente de Integração Contínua, por exemplo.
Rich Internet Application (RIA) com jQuery
Sumário
Neste capitulo, discutimos brevemente sobre RIA, envolvendo jQuery e JAX-RS, utilizadas no jCompany
para implementar duas modalidades (graduações) de RIA: Basic e Advanced.
Conhecemos alguns dos principais componentes de RIA disponíveis e vimos a facilidade com que
conseguimos ativá-los, com pouca intrusão e risco de problemas.
Por fim, entendemos a arquitetura que o jCompany provê para que se incorpore um grande número de
componentes RIA (plugins jQuery) sem perda de controle e de performance/escalabilidade.