Conhecendo o Ajax4Jsf

Rafael de Paula Souza (rafael.bnc@gmail.com), está cursando Engenharia de Computação na FURG. Atualmente faz estágio na área de soluções para Web em Java, utilizando JSF e demais frameworks.

Introdução

Ajax4Jsf é um framework que adiciona capacidade Ajax nas aplicações que utilizam JSF sem recorrer ao JavaScript. O principal objetivo do framework é fazer chamada das Actions ou ActionListeners no Managed Bean de forma assíncrona, obedecendo todo ciclo de vida do Faces, e depois fazendo uma atualização de um ou mais componentes especificados nos atributos da tag.

 

Instalação

A instalação do Ajax4Jsf é muito fácil, para isso basta seguir os passos a seguir.

·         Fazer download da distribuição em – http://labs.jboss.com/portal/jbossajax4jsf

·         Copiar os Jars “ajax4jsf-1.1.0.jar” e “oscache-2.3.2.jar” do Ajax4Jsf para a pasta WEB-INF/lib da sua aplicação.

·         Adicionar as configurações do filter do Ajax4Jsf no arquivo web.xml.  

·         Importar o ajax4jsf nas paginas da sua aplicação.

 

 

Configurando o web.xml

Adicione a seguinte configuração no arquivo web.xml:

<context-param> 

        <param-name>org.ajax4jsf.SKIN</param-name>

        <param-value>classic</param-value> 

</context-param>

<filter> 

<display-name>Ajax4jsf Filter</display-name>

<filter-name>ajax4jsf</filter-name>

<filter-class>org.ajax4jsf.Filter</filter-class> 

</filter>

<filter-mapping>

<filter-name>ajax4jsf</filter-name>

<servlet-name>Faces Servlet</servlet-name>

<dispatcher>REQUEST</dispatcher>

<dispatcher>FORWARD</dispatcher>

<dispatcher>INCLUDE</dispatcher>

</filter-mapping>

 

E para importar o ajax4jsf na sua pagina jsp use:

<%@ taglib uri=https://ajax4jsf.dev.java.net/ajax&#8221; prefix=“a4j”%>

 

Se você estiver trabalhando com facelets:

<xmlns:a4j=https://ajax4jsf.dev.java.net/ajax&#8221;>

 

AJAX Requests

Existem diferentes formas para fazer que suas paginas enviem AJAX requests. Para isso, você pode usar as seguintes tags: <a4j:commandButton>, <a4j:commandLink>, <a4j:poll> e <a4j:support>.

 

Essas tags escondem do programador o JavaScript que é necessário para enviar AJAX requests,  o que facilita muito o desenvolvimento de aplicações que utilizam essa tecnologia. Elas também permitem que você escolha quais componentes de sua pagina que serão “modificados” após o AJAX response (você pode listar os IDs desses componentes através do atributo “reRender”).

 

<a4j:commandButton> e <a4j:commandLink>: essas tags são usadas para enviar AJAX request através do evento “onclick”.

<a4j:poll>: usada para enviar AJAX request em um determinado tempo.

<a4j:support>: permite que qualquer componente JSF faça AJAX request através de um determinado evento JavaScript: “onkeyup”, “onmouseover”, etc.

 

Exemplos:

<h:inputText value=“#{pessoa.nome}”>

        <a4j:support event=“onkeyup” reRender=“texto”/>

</h:inputText>

<h:outputText id=“texto” value=“#{pessoa.nome}”/>

 

 

<h:form id=”form”>

        <h:inputText value=“#{pessoa.nome}”/>

        <h:inputText value=“#{pessoa.rg}”/>

        <h:inputText value=“#{pessoa.cpf}”/>

        <a4j:commandButton reRender=“form” action=“#{pessoa.atualizar}” value=“Atualizar” oncomplete = “alert(‘Dados atualizados’)”/>

</h:form>

Anúncios

Delphi for PHP

27 de Fevereiro de 2007 Splash Screen do Delphi for PHP É um pássaro, um avião? Será mesmo que o Delphi for PHP será o Superman da WEB? Depois de desistir do mercado de IDE’s e colocar à venda sua popular suite, a Borland volta atrás e divide as operações da empresa para manter os produtos. Parece que a nova empresa está com todo o gás, pois anunciou um novo IDE: Delphi for PHP. Na verdade a ferramenta foi adquirida da Qadram Software Development que desenvolveu um IDE idêntico ao Delphi chamado QStudio. A notícia é no mínimo interessante. Será que a CodeGear (nova empresa da Borland) vai manter o sucesso do Delphi (Pascal) com este novo produto?

A Borland sempre foi conhecida pelo seu pioneirismo quando o negócio é disponibilizar tecnologias emergentes em seus produtos. Mas será que desta vez podemos chamar isto de inovação? Unir a produtividade do Delphi com a facilidade do PHP é bastante tentador, mas a esta altura do campeonato será que ainda temos mercado para isto? É certo que a maioria dos projetos Open Source WEB são em PHP, mas ao que tudo indica o IDE será pago afastando esta possibilidade para popularizar o produto.

Às vezes me pergunto se não seria tarde para um IDE proprietário entrar no mercado tentando facilitar o desenvolvimento de uma linguagem que já é uma das mais produtivas. Uma coisa é certa: Borland é Borland e já me surpreendi muito com a qualidade de seus produtos. Acho que o mercado de IDE proprietária ficou no passado e a maior contribuição que pode ser feita é realmente liberar o código para projetos Open Source. A própria comunidade deveria ser responsável por evoluir a suite ajudando a própria Borland a popularizar seus outros produtos que funcionariam integrados a esta suíte. As respostas para tantas dúvidas, só o tempo pode responder. Vamos aguarda o lançamento do novo IDE.

Para saber mais:
http://dn.codegear.com/article/34059 http://www.codegear.com/Products/Delphi/DelphiforPHP/tabid/237/Default.aspx

Design Patterns

Extraído do site www.portaljava.com

 

Portal Java Tutorial: Design Patterns por Dennys Fredericci Introdução Básica

Primeiramente precisamos saber o que é um Design Pattern.

Design Pattern é uma forma padrão de organizar classes e objetos, nomes para soluções que você já modelou, uma forma de compartilhar conhecimentos sobre POO, soluções de POO para problemas que incidem em diversos cenários de desenvolvimento, etc.

Quando adotamos o uso de Design Patterns seu código fica mais organizado, aumenta a qualidade, menor complexidade, aumenta a comunicação dentro da equipe de desenvolvimento, etc.

A definição de um pattern pode conter:

            Um nome: Transfer Object

            Um outro nome(also know as): Value Object

            Um problema: alguma entidades contém dados que são sempre lidos em grupo…

            Uma solução: serializar todos os dados da entidade em um objeto…

 

Familia de Patterns GoF

GoF é uma familia de Design Patters, são 23 padrões, veja alguns:

            Criação: Abstract Factory, Builder, Factory Method, Prototype, Singleton

            Estrutura: Adapter, Bridge, Composite, Decorator, Facade, Flyweight, Proxy

            Comportamento: Chain Of Response, Command Interpreter, Mediator, Memento, Observer, State, Strategy, Template Method, Visitor.

 

Familia de Patterns J2EE

            • J2EE: Busness Delegate, Composite Entity, Composite View, Data Access Object, Fast Lane Reader, Front Controller, Intercepting Filter, Model-View-Controller, Service Locater, Session Facade, Transfer Object, Value List Handler, View Helper

Você pode consultar o catalogo de Patterns do J2EE no endereço abaixo.

http://java.sun.com/blueprints/patterns/catalog.html

 

Patterns e Certificação

As seguintes certificações Sun exigem conhecimentos de Patterns:

            • Sun Certified Web Component Developer

            • Sun Certified Enterprise Architect;

 

Para quem pretende tirar uma destas certificações é necessário estudar todos os patterns, aplicar na prática os principais GoF e conhecer a teoria básica dos mais obscuros;

Alguns Patterns

Service Locator

            Definição: simplifica o acesso a recursos J2EE em um aplicativo centralizando lookups com JNDI em classes específicas de localização de serviços.

            • Evita que sua solução tenha alto acoplamento com JNDI Naming Service;

            • Tomar cuidado com Service Locates e cluster!

            • Utilize sempre que possível ENC.

            • Exemplo no JAREF(J2EE Architecture, Research and Education Framework);

 

Data Access Object

            Definição: centraliza o serviço de persistência de objetos em um pequeno conjunto de classes, evitando por exemplo que o código SQL se espalhe pelo código da solução.

            • Mesmo utilizando framework de persistência, utilize Data Access Object

            • Exemplo no JAREF(J2EE Architecture, Research and Education Framework);

 

Model View Control

            Definição: divide o aplicativo em dados, comportamento e apresentação.

            • Aplicando o MVC podemos reaproveitar o mesmo dado para múltiplas visualizações;

            • Podemos reaproveitar o comportamento(eventos) da solução;

            • É um pattern de arquitetura, criado há muito tempo. Pode ser aplicado em qualquer linguagem, mais facilmente com OOP.

            • Struts, WebWork, Spring, PicoContainer são exemplos de frameworks J2EE.

            • Link comparativo de frameworks MVC: https://equinox.dev.java.net/framework-comparison/WebFrameworks.pdf

 

Front Controller

            Definição: centraliza requests em um ponto central na solução.

            • No lugar de um JSP submit para ouro JSP todos os JSP’s “subments” para um Servlet Controller que será responsável por processar as requisições.

            • Exemplo no JAREF(J2EE Architecture, Research and Education Framework);

 

Command / Action

            Definição: encapsula uma requisição ao software em um objeto.

            • Transforma métodos em classes

            • Facilita o desenvolvimento de undo/redo

            • Aumenta a granularidade do código, permitindo o reuso

            • Action do Struts é o principal exemplo de implementação deste pattern

 

Factory

            Definição: instancia classes conforme demanda, recebendo parâmetros indicativos do objeto a ser instanciado.

            • É comum o Controller “inchar”, pois nele incide todas as solicitações externas. Como uma maneira de resolver esse tipo de crescimento desordenado, é sugerido que o Command seja criado sob demanda, e deixa por conta de uma Factory a instanciação das classes Command necessárias.

 

Dispatcher to views

            Definição: gerencia a saída de informações para a interface desejada pelo cliente. Desatrela a forma de se enxergar os dados para múltiplas visões.

            • É uma maneira de se implementar M. V. C. na sua essência, como o Smalltalk pregava.

 

Intercepting Filter

            Definição: forma para executar pré e pós processamento em request da solução.

            • Um Servlet Filter é um exemplo de implementação de um Intercepting Filter para interceptar requests no Web Container;

 

View Helper

            Definição: simplifica a “redenrização” de objetivos em views com formatação.

            • Uma Custom Tag pode representar uma View Helper;

            • Uma simples classe convencional com métodos estáticos também;

            • Exemplo no JAREF(J2EE Architecture, Research and Education Framework);

 

Business Delegate

            Definição: em aplicações distribuídas, o acesso remoto/local a EJB’s via JNDI Naming Service e tratamento de erros podem se tornar complexo à medida que o projeto cresce.

            Solução: criar uma classe intermediaria para acessar os EJB’s que contempla as regras de nomes de componentes para lookups, propriedades do servidor J2EE, tratamento de exceptions, etc;

Conclusão

            • Os patterns J2EE são pouco fáceis de entender;

            • Utilizando patterns você cria soluções padronizadas, facilitando a troca de programadores;

            • Você pode criar seus próprios patterns;

            • O site theserverside.com contém vários patterns fora do catálogo J2EE e GoF;

O que o AJAX.NET não tem?

 

Vale a pena utilizar o AJAX.NET da Microsoft ou construir a própria biblioteca AJAX?Já coloquei muito a mão na lama, mas depois de algum tempo, você passa a gerenciar projetos ou tocar uma empresa e perde o contato com os detalhes das coisas.

Por outro lado é necessário tomar decisões tecnológicas que irão afetar a empresa onde você trabalha. Estive nessa situação há alguns meses. Ir de AJAX.NET ou desenvolver uma biblioteca AJAX própria?

Pedi uma análise e uma indicação para dois dos engenheiros de software da nossa empresa sobre a proposta da Microsoft. Eis aqui o relatório.

Problemas do ASP.NET

Tudo começou quando a Microsoft introduziu o ASP.NET, uma versão aprimorada do ASP. Ela adicionou a arquitetura .NET uma tecnologia para produção de páginas web, os WebForms. Com eles se pode criar uma interface visual com o usuário de forma semelhante à feita usando o Visual Basic. A sua arquitetura é baseada no servidor.

Para criar uma página ASP.NET você tem a disposição os HTMLControls, que não são processados pelo servidor quando o usuário interage com os mesmos, e os WEBControls, que são processados pelo servidor quando existe interação.

Ao abrir uma página ASP.NET, o cliente (navegador do usuário) exibirá o resultado HTML/JavaScript de um WebForm processado pelo servidor. Quando o cliente interagir com a página, ela será transmitida de volta ao servidor, alterada e depois restaurada de volta ao cliente. E sempre que ocorrer uma interação do usuário com um controle que disparar um evento, este caminho será seguido, do cliente para o servidor e de volta ao cliente. Deu-se a isto o nome de postback.

Nessa arquitetura, o cliente é “burro” e 100% da lógica de negócio fica a cargo do servidor. Do ponto de vista do desenvolvedor isso é ótimo, facilita o desenvolvimento com a utilização dos WebControls. Mas e o usuário, onde fica?

Assim, para cada interação complexa existe um postback e para cada postback um tempo de espera. Você provavelmente estará destruindo a usabilidade de seu site e a paciência de seus usuários.

Em um exemplo simples, basta imaginar um formulário com quatro combos encadeadas e algumas validações. A página executará no mínimo quatro postbacks. A página inteira irá quatro vezes para o servidor e retornará ao cliente. Haja paciência.

Solução aos postbacks?

O modelo ACSC (Asynchronous Client/Server Communication) é muito mais interessante para o usuário que o modelo WebForm/Postback do ASP.NET e abre um leque de possibilidades de interação antes impraticáveis.

O amadurecimento e a consolidação das tecnologias ACSC (e a popularidade da implementação desse modelo com o AJAX), onde o recarregar de páginas inteiras é substituído por requisições assíncronas do cliente ao servidor e atualização somente da parte onde ocorreu interação com o usuário, obrigou a Microsoft a atualizar sua arquitetura para suportar o modelo ACSC, de modo a evitar que o ASP.NET não perdesse seu mercado.

Para manter a compatibilidade com códigos já existentes em ASP.NET 2.0, a Microsoft desenvolveu parte do Atlas baseada em sua antiga arquitetura, a centralizada no servidor (Server centric), onde o comportamento de postback dos WebControls é modificado, mas ainda assim a lógica do negócio fica toda no lado servidor. Isso é contrário ao verdadeiro modelo ACSC, onde a lógica do negocio é dividida entre o cliente e o servidor e centralizada no cliente (Client centric).

O Atlas Server Centric é baseado em painéis Ajax onde é possível inserir os WebControls já existentes do ASP.NET. Uma vez dentro do painel Ajax o postback do WebControl será substituído por uma requisição assíncrona ao servidor. O modo centralizado no servidor é na verdade apenas uma “maquiagem” para as páginas ASP.NET, já que toda lógica de negócio fica no servidor.

Nenhuma inteligência complexa é mantida no cliente. Todos os postbacks continuam sendo realizados por baixo da “máscara” do XMLHttpRequest e, como todos os WebControls ainda continuam sendo processados no servidor, o retorno do Atlas Server Centric é HTML (AJAH – Asynchronous JavaScript and HTML) e não AJAX.

Isso torna o overhead e o trafego muito maiores já que ao invés de retornar uma estrutura apenas com os dados relevantes o Atlas Server Centric retorna os dados em conjunto com HTML.

Decisão: nossa Biblioteca vs. Atlas

Tomamos a decisão de construir uma biblioteca própria para diminuir o overhead de transmissão de dados – já que isso é crítico -, a serialização e os recursos encapsulados para facilitar realmente a vida do programador. Criamos a Naja.NET.

O Atlas Client Centric tem uma arquitetura muito parecida com o framework Naja.NET. Segue o mesmo modelo, porém o Atlas Client Centric é um framework sem todos os recursos do Naja.NET, sem toda a extensão do JavaScript e sem todos os objetos portados do .NET que o framework Naja.NET possui.

A falta de serializadores e conversores de tipos complexos (como DataTable, XmlDocument, etc.) também é uma desvantagem do Atlas Client Centric em relação ao Naja.NET, que consegue converter praticamente qualquer tipo do .NET para qualquer tipo do JavaScript.

A serialização do Naja.NET também tem a vantagem de ser mais inteligente e com maior desempenho. Conforme o problema o framework escolhe entre a serialização JSON (JavaScript Object Notation) ou o retorno puro de JavaScript. Outra grande vantagem do Naja.NET é o suporte ao Framework .NET 1.1 e 2.0. O Atlas suporta apenas o framework 2.0.

A extensão do JavaScript padrão também é superior no framework Naja.NET, e conseqüentemente facilita a vida do desenvolvedor que não precisará estender o JavaScript por conta própria para atender suas necessidades e nem utilizar bibliotecas de terceiros que podem apresentar problemas de compatibilidade.

* Otávio Medeiros Dias e Marcell Dietrich Felipe Duran são engenheiros de software da Voxel Informática e colaboraram com os dados relevantes desta coluna.

Nivaldo Foresti é programador há 30 anos, desde a jurássica era do mainframe. Foi consultor e desenvolvedor de produtos na internet como o BOL e hoje tem uma empresa de webcasting, com software nacional. Neste espaço, o colunista revela o que os desenvolvedores podem esperar da profissão, além de analisar as novas eras tecnológicas que se aproximam. E-mail: nforesti@yahoo.com .