# Set root category priority to INFO and its only appender to CONSOLE.
log4j.rootCategory=INFO, CONSOLE

# Set the hbm2ddl logger category to FATAL and its only appender to CONSOLE.
log4j.logger.org.hibernate.tool.hbm2ddl=FATAL, CONSOLE

# CONSOLE is set to be a ConsoleAppender using a PatternLayout.
log4j.appender.CONSOLE=org.apache.log4j.ConsoleAppender
log4j.appender.CONSOLE.Threshold=INFO
log4j.appender.CONSOLE.layout=org.apache.log4j.PatternLayout
log4j.appender.CONSOLE.layout.ConversionPattern=%-4p: %c{1} %m%n

A maior revista sobre Java do país, que agora se chama MundoJ, está na edição 42 com um artigo sobre o Next Framework. O artigo está em formato de tutorial, bastante detalhado, sobre como criar uma aplicação do tipo Blog. Abrange vários assuntos, desde a criação de CRUDs, validação até upload de arquivos.

Parabéns e obrigado a todos os usuários do Next Framework que possibilitam o crescimento e a qualidade da ferramenta.

Possibilidade de usar a configuração simplificada de banco de dados (via connection.properties) para todos os bancos que o Hibernate suporta.

Possibilidade de configurar o dialeto do banco através do arquivo hibernate.properties.

Simplificação das actions do MultiActionController.

Action até a versão 3.5.0:

Action a partir da versão 3.5.1:

A forma antiga continua funcionando, não será necessário atualizar os seus controllers ao migrar a versão.

Vários bugs corrigidos e algumas melhorias.

     Para resolver o problema do mapeamento objeto/relacional temos como exemplo o Hibernate. Para resolver o problema da dependência entre os objetos podemos utilizar o Spring. Além desses problemas que surgiram apenas por necessidades arquiteturais de um sistema, no ambiente web também temos os problemas de comunicação entre cliente e servidor. Onde informações devem ser trocadas por um meio onde apenas Strings são transferidas, que é o protocolo HTTP. O próprio Spring tem um modelo MVC para ajudar a solucionar esse problema.

     Com esses dois frameworks, Hibernate e Spring, podemos então solucionar grande parte dos problemas estruturais de uma aplicação. Conseguimos desenvolver em um nível mais alto, já que os problemas mais básicos estão resolvidos. Nesse nível mais alto temos agora, que integrar os dois frameworks. O Spring possui classes já preparadas para a integração com o Hibernate. Mas mesmo utilizando os recursos mais automatizados do Spring, ainda será necessário a utilização de um XML para configurar DataSources, HibernateTemplates, TransactionTemplates, etc. A mesma coisa acontece com o Spring MVC, será necessário configurar qual engine de templates utilizar, como serão resolvidas as URLs e com isso mais um XML será criado.

     Se pensarmos que a única informação realmente relevante para o Hibernate e toda a configuração de persistencia do Spring são o caminho para o banco de dados e quais são as classes que serão mapeadas, ainda temos muito trabalho configurando informações que praticamente não mudam. Ou seja, as classes que serão mapeadas serão as que tiverem a anotação @Entity e o dataSource, hibernateTemplate, transactionTemplate serão configurados de acordo com o caminho banco de dados. Com base nisso as informações realmente relevantes são url, driver, usuário e senha do banco de dados. Para que tanto XML e configuração sendo que tudo é baseado apenas no caminho do banco de dados? No caso do Hibernate por exemplo, porque sempre temos que informar o dialeto sendo que o dialeto já é especifico para cada SGBD? Acho que ninguém usa um dialeto do PostgreSQL em um banco MySQL. Ainda podemos eliminar trabalho na área de persistencia.

     Vamos pensar agora na camada de visão da aplicação, considerando que o usuário do sistema o utilizará através de um browser lendo HTML e conversando HTTP. A base que temos é: um servlet receberá os parâmetros e deverá montar alguma resposta com base na requisição. Utilizando o Spring MVC, elevamos essa base para algo mais interessante, com a possibilidade de mapear os parâmetros recebidos em objetos e redirecionar a requisição para um template que irá montar a resposta. A camada de controle, deve estar alinhada com a camada de visão pois o que a visão renderizar será a causa de uma nova requisição, logo os parâmetros dessa nova requisição devem condizer com que o controle espera. Quando desenvolvemos aplicações JEE a camada de visão é quase sempre JSP. O Spring MVC possui algumas tags para facilitar a montagem dessa resposta no JSP de acordo com que o controle espera. Mas essas tags não são completas.

     Quando vamos montar um HTML temos alguns problemas básicos a enfrentar. O primeiro é que precisamos navegar em objetos e seus atributos para recuperar o modelo que será utilizado na renderização. Ou seja, precisamos recuperar o valor do atributo nome do objeto que está no escopo de requisição com o nome pessoa.

     Depois que navegamos nos objetos disponíveis e escolhemos os atributos a serem mostrados, temos que escolher se mostramos esse valor como output, ou seja, apenas para leitura do usuário. Ou, como input, o usuário irá preencher esse valor, que deve ser lido pelo controle posteriormente. Nesse caso já vemos que o controle deve estar alinhado com a camada de visão.

     As informações mostradas no HTML não podem ficar soltas, precisamos de algumas tags como DIVs ou TABLEs para organizar o conteúdo na página.

     E finalmente precisamos ter algum meio de navegação, onde podemos criar formas de o usuário acessar as várias funcionalidades de um sistema.

     De todos esses problemas que estão presentes na montagem de um JSP, o único que as tags do Spring implementa de forma que auxilia o desenvolvedor é a navegação entre os objetos. No ambito de escolher entre input, output, organizar as informações no HTML e ainda dar estilo, o Spring MVC não consegue auxiliar tanto. Por isso o Spring MVC não é tão produtivo para a camada MVC da sua aplicação. Mas ainda assim é melhor que um servlet puro.

     Com base nesses problemas levantados, vemos que ainda restam várias brechas que os frameworks de mercado não resolvem, e talvez nem esteja no escopo deles resolver. É justamente nessas brechas que o Framework Next atua. Os problemas citados nesse artigo são resolvidos pelo Next de forma que o desenvolvedor não precise se preocupar com eles. Para configurar o Next com o Hibernate, e todos os objetos do Spring que dão suporte ao Hibernate por exemplo, basta um arquivo connection.properties que contém apenas a url, driver, usuário e senha do banco de dados. Todas as outras configurações são feitas pelo Next, você só precisará modificá-las caso necessite. Na camada de visão o Next tem um grupo de tags para trabalhar com cada um dos problemas citados. Como os problemas estão separados em cada grupo, um número pequeno de tags consegue resolver a maior parte dos problemas. O Next também melhora a camada de controle com mais suporte e integração com a camada de visão. E outras situações que não falamos aqui, como autorização e autenticação, upload de arquivos, AJAX, relatórios e casos de uso que são padrão como CRUDs também são tratados pelo Next.

     Vemos que o Next não tenta reinventar a roda, ele utiliza ao máximo os frameworks de suporte e vai além, provendo uma plataforma de mais alto nível para dar mais produtividade ao desenvolvimento de aplicações JEE.

Foi publicado um link para o lançamento do Next Framework no site do UOL Tecnologia, dia 03/03/2010. http://tecnologia.uol.com.br/programacao

Utilizaremos os recursos de geração de tabelas do Hibernate para isso.

O primeiro passo é criar dentro da pasta src (ou a pasta fonte da sua aplicação) o arquivo hibernate.properties.

Nesse arquivo podem ser colocadas qualquer configuração do hibernate, não apenas a apresentada nesse tutorial.

Edite o arquivo hibernate.properties criado e adicione a seguinte linha:

hibernate.hbm2ddl.auto=update

Isso fará com que o hibernate atualize a estrutura do banco de dados de acordo com as alterações das entidades. Sempre que houver alguma modificação como adição ou remoção de atributos, novas entidades, ou qualquer outra alteração que necessite modificar a estrutura do banco, o hibernate fará o trabalho pra você.

Ao publicar a sua aplicação o arquivo hibernate.properties deve ficar em WEB-INF/classes.