Update http://www.nextframework.org/download/next-3.5.3_01.jar

Download JAR next-3.5.1-build20110420.jar
Download Source next-3.5.1-build-20110420-src.zip
Release Notes

Essa versão não foi disponibilizada na seção de downloads pois é um nightly build.
Será necessário fazer o download do arquivo 3.5.1-Full na seção de downloads.
Para utilizar essa versão substitua o JAR do Next, pelo JAR dessa versão.
(Se ao fazer o download, a extensão do arquivo vier como .zip, basta renomear para .jar)

Chamadas AJAX são basicamente invocações de métodos no servidor de forma assincrona, onde é possível atualizar partes da página atual ou executar operações no servidor sem a necessidadde de recarregar a página inteira. Isso economiza recursos tanto do servidor quanto do cliente, possibilitando aplicações mais ricas e ao mesmo tempo mais eficientes. É um recurso muito utilizado e dá bastante vida as páginas.

Para utilizar a tag a:call do next, é necessário que seu módulo utilize o arquivo base.jsp. Veja a documentação de referência para mais informações sobre o base.jsp. Capítulo 6 – MVC.

O primeiro passo para utilizar a tag, é importar a tag lib de ajax. Para isso, adicione no seu JSP o seguinte import.

<%@ taglib prefix="a" uri="ajax"%>

A taglib ajax possui apenas uma tag call. Dois atributos dessa tag são obrigatórios:

• functionName, que é o nome da função javascript que será gerada, e que poderá ser invocada pelos seus scripts.
• action, que é o nome da action no controller que irá receber a chamada.

A tag call possui outros 3 atributos, que são opcionais.

• callback, que é o nome da função javascript que irá receber a resposta do servidor. Se desejar você pode escrever uma função personalizada para tratar os dados recebidos. A função de callback padrão faz um eval do conteúdo retornado.
• parameters, que é a lista de parametros a ser passada para o servidor. Os parâmetros devem ser especificados na sintaxe de URL, ex: param1=value1&param2=value2.
• url, que é a url do controller para onde a chamada deve ser enviada. Se não for informado o controller chamado será o mesmo que recebeu a requisição que renderizou a página.

A seguir serão apresentados alguns exemplos de utilização da tag. A versão utilizada para testes dos exemplos é a 3.5.1.

Exemplo 1 – Básico

Nesse exemplo será mostrada a chamada mais simples de chama AJAX. Será renderizado um botão que ao ser clicado envia uma requisição ao servidor, que devolve um comando alert para o browser.

Controller

package controller;

import org.nextframework.controller.Controller;
import org.nextframework.controller.DefaultAction;
import org.nextframework.controller.MultiActionController;
import org.nextframework.view.ajax.View;

@Controller(path="/modulo/ajax")
public class AjaxController extends MultiActionController{

    /**
     * Action default.
     * Será chamada pelo browser diretamente para renderizar a página
     * @return
     */
    @DefaultAction
    public String pagina(){
        return "pagina";
    }

    public void actionAjax(){
        /*
         * A classe View possui alguns métodos para facilitar o envio de informações para o cliente.
         * Basicamente cada comando representa um print na saída do response.
         */
        View.getCurrent().alert("Conteúdo AJAX enviado pelo servidor");
    }
}

JSP (pagina.jsp)

<%@ taglib prefix="a" uri="ajax"%>

Essa é a página que utilizará AJAX.

<button onclick="chamarAjax()">Clique para efetuar o AJAX</button>

<a:call functionName="chamarAjax" action="actionAjax" />

Exemplo 2 – Alterando o conteúdo do HTML

No segundo exemplo iremos alterar o conteúdo de um DIV, com o conteúdo enviado pelo servidor.

Controller

package controller;

import org.nextframework.controller.Controller;
import org.nextframework.controller.DefaultAction;
import org.nextframework.controller.MultiActionController;
import org.nextframework.view.ajax.View;

@Controller(path="/modulo/ajax")
public class AjaxController extends MultiActionController{

    /**
     * Action default.
     * Será chamada pelo browser diretamente para renderizar a página
     * @return
     */
    @DefaultAction
    public String pagina(){
        return "pagina";
    }
    public void actionAjax(){
        //o eval só funcionará se a função callback do cliente for
        //a função default (ou seja, callback não especificado)
        View
            .getCurrent()
            .eval("document.getElementById(’conteudo’).innerHTML = " +
                    "’Novo conteúdo enviado pelo servidor’;")
            .eval("document.getElementById(’conteudo’).style.backgroundColor = " +
                    "’#DEDE55′;"); //é possível enviar vários comandos
    }
}

JSP (pagina.jsp)

<%@ taglib prefix="a" uri="ajax"%>

Essa é a página que utilizará AJAX.

<div id="conteudo" style="border:1px solid red">
Conteúdo que será alterado
</div>

<button onclick="chamarAjax()">Clique para efetuar o AJAX</button>

<a:call functionName="chamarAjax" action="actionAjax" />

Exemplo 3 – Enviando parâmetros para o servidor

Nesse exemplo é mostrado como é possível passar parâmetros para o servidor.

Controller

package controller;

import org.nextframework.controller.Controller;
import org.nextframework.controller.DefaultAction;
import org.nextframework.controller.MultiActionController;
import org.nextframework.view.ajax.View;

@Controller(path="/modulo/ajax")
public class AjaxController extends MultiActionController{

    @DefaultAction
    public String pagina(){
        return "pagina";
    }
    public void actionAjax(){
        //pegamos o parametro enviado pelo cliente para montar a resposta
        String id = getParameter("id");
        View
            .getCurrent()
            .eval("document.getElementById(’"+id+"’).innerHTML = " +
                    "’Novo conteúdo enviado pelo servidor’;")
            .eval("document.getElementById(’"+id+"’).style.backgroundColor = " +
                    "’#DEDE55′;"); //é possível enviar vários comandos
    }
}

JSP (pagina.jsp)

<%@ taglib prefix="a" uri="ajax"%>

Essa é a página que utilizará AJAX.

<div id="conteudo" style="border:1px solid red">
Conteúdo que será alterado
</div>

<button onclick="chamarAjax()">Clique para efetuar o AJAX</button>

<a:call functionName="chamarAjax" action="actionAjax" parameters="id=conteudo"/>

Exemplo 4 – Parâmetros Dinâmicos

É também possível montar os parâmetros dinamicamente via código javascript, para isso utilizaremos uma construção especial no atributo parameters. Antes de clicar no botão para chamar o AJAX preencha no input o valor 1, 2 ou 3.

Controller

package controller;

import org.nextframework.controller.Controller;
import org.nextframework.controller.DefaultAction;
import org.nextframework.controller.MultiActionController;
import org.nextframework.view.ajax.View;

@Controller(path="/modulo/ajax")
public class AjaxController extends MultiActionController{

    @DefaultAction
    public String pagina(){
        return "pagina";
    }
    public void actionAjax(){
        //pegamos o parametro enviado pelo cliente para montar a resposta
        String id = getParameter("id");
        View
            .getCurrent()
            .eval("document.getElementById(’"+id+"’).innerHTML = " +
                    "’Novo conteúdo enviado pelo servidor’;")
            .eval("document.getElementById(’"+id+"’).style.backgroundColor = " +
                    "’#DEDE55′;"); //é possível enviar vários comandos
    }
}

JSP (pagina.jsp)

<%@ taglib prefix="a" uri="ajax"%>
<%@ taglib prefix="n" uri="next"%>

Essa é a página que utilizará AJAX.

<div id="conteudo1" style="border:1px solid red;">
Conteúdo que será alterado 1
</div>
<div id="conteudo2" style="border:1px solid green;">
Conteúdo que será alterado 2
</div>
<div id="conteudo3" style="border:1px solid blue;">
Conteúdo que será alterado 3
</div>

Digite qual conteúdo deseja alterar (1, 2 ou 3): <n:input type="integer" value="1" id="numero"/>

<button onclick="chamarAjax()">Clique para efetuar o AJAX</button>

<a:call functionName="chamarAjax" action="actionAjax" parameters="javascript:’id=conteudo’+document.getElementById(’numero’).value"/>

Também é possível alterar a montagem dos parametros para delegar a uma função javascript, conforme exemplo:

<a:call functionName="chamarAjax" action="actionAjax" parameters="javascript:montarParametros()"/>

<script type="text/javascript">
function montarParametros(){
    return ‘id=conteudo’ +  document.getElementById(’numero’).value;
}
</script>

Como visto nos exemplos a chamada ajax no servidor é feita de forma bem simples. Basicamente a tag a:call monta a função javascript e você apenas chama na sua página onde for necessário. No servidor a classe View, possui alguns métodos utilitários para escrever no response.

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