Captulo

Extenses Arquiteturais
com jCompany Extensions
6
A

Expandindo o Poder do jCompany Developer Suite

- Entendendo as melhores prticas de customizao

xercitamos em vrios captulos as possibilidades de extenso do jCompany FS Framework atravs de

herana, especialmente atravs do DP Template Method nas camadas de controle (*Action) e modelo
(*Manager ou *BO). Alm disso, vimos que o jCompany tambm traz uma arquitetura rica e extensvel
na camada viso, seja de "cliente" (Javascript, Ajax, CSS, HTML), seja de servidor (XHTML/Facelets,
JSF).
Mas em todas as prticas que simulamos at agora estvamos preocupados em solucionar um problema
de negcio especfico, em nvel de um Caso de Uso. No mundo real, muitas regras de negcio e
customizaes em geral tero utilidade para alm deste escopo, para certo nmero de casos de uso ou
mesmo para todos eles! Para cada um destes cenrios, um conjunto diferente de Design Patterns mais
apropriados deve ser utilizado.
Vejamos quais os principais cenrios de demanda por programao candidata ao reso - e respectivos
padres de implementao recomendados:
1.

Problema Especfico de um Caso de Uso: Se no h uma perspectiva visvel de demanda pela

reutilizao de uma determinada implementao especializada, para alm do escopo de um Caso de
Uso, a melhor abordagem (mais produtiva, fcil de entender e evoluir) utilizar os DP Template
Methods conforme abordamos at aqui, nas prticas deste livro.

2.

Problema Mais Genrico, de Reuso Potencial em um subconjunto de Casos de Uso de uma

aplicao: Quando percebemos que uma especializao possui artefatos de implementao de
interesse em uma categoria de casos de uso (mais de um) dentro de uma mesma aplicao, a
melhor abordagem ainda a utilizao do DP Template Method, porm com uso complementar do
DP Delegation (Delegao).
Este ltimo Design Pattern consiste em basicamente se mover as implementaes de classes "pivs"
(controladoras ou orquestradoras) para POJOs externos, que passam a ser chamados pelas
primeiras. Estes POJOs encapsulam o segmento reutilizvel do cdigo de customizao e podem ser
reutilizados de maneira elegante, via Injeo de Dependncia simples do CDI, a partir das outras
classes controladoras (de outros casos de uso).

3.

Problema Mais Genrico, de Reuso Potencial em Um Sub-Conjunto de Casos de Uso de

Aplicaes Distintas: Quando percebemos que uma extenso ou customizao ser til para uma
determinada categoria de Casos de Uso, alm das fronteiras da prpria aplicao (por exemplo,
no caso de um novo padro de Caso de Uso prprio da organizao, baseado em variaes dos
padres do jCompany), ento passa a ser recomendvel considerar-se o DP Observer como
alternativa ao DP Template Method/Delegation.
O jCompany utiliza este DP como base na implementao recomendada pelo novo padro CDI
(Context Dependency Injection), conforme ser o foco deste captulo.

4.

Problema Bastante Genrico, para Toda a Corporao ou Portflio de Aplicaes: Quando

percebemos que uma modificao ser demandada em nvel corporativo ou mesmo por um conjunto
inteiro de aplicaes com caractersticas similares (ex: aplicativos de e-Commerce ou de B2B ou
administrativos), ento a recomendao volta a ser o uso do DP Template Method!
Porm, neste caso com o uso do DP Bridge. Nesta arquitetura, a empresa disponibiliza estas
especializaes de uso geral em suas prprias camadas (layers) arquiteturais, que vo embaladas
em todas as suas aplicaes (ou nos portflios indicados), de modo a garantir que sejam usadas.

Conforme citado, neste captulo iremos discutir a nova possibilidade descrita no item trs, uma vez que
somente foi incorporada a partir do suporte ao padro CDI, iniciado nas verses 5.5.x e aprimorado no
ramo 6.0.x.

- jCompany Extension = jCompany Plugin (OO) + Eclipse Plugin (Gerao de Cdigo)

Quanto mais uma empresa amadurece na compreenso da arquitetura do jCompany Developer Suite,
mais ela o especializa. Apesar dos padres "prontos para uso" como foram demonstrados nos primeiros
mdulos deste livro, com a expanso do uso espera-se de um arquiteto corporativo que identifique
grandes oportunidades de derivao dos padres existentes, seja para adequ-los a uma nova
expectativa de seus usurios, seja para expandir sua possibilidade de aplicao em outros cenrios - o
que, ao final, resulta em aumento do ndice de reuso e, em ltima anlise, da produtividade.
Os maiores benefcios do novo mecanismo "jCompany Extension" so voltados para o Arquiteto de
Software. Com este novo recurso, ele pode no somente criar novos padres com base em tcnicas de
Orientao a Objetos como tambm complement-los com geradores de artefatos (sejam eles Java,
XHTML, Properties ou outros formatos), para a parte "no generalizvel" do padro.
Portanto, um "jCompany Extension" completo agrupa, em um nico projeto Eclipse:
o Mecanismo OO: Classes POJO genricas, atuando em diversas camadas MVC2-P, que
introduzem cdigo de especializao (ou sobrepem os existentes) atravs de interceptaes no
padro CDI (DP Observer) definidos em pontos chave do jCompany FS Framework - os mesmos
pontos chaves utilizados nos Template Methods, porm sem uso de herana!
o Mecanismo de Gerao de Cdigo: No mesmo projeto Eclipse pode-se construir uma soluo
de gerao de cdigo complementar, que se torna imediatamente disponvel no Eclipse. E isso,
apenas via declaraes em um XML e confeco de templates de arquivos em formatos
diversos, sem a necessidade de implementar novos plugins do Eclipse!

- Bridge x Extension
Mas por que no implementamos estes novos padres via DP Template Methods e os disponibilizamos na
camada Bridge, por exemplo?
A experincia em instalaes mais avanadas demonstra que, muito embora a Bridge seja uma soluo
bastante til para prover um espao para customizaes "globais" (ou, ao menos, teis para um portflio
inteiro de aplicaes), ela comea a oferecer limitaes quando um maior nmero de padres "opcionais"
comea a ser incorporado em seu nvel.
Os projetos que formam a Bridge so um "espao arquitetural" ideal para: regras de segurana,
logging/auditoria, customizaes de "web-design corporativo" (logo, topos de impresso, cores, etc.),
customizaes globais de mensagens, etc.. Ou seja, para implementaes corporativas ou de grande
amplitude de reso.
Aproveitar este mesmo espao para catalogar padres opcionais, digamos que sejam teis em trs ou
quatro casos de uso distintos de uma ou outra aplicao - pode levar a uma rpida deteriorao da
estabilidade desta camada. Isso se nota atravs de conflitos entre diferentes padres "competindo" pelos
mesmos "extentions points", por exemplo, onde evolues em um padro A acabam instabilizando um
padro B existente e j estvel. Ao final, pode-se sofrer com perda de coeso, tornando-se difcil
identificar e manter cada padro individualmente.
Por tudo isso e pelas facilidades adicionais de gerao de cdigo que preconizamos o uso do novo DP
Observer via jCompany Extension, para a categoria 3 do tpico anterior.

Criando um jCompany Extension

- Identificando uma demanda para uso de "Extension": Importao de Objetos Simples
Suponhamos que nosso negcio necessite importar muitos arquivos pequenos (tabelas de cdigos
diversas) e desejamos, como arquitetos, prover uma variao do padro "Manter Classe" que garanta
para a empresa uma implementao mais rpida e homognea para estes casos. Obs.: Uma fbrica de
software tambm pode querer expandir suas possibilidades com novos padres deste tipo, que possam
inclusive ser reutilizados "de um cliente para outro".

No novo padro proposto, alm de um novo boto de importao e um mtodo de controle padro
(disponvel para que o desenvolvedor implemente a importao em si*), queremos impedir que o usurio
exclua ou inclua novos itens. Ele poder, no entanto, alterar as descries dos itens importados.
Se este fosse um problema pontual, especfico de um Caso de Uso, ento o resolveramos como citamos
na introduo deste captulo, com DP Template Method e especializaes de camada viso. Porm, se
como Arquitetos de Software o julgarmos "arquiteturalmente significante" (haver um volume maior de
casos e h uma boa parcela repetitiva e onerosa de codificao similar), o melhor encaminhamento
generalizar parcialmente uma soluo na forma de um novo padro, para maximizar o ganho de escala.
Vamos ento iniciar a criao deste novo padro, como nosso primeiro "jCompany Extension":
1.

No Eclipse, acione o menu "File -> New Project -> Powerlogic jCompany Code Generator", e em
seguida "Criar novo mdulo de extension jCompany". Conforme a Figura G23.1.

Figura G23.1. Assistente para criao de um novo "jCompany Extension"

2.

Preencha o prximo formulrio conforme a Figura G23.2. Note que o nome dado ao novo padro
"importacao".

Figura G23.2. Formulrio de criao de um novo "jCompany Extension".

*
Perceba que nosso foco aqui em reuso do arcabouo MVC2-P, organizao de classes e artefatos, etc. - e no em generalizar o
algoritmo de importao em si!

#1. Nome do novo projeto de extenso, conforme dito anteriormente o nosso padro chamar
"importacao".
#2. Diretrio em que a aplicao 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 padro j citado no livro, uma vez que ele
garante a especificidade do projeto.
#4. Arquivo de template para o projeto de extenso jCompany. Selecione o arquivo padro
"jcompany_ini_extension.zip" encontrado na pasta "meus projetos" do Eclipse ou o arquivo
personalizado criado para sua empresa.
#5. Sigla do mdulo de extenso, usaremos "Imp". Esta sigla usada em algumas configuraes
que veremos mais a frente.
#6. Caminho da aplicao raiz. Usaremos a aplicao "rhtutorial".
3.

Agora o projeto de extenso esta pronto, confira a gerao 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 proliferao desnecessria de estruturas neste nvel, at porque um
padro tende a no possuir quantidades massivas de classes ou artefatos.
Com isso, consegue-se uma coeso e simplicidade importantes para a reutilizao, ou seja: "um projeto
Eclipse = um padro", encapsulando generalizaes OO e tambm gerao de cdigo
suplementar!". Se algum Arquiteto de Software percebeu neste mecanismo uma grande oportunidade
de catalogar padres de modo simples e compreensivo, parabns! 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 diretrios criados.

Figura G23.4. Diretrios padres gerados para o projeto jCompany Extension "importacao"

#1. Diretrio que deve conter o cdigo fonte (Java) do projeto jCompany Extension "importacao".
#2. Diretrio que deve conter arquivos com anotaes Java que representam "metadados" do
projeto jCompany Extension "importacao".
#3. Diretrio padro META-INF para JARs. Os arquivos deste diretrio so interpretados pelo plugin
"Gerador Dinmico" possibilitando o funcionamento dos assistente de gerao de cdigo
integrados ao projeto jCompany Extension "importacao".

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

#5. Pasta que contm os arquivos de dependncia do Maven.
#6. Pasta padro de arquivos templates (tambm para a gerao de cdigo).
#7. Pasta com todos os arquivos target (temporrios) gerados pelo Maven.
#8. Projetos de extenso tambm so gerenciados pelo Maven, obviamente, portanto possuem seu
prprio arquivo "pom.xml".

Provendo generalizaes 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 aplicao, adequando-os ao nosso objetivo. Iniciaremos com a criao das classes
que implementam os "Observers" e so, portanto, responsveis por especializar o comportamento da
aplicao.
Lembrando o que foi dito na introduo, nosso objetivo ser criar um novo padro com base em variao
do padro "Manter Classe" que consistir basicamente em:
o

Prover um novo boto padro para acionar a importao de arquivo e um mtodo de controle
padro para a implementao da importao em si (futuramente, o prprio algoritmo de
importao poderia ser tambm generalizado nesta extenso).

Tambm queremos impedir que o usurio exclua ou inclua novos itens. Ele poder, no entanto,
alterar as descries dos itens importados.

Para implementar a demanda acima ser necessrio criar duas classes, descritas abaixo:

Controlador: A classe "EmpImportacaoActionObserver.java" contem a implementao dos Observers do extension. A classe pode ser vista

package com.empresa.rhtutorial.importacao.controle.jsf;
...
public class EmpImportacaoActionObserver {
protected @Inject @QPlcDefault PlcMetamodelUtil metamodelUtil;
/**Mtodo responsavel por ocultar o botao F7-Novo e o check-box de excluso*/
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 {
PlcConfigImportacao configTabular = EmpImportacaoHelper.getInstance()
.getConfigTabularConsulta();
if (configTabular != null) {
if (configTabular.ehConsultaTabular()) {
action.setContinuaFluxo(false);
} else {
action.setContinuaFluxo(true);
}
} else {
action.setContinuaFluxo(true);
}
}
/**Metodo responsavel por impedir que novos registros sejam inseridos.*/
public void gravaTabularAntes(@Observes @PlcGravaTabularAntes PlcBaseJsfAction action)
throws PlcException {
PlcConfigImportacao configTabular = EmpImportacaoHelper.getInstance()
.getConfigTabularConsulta();
if (instance.getId() == null && StringUtils.isBlank(instance.getIdAux())) {
itensPlc.remove(i);
} else {
instance.setIndExcPlc(false);
instance.setIndExcPlc("N");
}
}
}
no package com.empresa.rhtutorial.importacao.controle.jsf;
...
public class EmpImportacaoActionObserver {

protected @Inject @QPlcDefault PlcMetamodelUtil metamodelUtil;

/**Mtodo responsavel por ocultar o botao F7-Novo e o check-box de excluso*/

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 {
PlcConfigImportacao configTabular = EmpImportacaoHelper.getInstance()
.getConfigTabularConsulta();
if (configTabular != null) {
if (configTabular.ehConsultaTabular()) {
action.setContinuaFluxo(false);
} else {
action.setContinuaFluxo(true);
}
} else {
action.setContinuaFluxo(true);
}
}
/**Metodo responsavel por impedir que novos registros sejam inseridos.*/
public void gravaTabularAntes(@Observes @PlcGravaTabularAntes PlcBaseJsfAction action)
throws PlcException {
PlcConfigImportacao configTabular = EmpImportacaoHelper.getInstance()
.getConfigTabularConsulta();
if (instance.getId() == null && StringUtils.isBlank(instance.getIdAux())) {
itensPlc.remove(i);
} else {
instance.setIndExcPlc(false);
instance.setIndExcPlc("N");
}
}
}

Cdigo G23.1. Classe "EmpImportacaoActionObserver.java".

Novo metadado: A classe "PlcConfigImportacao.java" um metadado que no somente define

a ativao do novo padro como tambm permite que se parametrize a funcionalidade de inserir
e excluir registros, atravs da propriedade encapsulada ehConsultaManterClasse (isso torna
possvel, por exemplo, o reuso deste padro caso o desenvolvedor precise destas operaes). A
classe pode ser vista no

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 = "Configuraes complementares para
ManterClasse Somente Consulta")
// Configuraes globais de definio de logica manterclasse somente consulta
public @interface PlcConfigImportacao {
boolean ehConsultaManterClasse();
}

Cdigo G23.2:

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 = "Configuraes complementares para
ManterClasse Somente Consulta")
// Configuraes globais de definio de logica manterclasse somente consulta
public @interface PlcConfigImportacao {
boolean ehConsultaManterClasse();
}

Cdigo G23.2. Classe "PlcConfigImportacao.java".

Com a implementao da classe "Observer" e mtodos de extenso declarados, cria-se um "ponto de

corte" no fluxo de execuo padro do jCompany, de modo que a implementao do Extension sempre
ser executada. Note que o teste do metadado "PlcConfigImportacao" que impedir que a extenso
ocorra genericamente, para todos os padres do jCompany!
Neste ponto, para utilizar o novo padro manualmente o desenvolvedor poderia partir da gerao de um
Caso de Uso Padro "Manter Classe" e realizar pequenos ajustes adicionais para acionar e obter o
resultado proposto pelo novo padro. Basicamente, ele iria declarar no arquivo "package-info.java" da
camada de controle a nova anotao de metadado e incluiria o novo boto JSF para importao no
XHTML apropriado.
um padro que, portanto, poderia ser disponibilizado imediatamente, apenas com alguma
documentao adicional em Javadoc e possivelmente em algum documento padro da empresa (em
algum sistema de gesto de reuso ou de ativos de software). Esta documentao traria a orientao de
uso de nosso novo padro, partindo da gerao de um Caso de Uso padro "Manter Classe".

Provendo geradores de artefatos para um jCompany Extension

- Apoiando a soluo OO com gerao de artefatos
Se estivssemos na situao de liberar exatamente o padro que usamos para ilustrar neste captulo,
possivelmente pararamos na seo anterior, pois sua obteno a partir de um padro "prximo" muito
simples.
Porm, podem existir padres bastante distintos de algum existente no jCompany e/ou o nmero de
intervenes extras pode tambm ser bem maior do que no caso que ilustramos.

Se isso ocorrer, as falhas potenciais durante o reso aumentam bastante. Nestes casos, para melhorar
nossas chances de reso bem sucedido por parte dos desenvolvedores, podemos suplementar as tcnicas
OO que utilizamos at aqui com tcnicas de gerao de artefatos, tambm previstas no mecanismo do
jCompany Extension.
Importante: no gostamos de usar o termo "gerador de cdigo" porque, em nossa estratgia, no
estamos gerando "cdigo java", que por ser generalizvel melhor tratado via OO. Como geramos
artefatos "no Java", no generalizveis, utilizamos o termo "gerador de artefatos".
Perceba que a unio das duas tcnicas em uma soluo de mais alto nvel bem a forma com que o
prprio jCompany trabalha. Pode parecer menos importante, mas a gerao de artefatos assistida e
integrada a uma soluo OO acelera o aprendizado e diminui erros nos resos iniciais.

- Definindo um novo assistente de gerao de cdigo

Para o segmento da soluo que envolve a gerao de artefatos, uma primeira soluo possvel seria a
criao 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,
alm de APIs diversas desta IDE - o que pode ser uma "bala de canho para matar mosquito", no dito
popular, se o que precisamos for gerar alguns artefatos padres.
Para evitar esta curva de aprendizado, o jCompany Extensions traz um mecanismo que permite que
criemos assistentes Eclipse dinmicos e poderosos, especializados para gerao dos artefatos tpicos que
utilizamos em aplicaes Java EE em seus vrios formatos. Para tanto, nos basearemos principalmente
na definio de um arquivo XML (que serve como base para definio dos passos, formulrios e campos
do assistente dinmico no Eclipse) e tambm de arquivos "template" contendo cdigo Groovy e Velocity
para permitir a gerao de artefatos finais em formato XHTML de pginas, Menu, metadados com
anotaes padro Java, ApplicationResources, etc..
Comearemos criando o XML que abrigar as configuraes para o assistente Eclipse de gerao do
padro "importacao".
1.

Copie o arquivo "manterclasse.importacao.padrao.xml" do diretrio

"[jcompany_base]/jcompany_documentacao/rhtutorial/importacao" e salve-o no diretrio
"plcextension" do projeto de extenso, como nome "manterclasse.importacao.padrao.xml" conforme
mostrado na Figura G23.5.

Figura G23.5. Definio do arquivo de configurao de assistente dinmico.

...
<!--Declarao do script - Informao contendo o Titulo do Padro, exibido na tela inicial do wizard - Ex.:
(ManterClasse - Mestre Detalhe - Consulta)-->
<plc-padrao titulo="Caso de Uso Padrao 'Manter Classe Importao' (ManterClasse)">
<!--Exemplo de Utilizao do Plugin Dinmico para gerao de uma lgica ManterClasse Manter Classe
Somente Alterao. Neste script, voc encontrara exemplos de utilizao dos componentes do Plugin Dinmico.
- Definio de Telas - Definio de Campos - Invocao das tarefas para criao ou alterao dos arquivos.-->
<!-- Definio do cone que ser exibido na tela inicial -->
<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 Importao'.
Neste tutorial voc ir gerar todos os artefatos necessrios para
realizar manuteno em registros de menor escala. Vamos comear!
</padrao-descricao>
<!-- Esteretipo utilizado internamente pelo Plugin Dinmico. Deve ter nome nico...-->
<padrao-estereotipo>
ManterClasse_importacao
</padrao-estereotipo>
<!-- Exemplo de definio de componentes da primeira pgina do gerador com um campo String-->
<pagina titulo="Pgina 1 - Definio 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>
...

<!-- Exemplo de definio de componentes da segunda pgina do nosso gerador com um campo String-->
<pagina titulo="Pgina 2 - Definio do Evento Especfico">
<campo>
<codigo>nomeEvento</codigo>
<rotulo>nomeEvento Especifico</rotulo>
< ajuda>
Digite o nome do Evento Especfico (Ex.: gravar, importar,
iniciarSincronizacao)
</ajuda>
< dominio>STRING</dominio>
< obrigatoriedade>true</obrigatoriedade>
< valor-default></valor-default>
</campo>
...
</pagina>
<!-- Exemplo de definio de componentes da terceira pgina do nosso gerador com um campo Grid-->
<pagina titulo="Pgina 3 - Definio 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>
<!-- Criao de uma pgina xhtml atravs da chamada a uma classe Groovy. O
Corpo do xhtml ser o contedo do template velocity/extensions/ManterClasse/corpo-xhtmlManterClasse.vm.
Possibilita ao usurio escolher o arquivo de destino. Exemplo de funcionamento em
CriarPagina.groovy-->
<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>
Cdigo G23.3. Estrutura do arquivo de configurao com explicao de segmentos mais importantes.

O arquivo XML criado define um novo "assistente Eclipse" que coleta dados em trs passos e utiliza estes
dados para gerar todos os artefatos necessrios para execuo do novo padro. Nesta tcnica, cada
campo coletado no assistente pode ser referenciado por arquivos de template para gerao do resultado
final.
Os passos do assistente foram projetados segundo os objetivos abaixo (confira os comentrios no
arquivo XML para entender como cada objetivo foi atingido):

Passo um: o assistente pede informaes elementares para gerao do Caso de Uso, como nome
(identificador da URL), subdiretrio para armazenar as pginas XHTML geradas, ttulo do
formulrio e classe de entidade principal j devidamente mapeada

Passo dois: coleta de informaes referentes ao boto especfico JSF que ser criado para
importao, como o nome do evento e o rtulo do Boto, bem como o nome da Action que
abrigar o Template Method para implementao do algoritmo de importao em si (iremos
neste caso gerar uma classe Java, mas com fins arquiteturais, ou seja, sem algoritmo e focando
somente em sua estrutura).

Passo trs: coleta informaes sobre o formulrio, permitindo que o usurio personalize os
campos a serem gerados no XHTML prprio, e em conformidade com os dados da entidade
principal selecionada no passo um.

Para que o gerador dinmico utilize as entradas de dados fornecidas pelo usurio e gere artefatos
dinmicos com base nelas, preciso configurar as aes no arquivo
"manterclasse.importacao.padrao.xml".
Uma ao a execuo de um programa Groovy, que poder ou no invocar um template com instrues
Velocity que permite a gerao refinada de arquivos de vrios formatos. A aes mais comuns, tanto em
Groovy quanto em Velocity j so disponibilizadas na criao do projeto dentro do diretrio "METAINF/plcextension/script". Elas podem ser utilizadas diretamente, sem modificao, mas tambm so
totalmente personalizveis pelo desenvolvedor, que pode ainda criar outras, totalmente novas.
As aes Groovy disponibilizadas so:
o

PlcAlterarArquivo: Altera um arquivo qualquer procurando pelos tokens (comentrios pelo

arquivo), caso no encontre, insere o contedo no final do arquivo. Este artefato pode ser
utilizado para alterar qualquer arquivo de texto, inserindo o contedo definido em um arquivo
Velocity.

PlcAlterarMenu: Altera o arquivo de menu do jCompany, adicionando os links para acessar as

lgicas. Este artefato pode ser utilizado em toda lgica que acesse o menu. O fato de ter sido
desenvolvida para alterar o menu torna esta classe incompatvel com outras situaes.

PlcCriarClasse: Cria uma Classe Java com base em um modelo Velocity pr definido. Este
artefato pode ser utilizado em toda lgica que necessite da criao de Classes Java, como Beans
por exemplo.

PlcCriarPackageInfo: Cria uma Classe "package-info.java" com base em um modelo velocity

pr definido. Este artefato pode ser utilizado em toda lgica que necessite da criao de PackgeInfo.

PlcCriarPagina: Permite a criao de pginas (HTML, JSP, XHTML) em um projeto. Este

artefato pode ser utilizado em todo padro que utilize pginas para apresentao na camada de
viso.

PlcRecuperarPropsClasse: Recupera informaes sobre a entidade para popular o grid

utilizado internamente pelo plugin dinmico para varrer a entidade informada pelo usurio,
retornando todos os atributos para gerao do Grid com essas entidades. Este artefato pode ser
utilizado aps a definio de uma pgina que vai conter dados da entidade.

PlcValoresDefault: Utilizado para preencher valores defaults nos campos do assistente. Este
artefato pode ser utilizado ao definir um campo para uma pgina, o usurio pode definir um
valor padro para esse campo.

Os artefatos Velocity disponveis so:

o

plc-application-resources.vm: Template Velocity que insere o contedo definido em

assistentes no arquivo ApplicationResources.properties.

plc-item-menu.vm: Template Velocity utilizado pelo AlteraMenu.groovy para inserir o contedo

definido em seu corpo no arquivo geralMenu.xhtml.

Note que temos aes especializadas na gerao ou alterao da maioria dos artefatos tpicos da
arquitetura Java EE.
As linguagens Groovy e Velocity so linguagens populares de script, dinmicas e simples de se entender
e alterar. Recomendamos uma leitura e explorao de alteraes sobre os arquivos padres, para seu
pleno entendimento.

- Criando um template Velocity para gerao de pginas XHTML para formulrios.

A ao Groovy "PlcCriarPagina" definida como um parmetro da seo "acao" do XML exemplificado (o
XML que define o assistente dinmico), que contm no total trs argumentos:
o

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

template-origem: Um arquivo Velocity que contm trechos de cdigo constantes (fixos) e

comandos Velocity utilizados para gerar segmentos dinmicos de cdigo - de modo a produzir
novos arquivos completos no formato XHTML (ou seja, o arquivo do formulrio especfico).

diretorio-arq-destino: Este argumento define um padro de nome (e diretrio) para conter o

resultado final de transformao no arquivo definido em template-origem. Neste caso especfico,
o token ${casouso}, por exemplo, ser substitudo pelo valor informado pelo desenvolvedor no
campo "Caso de Uso" do assistente, definido na primeira pgina. E assim por diante: outros
tokens tambm funcionam de forma similar.

Portanto, conforme definido no template-origem para esta ao, precisamos criar o template Velocity
"corpo-xhtml-manterclasse-alteracao.vm" no diretrio padro indicado na Figura G23.7.

Figura G23.6. Diretrio para inserir os arquivos do extension.

Cdigo G23.4. Note que, enquanto algumas estruturas so fixas (constantes), outras sero modificadas
dinamicamente pelo Velocity (textos inicados com "#" e "$"), conforme informaes coletadas no

O contedo 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>
#foreach ($umaProp in $contexto.entidade.listaPropriedades)
#if ( $umaProp.gerar == 'S')
#if ( $umaProp.nome != 'hashCodePlc')
<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')
<plcf:texto id="${umaProp.nome}" value="#{item.${umaProp.nome}}" />
#elseif ($umaProp.tipo == 'longo')
<plcf:texto id="${umaProp.nome}" value="#{item.${umaProp.nome}}" />
#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>

assistente.

...
<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>
#foreach ($umaProp in $contexto.entidade.listaPropriedades)
#if ( $umaProp.gerar == 'S')
#if ( $umaProp.nome != 'hashCodePlc')
<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')
<plcf:texto id="${umaProp.nome}" value="#{item.${umaProp.nome}}" />
#elseif ($umaProp.tipo == 'longo')
<plcf:texto id="${umaProp.nome}" value="#{item.${umaProp.nome}}" />
#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>
Cdigo G23.4. Contedo do arquivo Velocity (.vm) que gera o arquivo "XHTML" para o formulrio.

- Criando o(s) template(s) Velocity para gerao de arquivos "package-info.java" (metadados)

De modo anlogo ao anterior, a ao Groovy "PlcCriarPackageInfo" espera um arquivo de template
Velocity para gerar, respectivamente, um arquivo final "package-Info.java", padro do jCompany para

conter metadados de Casos de Uso Padres. Como sabemos, iremos precisar de dois destes arquivos:
um para o projeto principal (metadados de camada controle) e outros para o projeto de domnio
(metadados de camada comuns).
Como o segundo "package-info.java" no ser gerado no projeto Eclipse principal um atributo adicional
"<projeto-destino>" deve ser adicionado segunda declarao de ao, alterando o projeto no qual o
arquivo ser criado. Observe o uso do token na declarao da Figura G23.7.

Figura G23.7. Contedo do arquivo "package-info.java" com a declarao "projeto-destino".

Para satisfazer primeira "acao" definida, crie o arquivo "package-info-manterclasse-grupocontroleaction-especifica.vm" no mesmo diretrio que citamos no tpico anterior. O contedo do arquivo pode ser
conferido no Cdigo G23.5 abaixo.

/** Meta-dados para a camada de controle. Define preferncias e inverses 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};
...
Cdigo G23.5. Contedo do arquivo "package-info.java"para satisfazer a primeira "acao".

Crie em seguida o arquivo "package-info-manterclasse-grupoagregacao-alteracao.vm" no mesmo

diretrio, para a segunda "acao".

@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};
...
Cdigo G23.6. Conteudo do arquivo "package-info.java" para satisfazer a segunda "acao".

- Configurando a gerao de textos I18n no arquivo "ApplicationResources.properties".

A ao "PlcAlterarArquivo" definida abaixo realiza a insero de chaves e textos com mensagens e rtulos
no arquivo "ApplicationResources.properties ". Neste caso especfico, nenhum template novo precisa ser
criado. O jCompany Extensions j prov um template genrico suficiente e a ao Groovy capaz de
alterar o arquivo padro, acrescentando as novas entradas ao seu final.

Figura G23.8. Ao utilizando o template genrico "application-resources.vm".

- Configurando a alterao de Menu (incluso de chamadas).

A alterao do menu tambm dispensa a criao de novos template Velocity ou aes Groovy. Basta que
se informe o endereo para localizao 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 incio do captulo, 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 usurio
possa implementar o algoritmo de importao 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, no h pretenso aqui de gerar "cdigo Java", mas
somente estruturas da soluo arquitetural - o que evita o anti-pattern "gerao de cdigo OO
generalizvel".
A figura abaixo ilustra a ao como deve ser declarada no XML de definio do assistente.

Figura G23.10. Template "action-evento-especifico-ManterClasse-criacao.vm" definido na ao PlcCriarClasse.

O groovy "PlcCriarClasse" ir utilizar como template o arquivo "action-evento-especifico-manterclassecriacao.vm", que est definido no cdigo abaixo.

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;
}
}
Cdigo G23.7. Contedo do template Velocity para gerao da classe.

- Configurando a gerao de boto especfico no arquivo "geralAcoesComplemento.xhtml"

Ao contrrio dos casos anteriores, este ltimo ilustra um tipo de modificao que no realizada por
nenhum assistente padro do jCompany, comprovando a flexibilidade e poder dos assistentes dinmicos
providos pelo jCompany Extensions.
Queremos definir um nova ao que reutilize o Groovy "PlcAlterarArquivo" para alterar o arquivo
"geralAcoesComplemento.xhtml", utilizado como padro no jCompany para conter botes adicionais aos
bsicos de manuteno. Este boto dever aparecer junto barra de aes e disparar a importao em
si, implementada na classe Java cujo esqueleto geramos nos passo anterior.

Figura G23.11. Definio da ao que ir utilizar o template "altera-geral-acoes.vm".

Precisaremos ento criar o template Velocity "altera-geral-acoes.vm" conforme visto no Cdigo G23.8.

## Criando declarao do evento para Caso de Uso Padro

<plcf:botaoAcao urlIcone="ico iEspecifico" label="jcompany.evt.${contexto.nomeEvento}"
action="#{plcAction.${contexto.nomeEvento}}" rendered="#{requestScope.plcActionSemBarra ==
'${contexto.casouso}'}"/>
Cdigo G23.8. Contedo do arquivo "altera-geral-acoes.vm".

Importante: Alm disso, neste caso precisamos definir ainda um ponto de insero no arquivo
"geralAcoesComplemento.xhtml", para evitar erros de interpretao do gerador, em situaes onde
existam contedos complexos neste arquivo. Note que possvel se definir este ponto (um comentrio
padro) nos templates INI utilizados pela organizao, de modo que j venham pr-configurados em
todos os seus projetos:

Figura G23.12. Exemplo de comentrio definindo ponto de insero no arquivo "geralAcoesComplemento.xhtml"

Com isso, finalizamos todas as configuraes necessrias para disponibilizar nosso novo componente OO
com um assistente que apie decisivamente seu reso, inclusive gerando todas as partes especficas e
que no foram possvel de ser generalizadas.

Disponibilizando e Reutilizando um Novo Padro jCompany Extension

- Disponibilizando o novo padro para a empresa
Para disponibilizar este e outros padres de Caso de Uso criados via jCompany Extension, o Arquiteto de
Software deve manter um catlogo de ativos reutilizveis em algum repositrio corporativo, como o
Maven Archiva, por exemplo, que o aplicativo homologado pelo jCompany QA Suite.
Para disponibilizar o 'plugin eclipse dinmico' em seu ambiente, caso o desenvolvedor possua o projeto
jCompany Extension, a tarefa Maven "instalar projeto no repositrio local" deve ser executada no projeto
relacionado. Caso contrrio, ao informar essa dependncia no arquivo pom.xml, o artefato ser baixado
para o repositrio local automaticamente.
O prximo passo ser fazer com que o ambiente Eclipse dos desenvolvedores reconhea o novo
assistente. Para tanto necessrio modificar o arquivo "extensions.properties" que se encontrado na
pasta raiz do plugin "Gerador Dinmico", instalado como padro em
"[jcompany_base]/eclipse/pluginsPlc/powerlogic/eclipse/plugins/
com.powerlogic.jcompany.ide.geradordinamico_[versao]"*.
Esse arquivo fornece ao plugin a localizao dos arquivos JAR dos jCompany Extensions criados. Novos
padres devem ser inseridos no padro abaixo:
[nomedoprojetoextension] = [Subdiretrio do jCompany Extension criado, comeando do repositrio].
Importante: Esta configurao na verdade uma limitao atual da soluo, que dever "descobrir"
dinamicamente estes diretrios em verses futuras do jCompany Extensions. Deste modo, a configurao
por parte do desenvolvedor se limitar ao seu trabalho tpico 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 padro, para que
aparea nos assistentes do Eclipse.

Caso a sua verso 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 no a gerao de artefatos

O trabalho de criao dos assistentes e geradores que tivemos at aqui, embora no seja muito
extensivo, tambm no desprezvel. 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 critrio qual a real
probabilidade de reuso do padro e valor que a gerao de cdigo trar, em cada contexto.
Por exemplo, caso o Arquiteto de Software estime que um novo padro recorrente ocorra dezenas de
vezes pelas aplicaes da empresa, o custo/benefcio possivelmente ir compensar. No somente na
forma de produtividade, mas tambm no reforo ao aprendizado e padronizao (ganhos na
manuteno). Mas caso ele perceba que haja menor previsibilidade ou probabilidade de ocorrer, talvez
valha pena ficar apenas na parte OO da soluo, orientando seu reso apenas com documentao.

- Reutilizando o padro "importacao" no projeto "rhtutorial"

Retornando ao nosso caso, vamos agora parte final. Aps termos o novo padro 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 devero trazer retorno ao nosso esforo
investido.
Vamos ento criar uma "Importao de UF" simulada, no projeto "rhtutorial".
Aps a criao da classe e mapeamento da mesma atravs da opo "01 Mapear Objeto Relacional"
acione os assistentes do jCompany para criao de Caso de Uso, atravs 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 padro exibindo opo para assistentes dinmicos.

Ao clicar em "next" vamos para a tela de seleo de assistente dinmicos. Perceba que todos os novos
padres so exibidos no segundo passo, conforme mostra a Figura G23.15.

Figura G23.15. Passo de seleo de novos assistentes de gerao do jCompany Extensions.

Aps selecionar o Caso de Uso Padro "Manter Classe Importao" clique novamente em "Next" para
seguir para o primeiro passo do assistente dinmico, ilustrado na Figura G23.16.

Figura G23.16. Primeiro passo do assistente dinmico, exibindo campos conforme configuraes do arquivo XML.

Uma vez definida a entidade e informaes bsicas, vamos para o passo de configurao da classe de
Action. A Figura G23.17 mostra o resultado das configuraes feitas para o passo 2.

Figura G23.17. Segundo passo, com as configuraes 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 opes de configurao para gerao
para cada uma delas. A Figura G23.18 mostra este passo j devidamente preenchido.

Figura G23.18. ltimo passo, de edio de propriedades da Entidade para gerao do formulrio.

Aps clicar no boto "Finish", o gerador dinmico ir processar e executar as aes Groovy definidas ao
final do XML, conforme vimos, gerando ento todos os artefatos necessrios para que o desenvolvedor j
obtenha o Caso de Uso em estgio prximo ao final. Neste caso, restando apenas a implementao do
algortimo especfico de importao em si (futuramente o Arquiteto de Software tambm 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 variaes sutis necessrias em cada caso especfico - mas se j fizer a liberao de
imediato ele pode comprovar que o resultado final j tem qualidade de produo e est bastante
finalizado e em conformidade com o padro definido!

Figura G23.19. Formulrio com novo padro funcional.

- Programao do cdigo de importao

Como vimos, no ponto em que est nosso padro j impede a criao ou excluso manual, pelo usurio,
de novas entradas de UF, alm de prover um boto e classe especificamente projetados para a
implementao da importao em si.
Na hiptese deste exemplo imaginamos que o endereo do arquivo ser obtido de modo genrico neste
algoritmo. Mas voc seria capaz de modificar o padro para incluir um campo de seleo de arquivo para
importao, por exemplo, no incio do formulrio?

Sumrio
Neste captulo introduzimos a nova tecnologia do jCompany Extensions, que permite aos Arquitetos de
Software criarem novos padres de alto nvel similares aos do jCompany, englobando generalizaes OO
(derivadas ou no de padres existentes) e, opcionalmente, opes complementares de gerao de
artefatos.
Experimentamos a flexibilidade de se especializar o comportamento do jCompany atravs do DP Observer
via novo padro CDI e discutimos em quais cenrios cada tcnica de especializao se encaixa melhor:
DP Template Method para soluo 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 escalvel.
Construimos um novo padro com base em uma primeira extenso bastante simples, porm ressaltando
as inmeras possibilidades de uso deste novo e poderoso recurso.