tirando max javaee 6 jcompany6preview-23 final

Expandindo o Poder do jCompany Developer Suite

- Entendendo as melhores práticas de customização

EExercitamos 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 servidor (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.

A6Extensõ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) + Eclipse 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 disponibilizamos 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 "web-design 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 3 do tópico anterior.

Criando um jCompany Extension

- Identificando 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 jCompany Code Generator", e em seguida "Criar novo módulo de extension jCompany". Conforme a Figura G23.1.

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

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

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

* Perceba que nosso foco aqui é em reuso do arcabouço MVC2-P, organização de classes e artefatos, etc. - e não em generalizar o algoritmo de importação em si!

#1. Nome do novo projeto de extensão, conforme dito anteriormente o nosso padrão chamará "importacao".

#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 G23.3.

Figura G23.3. Pasta raiz do jCompany Extension "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 G23.4 mostra os diretórios criados.

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

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

#2. Diretório que deve conter arquivos com anotações Java que representam "metadados" do projeto jCompany Extension "importacao".

#3. 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 assistente de geração de código integrados ao projeto jCompany Extension "importacao".

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

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

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

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

#8. 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 comportamentos de controle via DP Observer

Agora que entendemos a hierarquia do projeto “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.

Para implementar a demanda acima será necessário criar duas classes, descritas abaixo:

Controlador: A classe "EmpImportacaoActionObserver.java" contem a implementação dos Observers do extension. A classe pode ser vista

no package com.empresa.rhtutorial.importacao.controle.jsf;

...

public class EmpImportacaoActionObserver {

package com.empresa.rhtutorial.importacao.controle.jsf;

...

public class EmpImportacaoActionObserver {

protected @Inject @QPlcDefault PlcMetamodelUtil metamodelUtil;

/**Método responsavel por ocultar o botao F7-Novo e o check-box de exclusão*/

public void trataBotoesConformeLogicaApos(

@Observes @PlcTrataBotoesConformeLogicaApos PlcBaseJsfAction action) throws PlcException {

PlcConfigImportacao configTabular = EmpImportacaoHelper.getInstance()

.getConfigTabularConsulta();

if (configTabular != null) {

if (configTabular.ehConsultaTabular()) {

PlcContextUtil contextUtil = PlcCDIUtil.getInstance()

.getInstanceByType(PlcContextUtil.class,QPlcDefaultLiteral.INSTANCE);

HttpServletRequest request = contextUtil.getRequest();

getServiceVisaoPlc().naoExibir(contextHelperPlc.getRequest(),

PlcConstantes.ACAO.EXIBE_BT_INCLUIR);

action.getVisaoJsfUtil().naoExibirComCorrelatos("indExcPlc");

}

}

}

/**Metodo responsavel por desabilitar a funcao do F7-Novo...*/

public void tabularNovoAntes( @Observes @PlcTabularNovoAntes PlcBaseJsfAction action)

throws PlcException {





action.setContinuaFluxo(false);

} else {

action.setContinuaFluxo(true);

}

} else {


}

}

/**Metodo responsavel por impedir que novos registros sejam inseridos.*/

public void gravaTabularAntes(@Observes @PlcGravaTabularAntes PlcBaseJsfAction action)




if (instance.getId() == null && StringUtils.isBlank(instance.getIdAux())) {

itensPlc.remove(i);

} else {

instance.setIndExcPlc(false);

instance.setIndExcPlc("N");

}

}

}

protected @Inject @QPlcDefault PlcMetamodelUtil metamodelUtil;

/**Método responsavel por ocultar o botao F7-Novo e o check-box de exclusão*/

public void trataBotoesConformeLogicaApos(

@Observes @PlcTrataBotoesConformeLogicaApos PlcBaseJsfAction action) throws PlcException {





PlcContextUtil contextUtil = PlcCDIUtil.getInstance()

.getInstanceByType(PlcContextUtil.class,QPlcDefaultLiteral.INSTANCE);

HttpServletRequest request = contextUtil.getRequest();

getServiceVisaoPlc().naoExibir(contextHelperPlc.getRequest(),

PlcConstantes.ACAO.EXIBE_BT_INCLUIR);

action.getVisaoJsfUtil().naoExibirComCorrelatos("indExcPlc");

}

}

}

/**Metodo responsavel por desabilitar a funcao do F7-Novo...*/

public void tabularNovoAntes( @Observes @PlcTabularNovoAntes PlcBaseJsfAction action)






action.setContinuaFluxo(false);

} else {


}

} else {


}

}

/**Metodo responsavel por impedir que novos registros sejam inseridos.*/

public void gravaTabularAntes(@Observes @PlcGravaTabularAntes PlcBaseJsfAction action)




if (instance.getId() == null && StringUtils.isBlank(instance.getIdAux())) {

itensPlc.remove(i);

} else {

instance.setIndExcPlc(false);

instance.setIndExcPlc("N");

}

}

}

o :

Código G23.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 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 G23.2:

Código G23.2. Classe "PlcConfigImportacao.java".

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 com 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.

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.

package com.empresa.rhtutorial.importacao.metadados;

...

@Documented

@Target(ElementType.PACKAGE)

@Retention(RetentionPolicy.RUNTIME)

@PlcMetaConfig(raiz = true, escopo = Escopo.APP, camada = Camada.COMUNS)

@PlcMetaEditor(rotulo = "Consulta ManterClasse", descricao = "Configurações complementares para

ManterClasse Somente Consulta")

// Configurações globais de definição de logica manterclasse somente consulta

public @interface PlcConfigImportacao {

boolean ehConsultaManterClasse();

}

package com.empresa.rhtutorial.importacao.metadados;

...

@Documented

@Target(ElementType.PACKAGE)

@Retention(RetentionPolicy.RUNTIME)

@PlcMetaConfig(raiz = true, escopo = Escopo.APP, camada = Camada.COMUNS)

@PlcMetaEditor(rotulo = "Consulta ManterClasse", descricao = "Configurações complementares para

ManterClasse Somente Consulta")

// Configurações globais de definição de logica manterclasse somente consulta

public @interface PlcConfigImportacao {

boolean ehConsultaManterClasse();

}

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 para 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 "importacao".

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

Figura G23.5. Definição do arquivo de configuração de assistente dinâmico.

...



<plc-padrao titulo="Caso de Uso Padrao 'Manter Classe Importação' (ManterClasse)">





<padrao-imagem>

importacao/plcextension/img/comuns/folder_aberta.gif

</padrao-imagem>

<padrao-descricao>

Bem-vindo ao tutorial do jCompany para o Caso de Uso 'Manter Classe Importação'.

Neste tutorial você irá gerar todos os artefatos necessários para

realizar manutenção em registros de menor escala. Vamos começar!

</padrao-descricao>



<padrao-estereotipo>

ManterClasse_importacao

</padrao-estereotipo>



<pagina titulo="Página 1 - Definição do Caso de Uso">

<campo>

<codigo>projeto</codigo>

<rotulo>Projeto Selecionado: </rotulo>

<ajuda>Digite aqui o nome do projeto.</ajuda>

<dominio>STRING</dominio>

<obrigatoriedade>true</obrigatoriedade>

<valor-default></valor-default>

<script>groovy/comuns/ValoresDefault</script>

</campo>

</pagina>

...

Código G23.3. Estrutura do arquivo de configuração com explicação de segmentos mais importantes.

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.

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



<pagina titulo="Página 2 - Definição do Evento Específico">

<campo>

<codigo>nomeEvento</codigo>

<rotulo>nomeEvento Especifico</rotulo>

< ajuda>

Digite o nome do Evento Específico (Ex.: gravar, importar,

iniciarSincronizacao)

</ajuda>

< dominio>STRING</dominio>

< obrigatoriedade>true</obrigatoriedade>

< valor-default></valor-default>

</campo>

...

</pagina>



<pagina titulo="Página 3 - Definição componentes da tela">

...

<campo>

<codigo>propriedades</codigo>

<rotulo>Propriedades da Entidade</rotulo>

<ajuda>Propriedades da Entidade</ajuda>

<dominio>GRID</dominio>

<grid-def>

...

<campo>

<codigo>tipo</codigo>

<rotulo>Tipo Propriedade</rotulo>

<ajuda>Tipo da propriedade</ajuda>

<dominio>COMBO</dominio>

<dominioDiscreto>

<opcao>

<rotulo>Texto</rotulo>

<valor>texto</valor>

</opcao>

...

</dominioDiscreto>

...

</pagina>



<acao>

<tipo-acao>groovy/comuns/PlcCriarPagina</tipo-acao>

<template-origem>

/scripts/velocity/extension/ManterClasse/corpo-xhtml-manterclasse-alteracao.vm

</template-origem>

<diretorio-arq-destino>

/src/main/webapp/WEB- INF/fcls/${subdiretorio} / ${casouso}Tab.xhtml

</diretorio-arq-destino>

</acao>

...

</plc-padrao>

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.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 Velocity 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 G23.7.

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

Código G23.4. Note que, enquanto algumas estruturas são fixas (constantes), outras serão modificadas dinamicamente pelo Velocity (textos inicados com "#" e "$"), conforme informações coletadas no

assistente.

O conteúdo do template pode ser visto no ...

<html>

<ui:composition>

<plcf:tabela tituloChave="${contexto.casouso}.titulo">

<plcf:linha>

<plcf:celula/>

#foreach ($umaProp in $contexto.entidade.listaPropriedades)

#if ($umaProp.gerar == 'S')

#if ( $umaProp.nome != 'hashCodePlc')

<plcf:celula>

plcf:titulo tituloChave="label.$umaProp.nome"/>

</plcf:celula>

#end

#end

#end

</plcf:linha>

<plcf:iteracao id="plcLogicaItens" value="#{plcLogicaItens.itensPlc}">

<plcf:linha>

<plcf:celula styleClass="celulaFormularioContador">

<plcf:contador>1.</plcf:contador>

</plcf:celula>


#if ( $umaProp.gerar == 'S')


<plcf:celula styleClass="celulaFormularioCaixaMarcacao" rendered="#{empty

requestScope.visualizaDocumentoPlc}">

#if ($umaProp.nome == 'id')

<plcf:oid/>

#elseif ($umaProp.tipo == 'texto')

<plcf:texto id="${umaProp.nome}" value="#{item.${umaProp.nome}}" />

#elseif ($umaProp.tipo == 'inteiro')


#elseif ($umaProp.tipo == 'longo')


#elseif ($umaProp.tipo == 'data')

<plcf:data id="${umaProp.nome}" value="#{item.${umaProp.nome}}" />

#elseif ($umaProp.tipo == 'numerico')

<plcf:numerico id="${umaProp.nome}" value="#{item.${umaProp.nome}}" />

#elseif ($umaProp.tipo == 'boolean')

<plcf:caixaMarcacao id="${umaProp.nome} value="#{item.${umaProp.nome}}" />

#elseif ($umaProp.tipo == 'radio')

<plcf:radio id="${umaProp.nome}" value="#{item.${umaProp.nome}}"

dominio="${umaProp.dominio}" />

#end

</plcf:celula>

#end

#end

#end

</plcf:linha>

</plcf:iteracao>

</plcf:tabela>

</ui:composition>

</html>

Código G23.4. Conteúdo do arquivo Velocity (.vm) que gera o arquivo "XHTML" para o formulário.

- Criando o(s) template(s) Velocity para geração de arquivos "package-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

...

<html>

<ui:composition>

<plcf:tabela tituloChave="${contexto.casouso}.titulo">

<plcf:linha>

<plcf:celula/>


#if ($umaProp.gerar == 'S')


<plcf:celula>

plcf:titulo tituloChave="label.$umaProp.nome"/>

</plcf:celula>

#end

#end

#end

</plcf:linha>

<plcf:iteracao id="plcLogicaItens" value="#{plcLogicaItens.itensPlc}">

<plcf:linha>

<plcf:celula styleClass="celulaFormularioContador">

<plcf:contador>1.</plcf:contador>

</plcf:celula>


#if ( $umaProp.gerar == 'S')


<plcf:celula styleClass="celulaFormularioCaixaMarcacao" rendered="#{empty

requestScope.visualizaDocumentoPlc}">

#if ($umaProp.nome == 'id')

<plcf:oid/>

#elseif ($umaProp.tipo == 'texto')


#elseif ($umaProp.tipo == 'inteiro')


#elseif ($umaProp.tipo == 'longo')


#elseif ($umaProp.tipo == 'data')

<plcf:data id="${umaProp.nome}" value="#{item.${umaProp.nome}}" />

#elseif ($umaProp.tipo == 'numerico')

<plcf:numerico id="${umaProp.nome}" value="#{item.${umaProp.nome}}" />

#elseif ($umaProp.tipo == 'boolean')

<plcf:caixaMarcacao id="${umaProp.nome} value="#{item.${umaProp.nome}}" />

#elseif ($umaProp.tipo == 'radio')

<plcf:radio id="${umaProp.nome}" value="#{item.${umaProp.nome}}"

dominio="${umaProp.dominio}" />

#end

</plcf:celula>

#end

#end

#end

</plcf:linha>

</plcf:iteracao>

</plcf:tabela>

</ui:composition>

</html>

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 G23.7.

Figura G23.7. Conteúdo do arquivo "package-info.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 G23.5 abaixo.

Código G23.5. Conteúdo do arquivo "package-info.java"para satisfazer a primeira "acao".

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

/** Meta-dados para a camada de controle. Define preferências e inversões de controle de uso somente da

camada controle */

@PlcConfigGrupoControle(

action = ${contexto.pacotebase}.controle.jsf.${contexto.nomeAction}.class,

/** Usa layout universal */

layoutUniversal = @PlcConfigLayoutUniversal(dirBaseFacelets = "/WEB-INF/fcls/${contexto.subdiretorio}"

),

#set ($flagDespresar = '')

#foreach ($umaProp in $contexto.propsentidade.listaPropriedades)

#if ($umaProp.nome != 'dataUltAlteracao' &&

$umaProp.nome != 'usuarioUltAlteracao' &&

$umaProp.nome != 'versao' && $umaProp.nome != 'id' &&

$umaProp.nome != 'hashCodePlc' && $umaProp.nome != 'indExcPlc')

#if ($flagDespresar == '')

#set ($flagDespresar = $umaProp.nome)

#end

#end

#end

tabular = @PlcConfigTabular(

propReferenciaDesprezar = "$flagDespresar",

testaDuplicataFlagDesprezar = true, numeroNovos = 4),

comportamento = @PlcConfigComportamento(detalheLembra = true)

)

package com.powerlogic.jcompany.config.app.${contexto.casouso};

...

Código G23.6. Conteudo do arquivo "package-info.java" para satisfazer a segunda "acao".

- Configurando a geração de textos I18n no arquivo "ApplicationResources.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 G23.8. Ação utilizando o template genérico "application-resources.vm".

- Configurando a alteração de Menu (inclusão de chamadas).

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 G23.9. Metadado definido pelo jCompany no arquivo "package-info.java"

- Criando template para classe Action (para estimular o uso do Template Method correto)

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 correto 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 G23.10. Template "action-evento-especifico-ManterClasse-criacao.vm" definido na ação PlcCriarClasse.

@PlcConfigGrupoAgregacao(

entidade = ${contexto.entidade}.class,

padrao = @PlcConfigPadrao(logica = PlcConfigPadrao.Logica.MANTERCLASSE,

complexidade = PlcConfigPadrao.Complexidade.SIMPLES,

exclusaoModo = PlcConfigPadrao.ExclusaoModo.FISICA)

)

@PlcConfigImportacao(ehConsultaManterClasse=true)

Package com.powerlogic.jcompany.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 G23.7. Conteúdo do template Velocity para geração da classe.

- Configurando a geração de botão específico no arquivo "geralAcoesComplemento.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 flexibilidade 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 anterior.

Figura G23.11. Definição da ação que irá utilizar o template "altera-geral-acoes.vm".

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

Código G23.8. Conteúdo do arquivo "altera-geral-acoes.vm".

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:

package ${contexto.pacotebase}.controle.jsf;

...

@PlcTratamentoExcecao

public class ${contexto.nomeAction} extends AppAction {

protected static final Logger log = Logger.getLogger(${contexto.nomeAction}.class);

public String ${contexto.nomeEvento}() throws PlcException {

return PlcJsfConstantes.NAVEGACAO.IND_MESMA_PAGINA;

}

}

## Criando declaração do evento para Caso de Uso Padrão

<plcf:botaoAcao urlIcone="ico iEspecifico" label="jcompany.evt.${contexto.nomeEvento}"

action="#{plcAction.${contexto.nomeEvento}}" rendered="#{requestScope.plcActionSemBarra ==

'${contexto.casouso}'}"/>

Figura G23.12. Exemplo de comentário definindo 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 G23.13. mostra o arquivo extensions.properties configurado para a componente "importacao".

Figura G23.13. Arquivo 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.

* Caso a sua versão do jCompany tenha sido atualizada via "Eclipse Update (online)", a url correta para encontrar o plugin é:

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

- 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 "importacao" 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 G23.14.

Figura G23.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 G23.15.

Figura G23.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 G23.16.

Figura G23.16. Primeiro passo do assistente dinâmico, exibindo campos conforme configuraçõ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 G23.17 mostra o resultado das configurações feitas para o passo 2.

Figura G23.17. Segundo passo, com as configuraçõ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 G23.18 mostra este passo já devidamente preenchido.

Figura G23.18. Último passo, de edição de propriedades da Entidade para geração do formulá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 finalizado e em conformidade com o padrão definido!

Figura G23.19. Formulário com novo padrão funcional.

- 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.

Construimos 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.

tirando max javaee 6 jcompany6preview-23 final

Documents