com jcompany Extensions Capítulo Expandindo o Poder do jcompany Developer Suite - Entendendo as melhores práticas de customização

Expandindo o Poder do jCompany Developer Suite - Entendendo as melhores prátic as de c ustomizaç ão

E

E

xercitamos em vários capítulos as possibilidades de extensão do jCompany FS Framework através de herança, especialmente através do DP Template Method nas camadas de controle (*Action) e modelo (*Manager ou *BO). Além disso, vimos que o jCompany também traz uma arquitetura rica e extensível na camada visão, seja de "cliente" (Javascript, Ajax, CSS, HTML), seja de se rvidor (XHTML/Facelets, JSF).

Mas em todas as práticas que simulamos até agora estávamos preocupados em solucionar um problema de negócio específico, em nível de um Caso de Uso. No mundo real, muitas regras de negócio e

customizações em geral terão utilidade para além deste escopo, para certo número de casos de uso ou mesmo para todos eles! Para cada um destes cenários, um conjunto diferente de Design Patterns mais apropriados deve ser utilizado.

Vejamos quais os principais cenários de demanda por programação candidata ao reúso - e respectivos padrões de implementação recomendados:

1. Problema Específico de um Caso de Uso: Se não há uma perspectiva visível de demanda pela reutilização de uma determinada implementação especializada, para além do escopo de um Caso de Uso, a melhor abordagem (mais produtiva, fácil de entender e evoluir) é utilizar os DP Template Methods conforme abordamos até aqui, nas práticas deste livro.

2. Problema Mais Genérico, de Reuso Potencial em um subconjunto de Casos de Uso de uma aplicação: Quando percebemos que uma especialização possui artefatos de implementação de interesse em uma categoria de casos de uso (mais de um) dentro de uma mesma aplicação, a melhor abordagem ainda é a utilização do DP Template Method, porém com uso complementar do DP Delegation (Delegação).

Este último Design Pattern consiste em basicamente se mover as implementações de classes "pivôs" (controladoras ou orquestradoras) para POJOs externos, que passam a ser chamados pelas

primeiras. Estes POJOs encapsulam o segmento reutilizável do código de customização e podem ser reutilizados de maneira elegante, via Injeção de Dependência simples do CDI, a partir das outras classes controladoras (de outros casos de uso).

3. Problema Mais Genérico, de Reuso Potencial em Um Sub-Conjunto de Casos de Uso de Aplicações Distintas: Quando percebemos que uma extensão ou customização será útil para uma determinada categoria de Casos de Uso, além das fronteiras da própria aplicação (por exemplo, no caso de um novo padrão de Caso de Uso próprio da organização, baseado em variações dos padrões do jCompany), então passa a ser recomendável considerar-se o DP Observer como alternativa ao DP Template Method/Delegation.

O jCompany utiliza este DP como base na implementação recomendada pelo novo padrão CDI (Context Dependency Injection), conforme será o foco deste capítulo.

4. Problema Bastante Genérico, para Toda a Corporação ou Portfólio de Aplicações: Quando percebemos que uma modificação será demandada em nível corporativo ou mesmo por um conjunto inteiro de aplicações com características similares (ex: aplicativos de e -Commerce ou de B2B ou administrativos), então a recomendação volta a ser o uso do DP Template Method!

Porém, neste caso com o uso do DP Bridge. Nesta arquitetura, a empresa disponibiliza estas especializações de uso geral em suas próprias camadas (layers) arquiteturais, que vão embaladas em todas as suas aplicações (ou nos portfólios indicados), de modo a garantir que sejam usadas. A

6

Extensões Arquiteturais

com jCompany Extensions

Capítulo

Conforme citado, neste capítulo iremos discutir a nova possibilidade descrita no item três, uma vez que somente foi incorporada a partir do suporte ao padrão CDI, iniciado nas versões 5.5.x e aprimorado no ramo 6.0.x.

- jCompany Extension = jCompany Plugin (OO) + Ec lipse Plugin (Geraç ão de Código)

Quanto mais uma empresa amadurece na compreensão da arquitetura do jCompany Developer Suite, mais ela o especializa. Apesar dos padrões "prontos para uso" como foram demonstrados nos primeiros módulos deste livro, com a expansão do uso espera-se de um arquiteto corporativo que identifique grandes oportunidades de derivação dos padrões existentes, seja para adequá-los a uma nova

expectativa de seus usuários, seja para expandir sua possibilidade de aplicação em outros cenários - o que, ao final, resulta em aumento do índice de reuso e, em última análise, da produtividade.

Os maiores benefícios do novo mecanismo "jCompany Extension" são voltados para o Arquiteto de Software. Com este novo recurso, ele pode não somente criar novos padrões com base em técnicas de Orientação a Objetos como também complementá-los com geradores de artefatos (sejam eles Java, XHTML, Properties ou outros formatos), para a parte "não generalizável" do padrão.

Portanto, um "jCompany Extension" completo agrupa, em um único projeto Eclipse:

o Mecanismo OO: Classes POJO genéricas, atuando em diversas camadas MVC2-P, que

introduzem código de especialização (ou sobrepõem os existentes) através de interceptações no padrão CDI (DP Observer) definidos em pontos chave do jCompany FS Framework - os mesmos pontos chaves utilizados nos Template Methods, porém sem uso de herança!

o Mecanismo de Geração de Código: No mesmo projeto Eclipse pode-se construir uma solução de geração de código complementar, que se torna imediatamente disponível no Eclipse. E isso, apenas via declarações em um XML e confecção de templates de arquivos em formatos diversos, sem a necessidade de implementar novos plugins do Eclipse!

- Bridge x Extension

Mas por que não implementamos estes novos padrões via DP Template Methods e os d isponibilizamos na camada Bridge, por exemplo?

A experiência em instalações mais avançadas demonstra que, muito embora a Bridge seja uma solução bastante útil para prover um espaço para customizações "globais" (ou, ao menos, úteis para um portfólio inteiro de aplicações), ela começa a oferecer limitações quando um maior número de padrões "opcionais" começa a ser incorporado em seu nível.

Os projetos que formam a Bridge são um "espaço arquitetural" ideal para: regras de segurança, logging/auditoria, customizações de "webdesign corporativo" (logo, topos de impressão, cores, etc.), customizações globais de mensagens, etc.. Ou seja, para implementações corporativas ou de grande amplitude de reúso.

Aproveitar este mesmo espaço para catalogar padrões opcionais, digamos que sejam úteis em três ou quatro casos de uso distintos de uma ou outra aplicação - pode levar a uma rápida deterioração da estabilidade desta camada. Isso se nota através de conflitos entre diferentes padrões "competindo" pelos mesmos "extentions points", por exemplo, onde evoluções em um padrão A acabam instabilizando um padrão B existente e já estável. Ao final, pode-se sofrer com perda de coesão, tornando-se difícil identificar e manter cada padrão individualmente.

Por tudo isso e pelas facilidades adicionais de geração de código é que preconizamos o uso do novo DP Observer via jCompany Extension, para a categoria três do tópico anterior.

Criando um jCompany Extension

- Identific ando uma demanda para uso de "Extension": Importaç ão de Objetos Simples

Suponhamos que nosso negócio necessite importar muitos arquivos pequenos (tabelas de códigos diversas) e desejamos, como arquitetos, prover uma variação do padrão "Manter Classe" que garanta para a empresa uma implementação mais rápida e homogênea para estes casos. Obs.: Uma fábrica de software também pode querer expandir suas possibilidades com novos padrões deste tipo, que possam inclusive ser reutilizados "de um cliente para outro".

No novo padrão proposto, além de um novo botão de importação e um método de controle padrão (disponível para que o desenvolvedor implemente a importação em si*), queremos impedir que o usuário exclua ou inclua novos itens. Ele poderá, no entanto, alterar as descrições dos itens importados.

Se este fosse um problema pontual, específico de um Caso de Uso, então o resolveríamos como citamos na introdução deste capítulo, com DP Template Method e especializações de camada visão. Porém, se como Arquitetos de Software o julgarmos "arquiteturalmente significante" (haverá um volume maior de casos e há uma boa parcela repetitiva e onerosa de codificação similar), o melhor encaminhamento é generalizar parcialmente uma solução na forma de um novo padrão, para maximizar o ganho de escala. Vamos então iniciar a criação deste novo padrão, como nosso primeiro "jCompany Extension":

1. No Eclipse, acione o menu "File -> New Project -> Powerlogic Jaguar Code Generator", e em seguida "Criar novo módulo Jaguar Extension". Conforme a Figura G21.1.

Figura G21.1. Assistente para criação de um novo "jCompany Extension"

2. Preencha o próximo formulário conforme a Figura G21.2. Note que o nome dado ao novo padrão é "plx_importacao".

* P erc eba que nosso foc o aqui é em reus o do arc abouç o M VC2-P, organização de c lasses e artefatos, etc . - e não em generalizar o

Figura G21.2. Formulário de criação de um novo "jCompany Extension".

#1. Nome do novo projeto de extensão, conforme dito anteriormente o nosso padrão chamará "plx_importacao". Note que o prefixo "plx" separado por um underline indica que o projeto é um Extension.

#2. Diretório em que a aplicação será salva. Caso o checkbox "Use default" esteja marcado ela será enviada para o workspace do eclipse.

#3. Nome do pacote base do projeto. Usaremos o padrão já citado no livro, uma vez que ele garante a especificidade do projeto.

#4. Arquivo de template para o projeto de extensão jCompany. Selecione o arquivo padrão "jcompany_ini_extension.zip" encontrado na pasta "meus projetos" do Eclipse ou o arquivo personalizado criado para sua empresa.

#5. Sigla do módulo de extensão, usaremos "Imp". Esta sigla é usada em algumas configurações que veremos mais a frente.

#6. Caminho da aplicação raiz. Usaremos a aplicação "rhtutorial".

3. Agora o projeto de extensão esta pronto, confira a geração na Figura G21.3.

Figura G21.3. Pasta raiz do jCompany Extension "plx_importacao". - Entendendo um projeto jCompany Extension

Note que um projeto jCompany Extension engloba pacotes para todas as camadas MVC2-P em um único projeto Eclipse, evitando assim a proliferação desnecessária de estruturas neste nível, até porque um padrão tende a não possuir quantidades massivas de classes ou artefatos .

Com isso, consegue-se uma coesão e simplicidade importantes para a reutilização, ou seja: "um projeto Eclipse = um padrão", encapsulando generalizações OO e também geração de código

suplementar!. Se algum Arquiteto de Software percebeu neste mecanismo uma grande oportunidade de catalogar padrões de modo simples e compreensivo, parabéns! É isso mesmo que o jCompany Extension possibilita.

Vamos entender agora, com um pouco mais de detalhes, a estrutura interna de um projeto jCompany Extension. A Figura G21.4 mostra os diretórios criados.

Figura G21.4. Diretórios padrões gerados para o projeto jCompany Extension "plx_importacao"

#1. Diretório que deve conter o código fonte (Java) do projeto jCompany Extension "plx_importacao".

#2. Diretório padrão META-INF para JARs. Os arquivos deste diretório são interpretados pelo plugin "Gerador Dinâmico" possibilitando o funcionamento dos assistentes de geração de código integrados ao projeto jCompany Extension "plx_importacao".

#3. Pasta com toda a biblioteca nativa do JRE.

#4. Pasta que contém os arquivos de dependência do Maven.

#5. Pasta padrão de arquivos templates (também para a geração de código).

#6. Pasta com todos os arquivos target (temporários) gerados pelo Maven.

#7. Projetos de extensão também são gerenciados pelo Maven, obviamente, portanto possuem seu próprio arquivo "pom.xml".

Provendo generalizações OO para um jCompany Extension - Customizando os c omportamentos de c ontrole via DP Observer

Agora que entendemos a hierarquia do projeto “plx_importacao”, criaremos os artefatos que modificam o comportamento da aplicação, adequando-os ao nosso objetivo. Iniciaremos com a criação das classes que implementam os "Observers" e são, portanto, responsáveis por especializar o comportamento da aplicação.

Lembrando o que foi dito na introdução, nosso objetivo será criar um novo padrão com base em variação do padrão "Manter Classe" que consistirá basicamente em:

o Prover um novo botão padrão para acionar a importação de arquivo e um método de controle padrão para a implementação da importação em si (futuramente, o próprio algoritmo de importação poderia ser também generalizado nesta extensão).

o Também queremos impedir que o usuário exclua ou inclua novos itens. Ele poderá, no entanto, alterar as descrições dos itens importados.

Código G21.1. Classe "EmpimportacaoActionObserver.java".

o Novo metadado: A classe "PlcConfigimportacao.java" é um metadado que não somente define a ativação do novo padrão como também permite que se parametrize a funcionalidade de inserir e excluir registros, através da propriedade encapsulada “ehConsultaManterClasse” (isso torna

pac kage c om.empresa.rhtutorial.plx_importacao.c ontrole.jsf; ...

public c lass E mpimportacaoActionObserver {

protec ted @Inject @QPlcDefault PlcMetamodelUtil metamodelUtil;

/* * M étodo responsavel por oc ultar o botao F7 -Novo e o c hec k-box de exclusão*/ public void trataBotoesConformeLogicaApos(

@O bserves @PlcTrataBotoesConformeLogicaApos P lcBaseJsfAction ac tion) throws P lcException { P lcConfigimportacao c onfigTabular = E mpimportacaoHelper.getInstance()

.getC onfigTabularConsulta();

if (c onfigT abular ! = null) {

if (c onfigT abular.ehConsultaTabular()) {

P lcContextUtil c ontextUtil = P lc CDIUtil.getInstance()

.getI ns tanceByType(PlcContextUtil.class,QPlcDefaultLiteral.INSTANCE); H ttpServletRequest request = c ontextUtil.getRequest();

getServiceVisaoPlc().naoExibir(contextHelperPlc.getRequest(), P lc Constantes.ACAO.E XIBE_BT_INCLUIR); ac tion.getVisaoJsfUtil().naoExibirComCorrelatos("indExcPlc"); } } }

/* * M etodo responsavel por des abilitar a func ao do F7 -Novo...* /

public void tabularNovoAntes(@O bserves @PlcTabularNovoAntes P lcBaseJsfAction ac tion) throws P lc Exception { P lcConfigimportacao c onfigTabular = E mpimportacaoHelper.getInstance()

.getC onfigTabularConsulta();

if (c onfigT abular ! = null) {

if (c onfigT abular.ehConsultaTabular()) { ac tion.s etContinuaFluxo(false); } els e { ac tion.s etContinuaFluxo(true); } } els e { ac tion.s etContinuaFluxo(true); } }

/* * M etodo responsavel por impedir que novos registros s ejam ins eridos.* /

public void gravaTabularAntes(@Observes @PlcGravaTabularAntes PlcBaseJsfAction action) throws P lc Exception { P lcConfigimportacao c onfigTabular = E mpimportacaoHelper.getInstance()

.getC onfigTabularConsulta(); if (ins tance.getId() == null && StringU tils.isBlank(instance.getIdAux())) {

itens P lc.remove(i); } els e {

ins tanc e.s etIndExcPlc(false); ins tanc e.s etIndExcPlc("N"); }

} }

possível, por exemplo, o reuso deste padrão caso o desenvolvedor precise destas operações). A classe pode ser vista no

o Código G21.2:

Código G21.2. Classe "PlcConf igimportacao.jav a".

Com a implementação da classe "Observer" e métodos de extensão declarados, cria -se um "ponto de corte" no fluxo de execução padrão do jCompany, de modo que a implementação do Extension sempre será executada. Note que é o teste do metadado "PlcConfigimportacao" que impedirá que a extensão ocorra genericamente, para todos os padrões do jCompany!

Neste ponto, para utilizar o novo padrão manualmente o desenvolvedor poderia partir da geração de um Caso de Uso Padrão "Manter Classe" e realizar pequenos ajustes adicionais para acionar e obter o resultado proposto pelo novo padrão. Basicamente, ele iria declarar no arquivo "package-info.java" da camada de controle a nova anotação de metadado e incluiria o novo botão JSF para importação no XHTML apropriado.

É um padrão que, portanto, poderia ser disponibilizado imediatamente, apenas com alguma

documentação adicional em Javadoc e possivelmente em algum documento padrão da empresa (em algum sistema de gestão de reuso ou de ativos de software). Esta documentação traria a orientação de uso de nosso novo padrão, partindo da geração de um Caso de Uso padrão "Manter Classe".

Provendo geradores de artefatos para um jCompany Extension - Apoiando a soluç ão OO c om geraç ão de artefatos

Se estivéssemos na situação de liberar exatamente o padrão que usamos para ilustrar neste capítulo, possivelmente pararíamos na seção anterior, pois sua obtenção a partir de um padrão "próximo" é muito simples.

pac kage c om.empresa.rhtutorial.plx_importacao.metadados; ...

@Doc umented

@T arget(ElementType.PACKAGE) @Retention(RetentionPolicy.RUNTIME )

@P lcMetaConfig(raiz = true, es c opo = E s copo.APP, c amada = C amada.COMUNS)

@P lcMetaEditor(rotulo = "C onsulta M anterClasse", des cricao = "C onfigurações c omplementares para M anterClasse Somente C onsulta")

// C onfigurações globais de definiç ão de logica manterclasse s omente c onsulta public @interface P lcConfigPlx_importacao {

boolean ehC onsultaManterClasse(); }

pac kage c om.empresa.rhtutorial.plx_importacao.metadados; ...

@Doc umented

@T arget(ElementType.PACKAGE) @Retention(RetentionPolicy.RUNTIME )

@P lcMetaConfig(raiz = true, es c opo = E s copo.APP, c amada = C amada.COMUNS)

@P lcMetaEditor(rotulo = "C onsulta M anterClasse", des cricao = "C onfigurações c omplementares para M anterClasse Somente C onsulta")

// C onfigurações globais de definiç ão de logica manterclasse s omente c onsulta public @interface P lcConfigPlx_importacao {

boolean ehC onsultaManterClasse(); }

Porém, podem existir padrões bastante distintos de algum existente no jCompany e/ou o número de intervenções extras pode também ser bem maior do que no caso que ilustramos.

Se isso ocorrer, as falhas potenciais durante o reúso aumentam bastante. Nestes casos, para melhorar nossas chances de reúso bem sucedido por parte dos desenvolvedores, podemos suplementar as técnicas OO que utilizamos até aqui com técnicas de geração de artefatos, também previstas no mecanismo do

jCompany Extension.

Importante: não gostamos de usar o termo "gerador de código" porque, em nossa estratégia, não estamos gerando "código java", que por ser generalizável é melhor tratado via OO. Como geramos artefatos "não Java", não generalizáveis, utilizamos o termo "gerador de artefatos".

Perceba que a união das duas técnicas em uma solução de mais alto nível é bem a forma com que o próprio jCompany trabalha. Pode parecer menos importante, mas a geração de artefatos assistida e integrada a uma solução OO acelera o aprendizado e diminui erros nos reúsos iniciais.

- Definindo um novo assistente de geraç ão de c ódigo

Para o segmento da solução que envolve a geração de artefatos, uma primeira solução possível seria a criação de plugins do Eclipse similares aos do jCompany. Isso envolveria a necessidade de que

desenvolvedores Java EE com foco na Web apreendessem Java Desktop com o SWT, utilizado no Eclipse, além de APIs diversas desta IDE - o que pode ser uma "bala de canhão para matar mosquito", no dito popular, se o que precisamos for gerar alguns artefatos padrões.

Para evitar esta curva de aprendizado, o jCompany Extensions traz um mecanismo que permite que criemos assistentes Eclipse dinâmicos e poderosos, especializados pa ra geração dos artefatos típicos que utilizamos em aplicações Java EE em seus vários formatos. Para tanto, nos basearemos principalmente na definição de um arquivo XML (que serve como base para definição dos passos, formulários e campos do assistente dinâmico no Eclipse) e também de arquivos "template" contendo código Groovy e Velocity para permitir a geração de artefatos finais em formato XHTML de páginas, Menu, metadados com anotações padrão Java, ApplicationResources, etc..

Começaremos criando o XML que abrigará as configurações para o assistente Eclipse de geração do padrão "plx_importacao".

1. Copie o arquivo "manterclasse.plx_importacao.padrao.xml" do diretório

"[jcompany_base]/jcompany_documentacao/rhtutorial/plx_importacao" e salve-o no diretório "plcextension" do projeto de extensão, como nome "manterclasse.plx_importacao.padrao.xml" conforme mostrado na Figura G21.5.

Código G21.3. Estrutura do arquivo de conf iguração com explicação de segmentos mais importantes.·.

...

<! --Declaração do s cript - I nformação c ontendo o T itulo do P adrão, exibido na tela inic ial do wizard - E x.: (M anterClasse - M estre Detalhe - C onsulta)-->

<plc -padrao titulo="Caso de U so P adrao 'Manter C lasse I mportação' (M anterClasse)">

<! --E xemplo de U tilização do P lugin Dinâmico para geração de uma lógic a M anterClasse M anter C lasse Somente A lteração. N este script, voc ê encontrara exemplos de utilização dos componentes do P lugin Dinâmico. - Definição de T elas - Definição de C ampos - I nvocação das tarefas para c riação ou alteração dos arquivos.--> <! -- Definição do íc one que s erá exibido na tela inicial -->

<padrao-imagem>

plx_importacao/plcextension/img/comuns/folder_aberta.gif

</padrao-imagem> <padrao-des cricao>

Bem-vindo ao tutorial do jC ompany para o C aso de U s o 'M anter Classe I mportação'.

N es te tutorial você irá gerar todos os artefatos necessários para realizar manutenç ão em regis tros de menor es cala. V amos c omeçar! </padrao-descricao>

<! -- E s tereótipo utilizado internamente pelo P lugin Dinâmico. Deve ter nome únic o...--> <padrao-es tereotipo>

M anterClasse_importacao

</padrao-es tereotipo>

<! -- E xemplo de definiç ão de c omponentes da primeira página do gerador c om um c ampo String -->

<pagina titulo="P ágina 1 - Definição do C aso de U so">

<c ampo>

<c odigo>projeto</c odigo>

<rotulo>P rojeto Selecionado: </rotulo> <ajuda>Digite aqui o nome do projeto.</ajuda> <dominio>ST RING</dominio> <obrigatoriedade>true</obrigatoriedade> <valor-default></valor-default> <s c ript>groovy/comuns/ValoresDefault</s cript> </c ampo> </pagina> ...

O arquivo XML criado define um novo "assistente Eclipse" que coleta dados em três passos e utiliza estes dados para gerar todos os artefatos necessários para execução do novo padrão. Nesta técnica, cada campo coletado no assistente pode ser referenciado por arquivos de template para geração do resultado final.

<! -- E xemplo de definiç ão de c omponentes da s egunda página do nos so gerador c om um c ampo String-->

<pagina titulo="P ágina 2 - Definição do E vento E specífico">

<c ampo>

<c odigo>nomeE vento</c odigo> <rotulo>nomeE vento Especifico</rotulo> < ajuda>

Digite o nome do E vento E specífico (E x.: gravar, importar,

inic iarSincronizacao) </ajuda> < dominio>ST RING</dominio> < obrigatoriedade>true</obrigatoriedade> < valor-default></valor-default> </c ampo> ... </pagina>

<! -- E xemplo de definiç ão de c omponentes da terc eira página do nos so gerador c om um c ampo Grid --> <pagina titulo="P ágina 3 - Definição c omponentes da tela">

...

<c ampo>

<c odigo>propriedades</codigo>

<rotulo>P ropriedades da E ntidade</rotulo> <ajuda>P ropriedades da E ntidade</ajuda> <dominio>GRI D</dominio>

<grid-def> ... <c ampo>

<c odigo>tipo</c odigo>

<rotulo>T ipo P ropriedade</rotulo> <ajuda>T ipo da propriedade</ajuda> <dominio>C OMBO</dominio> <dominioDiscreto> <opc ao> <rotulo>T exto</rotulo> <valor>texto</valor> </opc ao> ... </dominioDis creto> ... </pagina>

<! -- C riação de uma página xhtml através da c hamada a uma c las se Groovy. O

C orpo do xhtml s erá o c onteúdo do template velocity/extensions/ManterClasse/corpo-xhtml- M anterClasse.vm.

P os sibilita ao us uário escolher o arquivo de des tino. E xemplo de func ionamento em C riarPagina.groovy--> <ac ao> <tipo-ac ao>groovy/comuns/PlcCriarPagina</tipo-acao> <template-origem> /s c ripts/velocity/extension/ManterClasse/c orpo-xhtml-manterclasse-alteracao.vm </template-origem> <diretorio-arq-destino>

/s rc /main/webapp/WEB- I NF/fc ls/${subdiretorio} / $ {c asouso}Tab.xhtml

</diretorio-arq-destino> </ac ao>

...

Os passos do assistente foram projetados segundo os objetivos abaixo (confira os comentários no arquivo XML para entender como cada objetivo foi atingido):

o Passo um: o assistente pede informações elementares para geração do Caso de Uso, como nome (identificador da URL), subdiretório para armazenar as páginas XHTML geradas, título do

formulário e classe de entidade principal já devidamente mapeada.

o Passo dois: coleta de informações referentes ao botão específico JSF que será criado para importação, como o nome do evento e o rótulo do Botão, bem como o nome da Action que abrigará o Template Method para implementação do algoritmo de importação em si (iremos neste caso gerar uma classe Java, mas com fins arquiteturais, ou seja, sem algoritmo e focando somente em sua estrutura).

o Passo três: coleta informações sobre o formulário, permitindo que o usuário personalize os campos a serem gerados no XHTML próprio, e em conformidade com os dados da entidade principal selecionada no passo um.

Para que o gerador dinâmico utilize as entradas de dados fornecidas pelo usuário e gere artefatos dinâmicos com base nelas, é preciso configurar as ações no arquivo

"manterclasse.plx_importacao.padrao.xml".

Uma ação é a execução de um programa Groovy, que poderá ou não invocar um template com instruções Velocity que permite a geração refinada de arquivos de vários formatos. A ações mais comuns, tanto em Groovy quanto em Velocity já são disponibilizadas na criação do projeto dentro do diretório "META-INF/plcextension/script". Elas podem ser utilizadas diretamente, sem modificação, mas também são totalmente personalizáveis pelo desenvolvedor, que pode ainda criar outras, totalmente novas. As ações Groovy disponibilizadas são:

o PlcAlterarArquivo: Altera um arquivo qualquer procurando pelos tokens (comentários pelo arquivo), caso não encontre, insere o conteúdo no final do arquivo. Este artefato pode ser utilizado para alterar qualquer arquivo de texto, inserindo o conteúdo definido em um arquivo Velocity.

o PlcAlterarMenu: Altera o arquivo de menu do jCompany, adicionando os links para acessar as lógicas. Este artefato pode ser utilizado em toda lógica que acesse o menu. O fato de ter sido desenvolvida para alterar o menu torna esta classe incompatível com outras situações. o PlcCriarClasse: Cria uma Classe Java com base em um modelo Velocity pré definido. Este

artefato pode ser utilizado em toda lógica que necessite da criação de Classes Java, como Beans por exemplo.

o PlcCriarPackageInfo: Cria uma Classe "package-info.java" com base em um modelo velocity pré definido. Este artefato pode ser utilizado em toda lógica que necessite da criação de Packge-Info.

o PlcCriarPagina: Permite a criação de páginas (HTML, JSP, XHTML) em um projeto. Este artefato pode ser utilizado em todo padrão que utilize páginas para apresentação na camada de visão.

o PlcRecuperarPropsClasse: Recupera informações sobre a entidade para popular o grid utilizado internamente pelo plugin dinâmico para varrer a entidade informada pelo usuário, retornando todos os atributos para geração do Grid com essas entidades. Este artefato pode ser utilizado após a definição de uma página que vai conter dados da entidade.

o PlcValoresDefault: Utilizado para preencher valores defaults nos campos do assistente. Este artefato pode ser utilizado ao definir um campo para uma página, o usuário pode definir um valor padrão para esse campo.

Os artefatos Velocity disponíveis são:

o plc-application-resources.vm: Template Velocity que insere o conteúdo definido em assistentes no arquivo ApplicationResources.properties.

o plc-item-menu.vm: Template Velocity utilizado pelo AlteraMenu.groovy para inserir o conteúdo definido em seu corpo no arquivo geralMenu.xhtml.

Note que temos ações especializadas na geração ou alteração da maioria dos artefatos típicos da arquitetura Java EE.

As linguagens Groovy e Velocity são linguagens populares de script, dinâmicas e simples de se entender e alterar. Recomendamos uma leitura e exploração de alterações sobre os arquivos padrões, para seu pleno entendimento.

- Criando um template Veloc ity para geraç ão de páginas XHTML para formulários.

A ação Groovy "PlcCriarPagina" é definida como um parâmetro da seção "acao" do XML exemplificado (o XML que define o assistente dinâmico), que contém no total três argumentos:

o tipo-acao: Define a ação Groovy em si, que orquestra todo o processo.

o template-origem: Um arquivo Velocity que contém trechos de código constantes (fixos) e comandos Velocity utilizados para gerar segmentos dinâmicos de código - de modo a produzir novos arquivos completos no formato XHTML (ou seja, o arquivo do formulário específico). o diretorio-arq-destino: Este argumento define um padrão de nome (e diretório) para conter o

resultado final de transformação no arquivo definido em template-origem. Neste caso específico, o token ${casouso}, por exemplo, será substituído pelo valor informado pelo desenvolvedor no campo "Caso de Uso" do assistente, definido na primeira página. E assim por diante: outros tokens também funcionam de forma similar.

Portanto, conforme definido no template-origem para esta ação, precisamos criar o template Velocity "corpo-xhtml-manterclasse-alteracao.vm" no diretório padrão indicado na Figura G21.7.

Figura G21.6. Diretório para inserir os arquivos do extension.

O conteúdo do template pode ser visto no Código G21.4. Note que, enquanto algumas estruturas são fixas (constantes), outras serão modificadas dinamicamente pelo Velocity (textos iniciados com "#" e "$"), conforme informações coletadas no assistente.

Código G21.4. Conteúdo do arquivo Velocity (.vm) que gera o arquivo "XHTML" para o f ormulário. - Criando o(s) template(s) Veloc ity para geraç ão de arquivos "pac kage-info.java" (metadados)

De modo análogo ao anterior, a ação Groovy "PlcCriarPackageInfo" espera um arquivo de template Velocity para gerar, respectivamente, um arquivo final "package-Info.java", padrão do jCompany para conter metadados de Casos de Uso Padrões. Como sabemos, iremos precisar de dois destes arquivos: um para o projeto principal (metadados de camada controle) e outros para o projeto de domínio (metadados de camada comuns).

Como o segundo "package-info.java" não será gerado no projeto Eclipse principal um atributo adicional "<projeto-destino>" deve ser adicionado à segunda declaração de ação, alterando o projeto no qual o arquivo será criado. Observe o uso do token na declaração da Figura G21.7.

Figura G21.7. Conteúdo do arquivo "package-inf o.java" com a declaração "projeto-destino".

Para satisfazer à primeira "acao" definida, crie o arquivo "package-info-manterclasse-grupocontrole-action-especifica.vm" no mesmo diretório que citamos no tópico anterior. O conteúdo do arquivo pode ser conferido no Código G21.5 abaixo.

Código G21.5. Conteúdo do arquivo "package-inf o.java"para satisf azer a primeira "acao".

Crie em seguida o arquivo "package-info-manterclasse-grupoagregacao-alteracao.vm" no mesmo diretório, para a segunda "acao".

/* * M eta-dados para a c amada de c ontrole. Define preferências e inversões de c ontrole de us o s omente da c amada c ontrole * /

@P lcConfigGrupoControle(

ac tion = $ {c ontexto.pacotebase}.c ontrole.jsf.$ {contexto.nomeAction}.class, /* * U s a layout universal * /

layoutU niversal = @P lcConfigLayoutUniversal(dirBaseFacelets = "/WE B -INF/fcls/$ {contexto.subdiretorio}" ),

#s et ($ flagDespresar = '')

#foreac h ($ umaP rop in $ c ontexto.propsentidade.listaPropriedades) #if ($ umaP rop.nome != 'dataUltAlteracao' &&

$ umaP rop.nome != 'us uarioUltAlteracao' &&

$ umaP rop.nome != 'vers ao' && $ umaProp.nome ! = 'id' &&

$ umaP rop.nome != 'has hCodePlc' && $ umaProp.nome != 'indE xcPlc')

#if ($ flagDespresar == '')

#s et ($ flagDespresar = $ umaP rop.nome) #end

#end #end

tabular = @P lcConfigTabular(

propReferenc iaDesprezar = "$ flagDespresar",

tes taDuplicataFlagDesprezar = true, numeroN ovos = 4 ),

c omportamento = @P lcConfigComportamento(detalheLembra = true)

)

pac kage c om.powerlogic.jc ompany.c onfig.app.$ {contexto.c asouso}; ...

Código G21.6. Conteudo do arquivo "package-inf o.java" para satisf azer a segunda "acao". - Configurando a geraç ão de textos I18n no arquivo "Applic ationResourc es.properties".

A ação "PlcAlterarArquivo" definida abaixo realiza a inserção de chaves e textos com mensagens e rótulos no arquivo "ApplicationResources.properties ". Neste caso específico, nenhum template novo precisa ser criado. O jCompany Extensions já provê um template genérico suficiente e a ação Groovy é capaz de alterar o arquivo padrão, acrescentando as novas entradas ao seu final.

Figura G21.8. Ação utilizando o template genérico "application-resources.v m". - Configurando a alteraç ão de Menu (inc lusão de c hamadas).

A alteração do menu também dispensa a criação de novos template Velocity ou ações Groovy. Basta que se informe o endereço para localização do arquivo de menu, conforme ilustrado na figura abaixo.

Figura G21.9. Metadado def inido pelo jCompany no arquivo "package-inf o.java"

- Criando template para c lasse Ac tion (para estimular o uso do Template Method c orreto)

Conforme explicado no início do capítulo, é esperado que seja definida uma classe que estende (herda) de outra que implementa um DP Template Method, que provê um local padronizado para que o usuário possa implementar o algoritmo de importação dos dados em si.

Um esqueleto desta classe pode ser gerado para adiantar este trabalho e estimular o uso corre to por parte do desenvolvedor. Note que, novamente, não há pretensão aqui de gerar "código Java", mas somente estruturas da solução arquitetural - o que evita o anti-pattern "geração de código OO generalizável".

A figura abaixo ilustra a ação como deve ser declarada no XML de definição do assistente.

Figura G21.10. Template "action-evento-especif ico-ManterClasse -criacao.v m" def inido na ação PlcCriarClasse .

@P lcConfigGrupoAgregacao(

entidade = $ {c ontexto.entidade}.class,

padrao = @ P lcConfigPadrao(logica = P lcConfigPadrao.Logica.MANTERCLASSE,

c omplexidade = P lcConfigPadrao.Complexidade.SIMPLES,

exc lusaoModo = P lcConfigPadrao.ExclusaoModo.FISICA)

)

@P lcConfigimportacao(ehConsultaManterClasse=true)

P ac kage c om.powerlogic.jc ompany.config.dominio.app.${contexto.casouso}; ...

O groovy "PlcCriarClasse" irá utilizar como template o arquivo "action-evento-especifico-manterclasse-criacao.vm", que está definido no código abaixo.

Código G21.7. Conteúdo do template Velocity para geração da classe.

- Configurando a geraç ão de botão espec ífico no arquivo "geralAc oesComplemento.xhtml"

Ao contrário dos casos anteriores, este último ilustra um tipo de modificação que não é realizada por nenhum assistente padrão do jCompany, comprovando a flexibilida de e poder dos assistentes dinâmicos providos pelo jCompany Extensions.

Queremos definir um nova ação que reutilize o Groovy "PlcAlterarArquivo" para alterar o arquivo

"geralAcoesComplemento.xhtml", utilizado como padrão no jCompany para conter botões adicionais aos básicos de manutenção. Este botão deverá aparecer junto à barra de ações e disparar a importação em si, implementada na classe Java cujo esqueleto geramos nos passo anterio r.

Figura G21.11. Def inição da ação que irá utilizar o template "altera-geral-acoes.v m".

Precisaremos então criar o template Velocity "altera-geral-acoes.vm" conforme visto no Código G21.8.

Código G21.8. Conteúdo do arquivo "altera-geral-acoes.v m".

Importante: Além disso, neste caso precisamos definir ainda um ponto de inserção no arquivo "geralAcoesComplemento.xhtml", para evitar erros de interpretação do gerador, em situações onde existam conteúdos complexos neste arquivo. Note que é possível se definir este ponto (um comentário padrão) nos templates INI utilizados pela organização, de modo que já venham pré -configurados em todos os seus projetos:

pac kage $ {contexto.pacotebase}.controle.js f; ...

@P lcTratamentoExcecao

public c lass $ {contexto.nomeAction} extends A ppAction {

protec ted s tatic final Logger log = Logger.ge tLogger(${contexto.nomeAction}.class); public String $ {contexto.nomeEvento}() throws P lcException {

return P lc JsfConstantes.NAVEGACAO.IND_MESMA_PAGINA; }

}

## C riando declaração do evento para C aso de U so P adrão

<plc f:botaoAcao urlIcone="ico iE specifico" label="jc ompany.evt.$ {contexto.nomeEvento}" ac tion="#{plcAction.${contexto.nomeEvento}}" rendered="#{requestScope.plcActionSemBarra == '$ {c ontexto.casouso}'}"/>

Figura G21.12. Exemplo de comentário def inindo ponto de inserção no arquivo "geralAcoesComplemento.xhtml"

Com isso, finalizamos todas as configurações necessárias para disponibilizar nosso novo componente OO com um assistente que apóie decisivamente seu reúso, inclusive gerando todas as partes específicas e que não foram possível de ser generalizadas.

Disponibilizando e Reutilizando um Novo Padrão jCompany Extension - Disponibilizando o novo padrão para a empresa

Para disponibilizar este e outros padrões de Caso de Uso criados via jCompany Extension, o Arquiteto de Software deve manter um catálogo de ativos reutilizáveis em algum repositório corporativo, como o Maven Archiva, por exemplo, que é o aplicativo homologado pelo jCompany QA Suite.

Para disponibilizar o 'plugin eclipse dinâmico' em seu ambiente, caso o desenvolvedor possua o projeto jCompany Extension, a tarefa Maven "instalar projeto no repositório local" deve ser executada no projeto relacionado. Caso contrário, ao informar essa dependência no arquivo pom.xml, o artefato será baixado para o repositório local automaticamente.

O próximo passo será fazer com que o ambiente Eclipse dos desenvolvedores reconheça o novo assistente. Para tanto é necessário modificar o arquivo "extensions.properties" que se encontrado na pasta raiz do plugin "Gerador Dinâmico", instalado como padrão em

"[jcompany_base]/eclipse/pluginsPlc/powerlogic/eclipse/plugins/ com.powerlogic.jcompany.ide.geradordinamico_[versao]"*_.

Esse arquivo fornece ao plugin a localização dos arquivos JAR dos jCompany Extensions criados. Novos padrões devem ser inseridos no padrão abaixo:

[nomedoprojetoextension] = [Subdiretório do jCompany Extension criado, começando do repositório]. Importante: Esta configuração é na verdade uma limitação atual da solução, que deverá "descobrir" dinamicamente estes diretórios em versões futuras do jCompany Extensions. Deste modo, a configuração por parte do desenvolvedor se limitará ao seu trabalho típico do dia a dia, de apenas configurar o

componente Maven!

A Figura G21.13. mostra o arquivo extensions.properties configurado para a componente "plx_importacao".

Figura G21.13. A rquivo extensions.properties.

Com isso, o mecanismo do jCompany Extension irá identificar e disponibilizar o novo padrão, para que apareça nos assistentes do Eclipse.

* _{C as o a s ua vers ão do jC ompany tenha sido atualizada via "Eclipse U pdate (online)", a url c orreta para enc ontrar o plugin é:}

- Considerando sobre usar ou não a geraç ão de artefatos

O trabalho de criação dos assistentes e geradores que tivemos até aqui, embora não seja muito extensivo, também não é desprezível. Certamente ele será mais eficaz do que se compararmos ao trabalho para se criar plugins Eclipse "do zero", mas ainda assim deve -se julgar com critério qual a real probabilidade de reuso do padrão e valor que a geração de código trará, em cada contexto.

Por exemplo, caso o Arquiteto de Software estime que um novo padrão recorrente ocorra dezenas de vezes pelas aplicações da empresa, o custo/benefício possivelmente irá compensar. Não somente na forma de produtividade, mas também no reforço ao aprendizado e padronização (ganhos na

manutenção). Mas caso ele perceba que haja menor previsibilidade ou probabilidade de ocorrer, talvez valha à pena ficar apenas na parte OO da solução, orientando seu reúso apenas com documentação.

- Reutilizando o padrão "plx_importac ao" no projeto "rhtutorial"

Retornando ao nosso caso, vamos agora à parte final. Após termos o novo padrão disponibilizado, identificado e configurado, veremos como iremos melhorar o trabalho no dia a dia. Neste ponto é onde verificamos os ganhos de produtividade e qualidade finais, que deverão trazer retorno ao nosso esforço investido.

Vamos então criar uma "Importação de UF" simulada, no projeto "rhtutorial".

Após a criação da classe e mapeamento da mesma através da opção "01 – Mapear Objeto Relacional" acione os assistentes do jCompany para criação de Caso de Uso, através do atalho "Ctrl + n" do Eclipse. Selecione a seguir o assistente de plugin "X - Powerlogic Outros Assistentes", conforme mostra a Figura G21.14.

Figura G21.14. Assistente padrão exibindo opção para assistentes dinâmicos.

Ao clicar em "next" vamos para a tela de seleção de assistente dinâmicos. Perceba que todos os novos padrões são exibidos no segundo passo, conforme mostra a Figura G21.15.

Figura G21.15. Passo de seleção de novos assistentes de geração do jCompany Extensions.

Após selecionar o Caso de Uso Padrão "Manter Classe Importação" clique novamente em " Next" para seguir para o primeiro passo do assistente dinâmico, ilustrado na Figura G21.16.

Figura G21.16. Primeiro passo do assistente dinâmico, exibindo campos conf orme conf igurações do arquivo XML.

Uma vez definida a entidade e informações básicas, vamos para o passo de configuração da classe de Action. A Figura G21.17 mostra o resultado das configurações feitas para o passo 2.

Figura G21.17. Segundo passo, com as conf igurações criadas no arquivo XML.

Clique novamente em "Next" para seguir para o último passo. Note que este retorna todas as

propriedades da entidade selecionada no passo 1 e ainda fornece opções de configuração para geração para cada uma delas. A Figura G21.18 mostra este passo já devidamente preenchido.

Figura G21.18. Último passo, de edição de propriedades da Entidade para geração do f ormulário.

Após clicar no botão "Finish", o gerador dinâmico irá processar e executar as ações Groovy definidas ao final do XML, conforme vimos, gerando então todos os artefatos necessários para que o desenvolvedor já obtenha o Caso de Uso em estágio próximo ao final. Neste caso, restando apenas a implementação do algorítimo específico de importação em si (futuramente o Arquiteto de Software também poderia considerar generalizar até este algoritmo, até certo ponto).

Neste ponto, se o desenvolvedor desejar, ele ainda pode editar cada um dos artefatos gerados e efetuar ajustes manuais para variações sutis necessárias em cada caso específico - mas se já fizer a liberação de imediato ele pode comprovar que o resultado final já tem qualidade de produção e está bastante

Figura G21.19. Formulário com novo padrão f uncional. - Programaç ão do c ódigo de importaç ão

Como vimos, no ponto em que está nosso padrão já impede a criação ou exclusão manual, pelo usuário, de novas entradas de UF, além de prover um botão e classe especificamente projetados para a

implementação da importação em si.

Na hipótese deste exemplo imaginamos que o endereço do arquivo será obtido de modo genérico neste algoritmo. Mas você seria capaz de modificar o padrão para incluir um campo de seleção de arquivo para importação, por exemplo, no início do formulário?

Sumário

Neste capítulo introduzimos a nova tecnologia do jCompany Extensions, que permite aos Arquitetos de Software criarem novos padrões de alto nível similares aos do jCompany, englobando generalizações OO (derivadas ou não de padrões existentes) e, opcionalmente, opções complementares de geração de artefatos.

Experimentamos a flexibilidade de se especializar o comportamento do jCompany através do DP Observer via novo padrão CDI e discutimos em quais cenários cada técnica de especialização se encaixa melhor: DP Template Method para solução pontual; DP Template Method + DP Observer para reuso intra-projeto; DP Template Method + DP Observer + DP Bridge para reuso corporativo; ou DP Observer para um reuso inter-projetos mais escalável.

Construímos um novo padrão com base em uma primeira extensão bastante simples, porém ressaltando as inúmeras possibilidades de uso deste novo e poderoso recurso.