JSF – Inicio Rápido – Final

PASSO ANTERIOR (PASSO 5).


Agora vamos a melhor parte do nosso projeto, os testes!
 
Veremos agora se tudo o que fizemos nos passos anteriores deu certo.


Primeiramente abra o navegador e digite http://localhost:8080/ProjetoX (ou o nome do seu projeto caso tenha utilizado outro).


Abriu a página inicial (menu.jsp)?


Se a resposta for afirmativa, teste a navegação, acesse o cadastro, veja como seu projeto está funcionando.
 
Se a resposta for negativa acredito que o server.xml não foi configurado automaticamente pela IDE, então vamos fazer a configuração manual.


Abra o arquivo server.xml, que está localizado dentro da pasta conf do seu Tomcat (instalou o Tomcat né?).
 
Vá para o final do arquivo e procure alguma tag parecida com esta:

<Host appbase=”webapps” name=”localhost”………..
<!– Um monte de comentários –>
</Host>

Esta tag indica que sempre que digitarmos localhost:8080 no navegador, alguma página (a do tomcat) irá abrir.
 
Mas não queremos ver a página do Tomcat, queremos ver a nossa página!
Então entre as tags <Host> e </Host>, alí onde estão os comentários, insira a seguinte tag:

<Context path=“/ProjetoX” docBase=“c:\projetos\ProjetoX\WebContent”
workDir=“c:\projetos\ProjetoX\work” reloadable=“true”/>

O que é isso?
Context é a tag que devemos criar para indicar um contexto do localhost, um “subdominio”.
path=”" é o nome que devemos indicar no navegador, ou seja, devemos digitar “http://localhost:8080/ProjetoX“.
docBase=”" é o local onde estão as páginas e o WEB-INF de sua aplicação, neste caso o MEU projeto está em c:\projetos\ProjetoX, e onde está a pasta WEB-INF? Exato, dentro da pasta WebContent, então devemos informar o caminho c:\projetos\ProjetoX\WebContent, mas esse é no meu computador, altere este caminho para o diretório onde a aplicação está instalada no seu computador.
workDir=”" , funciona da mesma maneira que o docBase, porém aqui devemos informar onde está a pasta work do projeto.
reloadable=”true” , esta linha indica que nosso projeto está em modo de desenvolvimento, e o servidor irá acompanhar de perto todas as mudanças que fazemos recarregando as classes do projeto todas as vezes que alguma alteração for detectada, porém para ambiente de produção, é recomendável colocar o atributo false, para desativar este acompanhamento de alterações.


Pronto, agora salve o arquivo e reinicie o Tomcat.
 
Abra o navegador e digite: http://localhost:8080/ProjetoX.
 
Se divirta!






Recomendações / Exercícios:


1 – Crie novas páginas para navegação, por exemplo, crie uma nova página de cadastro, com mais campos como Sobrenome, Endereço, idade, etç.
 
2 – Crie outro bean para este cadastro e crie métodos para validar se é menor de idade, redirecionando para páginas diferentes caso maior ou menor de idade, exibindo páginas de “erro” caso algo esteja errado, mais especificamente, crie uma página (jsp) genérica de erro que exiba uma mensagem do bean (o outputText pega uma variável do bean), se não foi digitado o endereço, coloque a mensagem na variável do bean “favor preencher o endereço”, se não preencheu a idade, coloque a mensagem “Favor preencher a idade“, etç. e retorna para a página de erro, esta página de erro vai exibir um outputText que copia a informação contida na variável do bean, a mensagem que você personalizou no método.
 
3 – Não se esqueça de configurar o faces-config, definindo as regras de navegação e o managed-bean.


Agora que você chegou até aqui e seu projeto está funcionando perfeitamente, você pode gritar ai “EU SEI FAZER UM SITE UTILIZANDO O FRAMEWORK JSF!!!!!!!!!!!!!!!!“.
 
E parabéns, agora você realmente conhece as principais funcionalidades do JSF, agora não pare por aqui, brinque, altere, crie, e desenvolva mais e mais páginas utilizando estas dicas.


Se quiser baixar este projeto (ProjetoX) finalizado e funcionando clique nestes links: RAR, ZIP ou JAR.


Para baixar um projeto JSF em branco, com toda a estrutura de pastas, arquivos de configuração criados e as bibliotecas necessárias, clique nos links: RAR ou ZIP.


Agora é por sua conta!


Obrigado por ter lido este tutorial, em caso de dúvidas em qualquer um dos passos, por favor comente!








Autor:
Reinaldo Elias
Analista de Sistemas – JavaMan
reinaldo558@gmail.com
http://codeerror.wordpress.com
http://pinguimtomandocafe.blogspot.com 

JSF, Inicio Rápido – Parte 5

PASSO ANTERIOR (PASSO 4).


Se você chegou até aqui, parabéns! Já leu muita coisa e já escreveu (ou copiou…) muitas linhas de código, mas o importante não é escrever com os próprios dedos, mas sim saber o que aquele trecho de código sgnifica, o que ele faz, como ele se comporta, etç.


Apenas recapitulando um pouco:


Criamos um Bean (testeBean.java) que tem um método testar(), este método faz uma verificação e retorna “falhou” caso não tenha sido digitado nada na tela, ou retorna “sucesso” caso os dois campos tenham sido populados pelo usuário.
 
Criamos também  uma página de menu (menu.jsp) que tem um botão que direciona para “cadastro“.
 
Criamos uma página de cadastro (inicio.jsp), esta página tem alguns campos que fazem referência à  “teste“.
 
Criamos uma página sucesso.jsp que tem um botão enviando para “inicio” e uma página falha.jsp com um botão direcionando para “cadastro“.


Ao longo deste projeto, criamos diversas páginas, todas apontando para algum “apelido“, para algum lugar imaginário que não existe. Todos estes apelidos são configurados no arquivo de configuração FACES-CONFIG.XML, é sobre este arquivo que iremos falar agora!


Faces-config, o coração do projeto JSF, o arquivo que faz todas as páginas se conectarem, se conhecerem, pode ser considerado também o “orkut” de uma aplicação JSF…


Este faces-config é um “arquivinho” xml qualquer, com algumas tags especiais que fazem o servidor encontrar todos os apelidos que distribuimos em nossas páginas.


Já criamos o arquivo nos passos anteriores, vamos então enfiar códigos nele!


Abra o arquivo faces-config.xml e insira as seguintes linhas de código:

<?xml version=”1.0″?>
<!DOCTYPE faces-config PUBLIC
“-//Sun Microsystems, Inc.//DTD JavaServer Faces Config 1.1//EN”
“http://java.sun.com/dtd/web-facesconfig_1_1.dtd”>
<faces-config>
<!– ################### NAVIGATION ###################–>
<navigation-rule>
<from-view-id>*</from-view-id>
<navigation-case>
<from-outcome>cadastro</from-outcome>
<to-view-id>/pages/inicio.jsf</to-view-id>
</navigation-case>
<navigation-case>
<from-outcome>falhou</from-outcome>
<to-view-id>/pages/falha.jsf</to-view-id>
</navigation-case>
<navigation-case>
<from-outcome>sucesso</from-outcome>
<to-view-id>/pages/sucesso.jsf</to-view-id>
</navigation-case>
<navigation-case>
<from-outcome>inicio</from-outcome>
<to-view-id>/pages/menu.jsf</to-view-id>
</navigation-case>
</navigation-rule>
<!– ################### MANAGED-BEAN ###################–>
<managed-bean>
<managed-bean-name>teste</managed-bean-name>
<managed-bean-class>br.com.projetox.view.bean.testeBean</managed-bean-class>
<managed-bean-scope>session</managed-bean-scope>
</managed-bean>
</faces-config>

Agora o que interessa, a explicação!


As primeiras linhas:
<?xml version=”1.0″?>
<!DOCTYPE faces-config PUBLIC
“-//Sun Microsystems, Inc.//DTD JavaServer Faces Config 1.1//EN”
“http://java.sun.com/dtd/web-facesconfig_1_1.dtd”> indicam que tipo de arquivo é este, são tags padrões que devem estar no cabeçalho de cada arquivo XML, dependendo da funcionalidade do arquivo as propriedades destas tags mudam um pouco, estas indicam que o arquivo é um “faces-config”.


As tags <faces-config></faces-config> presentes no inicio e no fim do arquivo indicam o começo e o fim dos comandos de configuração.
 
Assim como em JavaScript todos os comandos devem ser scritos dentro das tags <script> e </scritp>, todos os comandos de configuração do faces-config devem ser escritos entre as tags <faces-config></faces-config>, se você escrever alguma coisa fora não vai conseguir nem acessar a aplicação...

<navigation-rule> e</navigation-rule>
 
Regras de navegação.
Dentro destas tags indicaremos todas as nossas regras de navegação, mas o que seria uma regra de navegação? Seria basicamente informar: “saindo do jsp X, vai para o jsp Y”. Vamos ver com mais detalhes nas tags que estão dentro das navigation-rules.
<from-view-id>*</from-view-id>
Aqui estamos informando “saindo da jsp X…”, neste caso não temos uma regra específica, apenas informamos *, ou seja, qualquer página. Isso significa que não importa de onde venha a solicitação sempre terá o o destino, então a nossa “frase” ficaria mais ou menos assim: “Saindo de qualquer lugar, vai para o jsp Y” …
<navigation-case>
<from-outcome>cadastro</from-outcome>
<to-view-id>/pages/inicio.jsf</to-view-id>
</navigation-case>
Estas tags indicam o destino, o “vai para o jsp Y” e aqui definimos os apelidos dos destinos.
Todos os mapeamentos de destinos devem estar entre as tags <navigation-case> e </navigation-case>.


A tag <from-outcome>cadastro</from-outcome> é muito importante, aqui que configuramos um de nossos “apelidos”, neste caso o apelido “cadastro” que informamos na página menu.jsp, e também na página falha.jsp. Ou seja, a página menu.jsp, por exemplo, tem um link que direciona para o apelido “cadastro”, quando este link for acionado o servidor vai procurar o arquivo faces-config.xml, e perguntar para ele quem é “cadastro”, o faces-config por sua vez vai informar para o servidor que “cadastro” é…
<to-view-id>/pages/inicio.jsf</to-view-id> esta linha que indica que página o apelido cadastro deve chamar, neste caso estamos chamando /pages/inicio.jsf, note que estou chamando uma página com a extensão JSF e não com a extensão JSP, conforme explicação no passo anterior.


Então, de acordo com esta regra de navegação, sempre que de qualquer lugar do projeto alguem clicar em algum link “cadastro” a página inicio.jsp será acionada.

Nota adicional: Se quisermos deixar a arquitetura um pouco mais fechada, por exemplo, não queremos que “cadastro” seja chamado de qualquer lugar do projeto, mas somente da página principal, então na tag <from-view-id> devemos informar o nome da página principal.

As demais informações dentro das tags <navigation-rule> seguem o mesmo padrão do caso “cadastro“, nelas estamos configurando os outros apelidos como falhou e sucesso, que estão sendo utilizados no método testar() do nosso bean, e o apelido inicio que está sendo utilizado na página sucesso.jsp. Todos estes apelidos direcionam para alguma página dentro do nosso projeto.



Agora já configuramos quase todos os apelidos, falta o “teste” que está sendo utilizado na página inicio.jsp.
 
Neste caso é um pouco diferente, não estamos direcionando para alguma página, mas sim utilizando variáveis e métodos de uma classe, uma classe bean, então não podemos configurar uma regra de navegação pois esta não é uma regra, neste caso possuimos um BEAN, então é isto que devemos configurar.
<managed-bean> e </managed-bean>, estas tags informam o inicio e o fim da configuração de beans do projeto, todos os beans que vamos utilizar devem ser configurados dentro destas tags.
<managed-bean-name>teste</managed-bean-name>, é nesta linha que definimos o apelido do nosso bean, como ele deverá ser referenciado dentro de nossas páginas, neste casos estamos dizendo que o apelido do nossa classe testeBean.java será simplesmente teste.
<managed-bean-class>br.com.projetox.view.bean.testeBean</managed-bean-class>, nesta linha informamos o caminho completo e o nome da classe, para que o servidor consiga achar nosso bean quando este for solicitado por alguma página, neste caso a classe é testeBean (note que não é necessário informar a extensão da classe), e esta classe está dentro das pastas (pacote) br.com.projetox.view.
<managed-bean-scope>session</managed-bean-scope> esta linha indica como o servidor vai fazer a comunicação entre a página e o bean, se é por aplicação (application), se é por sessão (session) ou se é por solicitação (request). No nosso caso definimos que a comunicação entre as páginas e o bean será por sessão.


Pronto! Configuramos nossos apelidos e nosso bean! Falta agora configurar nosso projeto!


Somente com o que temos até agora a aplicação não irá funcionar, por que o servidor ainda não sabe que nosso projeto está utilizando o framework JSF.
 
Mas como informar para o servidor que nosso projeto é um projeto JSF? 
Atraves do arquivo web.xml!


Neste caso não existe muito o que falar, por enquanto. O arquivo web.xml é um arquivo padrão de configuração das aplicações web, tanto faz se é um projeto JSF, ou Struts, ou Raptor ou se não utiliza nenhum framework, o web.xml deve estar lá, devidamente configurado para que o servidor entenda que nosso projeto é assim ou assado.


Então abra o arquivo web.xml e insira as seguintes linhas de código:

<?xml version=”1.0″?>
<!DOCTYPE web-app PUBLIC
“-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN”
“http://java.sun.com/dtd/web-app_2_3.dtd”>
<web-app>
<context-param>
<param-name>javax.faces.STATE_SAVING_METHOD</param-name>
<param-value>server</param-value>
</context-param>
<context-param>
<param-name>javax.faces.CONFIG_FILES</param-name>
<param-value>/WEB-INF/faces-config.xml</param-value>
</context-param>
<listener>
<listener-class>com.sun.faces.config.ConfigureListener</listener-class>
</listener>
<!– Faces Servlet –>
<servlet>
<servlet-name>Faces Servlet</servlet-name>
<servlet-class>javax.faces.webapp.FacesServlet</servlet-class>
<load-on-startup> 1 </load-on-startup>
</servlet>
<!– Faces Servlet Mapping –>
<servlet-mapping>
<servlet-name>Faces Servlet</servlet-name>
<url-pattern>*.jsf</url-pattern>
</servlet-mapping>
</web-app>

Estas são tags padrões que devem ser inseridas no arquivo web.xml para que o servidor interprete corretamente nosso projeto JSF.
 
Em outro post irem mostrar algumas configurações mais avançadas deste arquivo e do faces-config.


Agora nosso projeto está concluído! Todas as páginas estão criadas e todos os arquivos devidamente configurados e se comunicando!


Vamos para a parte final deste tutorial…




PRÓXIMO PASSO (FINAL).

JSF, Inicio Rápido – Parte 4

PASSO ANTERIOR (PARTE 3).


Já estamos bem avançados em nosso projeto, já temos uma boa base, vamos agora criar as páginas necessárias para a navegação, aliás, vamos inserir códigos por que as páginas ja foram criadas no passo 2.


Puxando pela memória, na introdução foi informado que se chamarmos uma página pela extensão JSP, as tags não funcionariam, devemos invocar as páginas sempre utilizando a extensão JSF, neste post abordaremos um pouco deste assunto.
Antes de mais nada, nosso projeto precisa de uma pagina principal, então no arquivo index.jsp insira as seguintes linhas de código:

<html>
<body>
<jsp:forward page=”/pages/menu.jsf” />
</body>
</html>

Mas por que logo na página inicial estamos redirecionando para outro lugar?
Simples, se colocarmos as tags do JSF diretamente na página index.jsp elas não funcionariam, por que o servidor está invocando index.jsp e não index.jsf.

Existem outras formas até mais elegantes para contornar este problema, por exemplo configurando o web.xml para chamar index.jsf e não index.jsp, mas por enquanto este redirecionamento resolve nosso problema, e serve também como um ótimo exemplo para sempre lembrarmos que devemos invocar as páginas utilizando a extensão JSF para que elas funcionem…


Ok, ok, redirecionamos a página principal para “menu.jsf”, mas não tem nada nesta página!
Vamos inserir códigos nela então!


Abra o arquivo menu.jsp (lembre-se que JSF é uma extensão “imaginária”, as páginas reais possuem a extensão JSP), e insira as seguintes linhas de código:

<%@ taglib uri=”http://java.sun.com/jsf/html” prefix=”h” %>
<%@ taglib uri=”http://java.sun.com/jsf/core” prefix=”f” %>
<f:loadBundle basename=”br.com.projetox.view.bundle.messages” var=”msg”/>
<html>
<head></head>
<body>
<f:view>
<h1>
<h:outputText value=”#{msg.pagina_principal_label_titulo}”/>
</h1>
<h3>
<h:outputText value=”#{msg.pagina_principal_label_site}”/>
</h3>
<h:form id=”helloForm”>
<h:commandButton action=”cadastro” value=”#{msg.pagina_principal_label_link}” />
</h:form>
</f:view>
</body>
</html>

Agora vamos às explicações!


As duas primeiras linhas, taglib, informam que utilizaremos nesta página algumas tags JSTL específicas do framework JSF.

JSTL são bibliotecas, conjuntos de códigos personalizados, para serem utilizados dentro das páginas JSPs, existem várias JSTLs, e é possível até criar a sua propria linguagem, porém o assunto aqui não é este então não falaremos muito disso, mas já estou preparando um post sobre isso. Vale saber que alguns dos arquivos JAR que fizemos download na introdução são responsáveis por estas JSTLs que utilizaremos agora.

Na taglib informamos a propriedade prefix, que é um apelido para utilizarmos esta JSTL dentro da página.


A terceira linha utilizamos f:loadBundle, aqui já estamos utilizando uma JTSL! Enfim, este comando serve para carregar o arquivo messages.properties e é claro que você já está craque em properties né?

Note que informamos nesta linha o caminho inteiro (pacote) do arquivo properties, mas não é necessário informar a extensão, a propriedade var=”msg” funciona igual o prefix da taglib, é um apelido para utilizarmos na página.


Na tag h:outputText utilizamos a segunda taglib importada, esta é utilizada mais para campos de formulário e similares, como por exemplo neste caso estamos criando um outputText, que é como um “label” do VB ou de aplicações Java Desktop, simplesmente inserção de texto!

E nesta linha já invocamos uma variável do arquivo properties “msg.pagina_principal_label_site“, o msg. é apelido do properties que definimos na terceira linha, o resto é o nome da variável que está declarada no properties, fazendo isso, a página vai procurar no arquivo properties a variável pagina_principal_label_site, e vai escrever ná página o valor desta variável.


Na tag h:form, estamos criando um formulário, assim como no HTML, precisamos iniciar um formulário quando quisermos criar campos e botões válidos.


h:commandButton, aqui que está o pulo do gato! Este comando é similar ao botão SUBMIT do HTML, e funciona da mesma maneira, ele pega todos os campos do formulário e envia para algum lugar.

Vamos ver com um pouco de calma cada propriedade deste comando.
action=”cadastro”, mas o que é isso? “cadastro“, essa porcaria não é sequer uma página!
Realmente isto não é uma página, não é nada, “cadastro” não existe!

Essa string é outro apelido, que definiremos no arquivo de configuração, quando informamos para a página, “ao clicar neste botão vai para cadastro” ela procura esse tal de cadastro no arquivo faces-config.xml, e este se encarrega de informar qual página deve ser invocada.

A propriedade value é a mesma dos botões SUBMIT do HTML, aqui será inserida a informação que ficará escrita no botão, neste caso estamos procurando alguma informação no arquivo properties.


Com isso encerramos as explicações desta página!
Agora abra o arquivo inicio.jsp e insira as seguintes linhas de código:

<%@ taglib uri=”http://java.sun.com/jsf/html” prefix=”h” %>
<%@ taglib uri=”http://java.sun.com/jsf/core” prefix=”f” %>
<f:loadBundle basename=”br.com.projetox.view.bundle.messages” var=”msg”/>
<html>
<head></head>
<body>
<f:view>
<h1>
<h:outputText value=”#{msg.pagina_cadastro_label_titulo}”/>
</h1>
<h3>
<h:outputText value=”#{msg.pagina_cadastro_label_site}”/>
</h3>
<h:form id=”helloForm”>
<h:outputText value=”#{msg.pagina_cadastro_label_nome}”/>
<h:inputText value=”#{teste.nome}” />
<f:verbatim>
<br>
</f:verbatim>
<h:outputText value=”#{msg.pagina_cadastro_label_email}”/>
<h:inputText value=”#{teste.email}” />
<f:verbatim>
<br>
</f:verbatim>
<h:commandButton action=”#{teste.testar}” value=”#{msg.pagina_principal_botao_ok}” />
</h:form>
</f:view>
</body>
</html>

Nesta página, praticamente todos os comandos são similares aos da página anterior, com exeção de três que merecem uma explicação melhor:


<h:inputText value=”#{teste.nome}” />
Aqui estamos criando um inputText, que como você deve estar imaginando é uma caixa de texto, igual ao do HTML, mas o que precisa de uma explicação especial nesta tag é o value.
 
Note que estamos informando #{teste.nome}, fazendo isso estamos falando que este campo está vinculado à variável nome da classe teste. Ainda não sabemos quem é esse teste, por que não configuramos o faces-config.xml ainda, porém este é o nosso bean, a classe testeBean.java, lembra que criamos uma variável private String nome lá? Então, é aqui que ela está sendo referenciada.
 
Se a variável possuir algum valor, a página vai mostrar este valor no campo quando a página for carregada, e se o usuário digitar alguma coisa no campo, o valor do campo será copiado para a variável nome quando for clicado no botão de submit (o commandButton).
 
Então podemos imaginar, para efeito de analogia, que este campo é a própria variável da classe testeBean! Certo, certo, não são a mesma coisa, mas uma está vinculada diretamente com a outra, são irmãs gêmeas, e siamesas ainda por cima, o valor que uma possuir a outra vai copiar, tanto pra ir quando pra vir.


Um pouco mais abaixo temos a tag <f:verbatim><br></f:verbatim>, esta tag DEVE ser criada sempre que desejar inserir algum comando HTML puro na página, nunca se deve utilizar tags HTML em páginas JSF, nunca!
 
Mas, eu estou utilizando alguns comandos HTML diretamente, e ai?
 
Bem, eu posso explicar, este projeto é algo extremamente simples, apenas para exemplo, e as configurações do projeto deixam passar estas coisinhas, porém quando for fazer um projeto mais avançado onde as configurações também são mais avançadas, com certeza vai dar um erro quando sua página for chamada, o JSF não vai conseguir compilar a página por que não entenderá os comandos HTML, então já fica avisado aqui, sempre que for utilizar algum comando HTML, utilize-os dentro das tags <f:verbatim></f:verbatim>.


<h:commandButton> Novamente nos encontramos com o “SUBMIT” do JSF, porém ele está um pouco diferente agora…
 
A propriedade action não está mais chamando um apelido, e sim um método! Percorra um pouco as lembranças de sua memória ou abra o arquivo testeBean.java no seu projeto, verifique que ele tem um método testar() que retornar uma ou outra String, dependendo da situação do IF, certo? Então, para a propriedade action devemos SEMPRE informar um alias, uma String, porém não precisa ser diretamente, podemos chamar um método e este método retorna a tal String, no nosso caso estamos enviando as informações cadastradas na tela para o método testar() da classe testeBean (aqui está com o nome teste, mas teste é o apelido que daremos para a classe testeBean nos arquivos de configuração…) ao entrar no método testar(), fazemos algumas verificações e retornamos alguma string, esta string que será a página de destino de nossa aplicação!
 
Se não entendeu muito bem essa explicação, tenha calma no proximo post vamos preparar os arquivos de configuração, então você poderá entender melhor essa questão.


Agora não sobrou muito o que falar sobre as tags do JSF, então vamos inserir os códigos nos arquivos restantes!


Códigos da página sucesso.jsp

<%@ taglib uri=”http://java.sun.com/jsf/html” prefix=”h” %>
<%@ taglib uri=”http://java.sun.com/jsf/core” prefix=”f” %>
<f:loadBundle basename=”br.com.projetox.view.bundle.messages” var=”msg”/>
<html>
<head></head>
<body>
<f:view>
<h1>
<h:outputText value=”#{msg.pagina_sucesso_label_titulo}”/>
</h1>
<h3>
<h:outputText value=”#{msg.pagina_sucesso_label_site}”/>
</h3>
<h:form id=”helloForm”>
<h:outputText value=”#{msg.pagina_sucesso_label_texto}”/>
<f:verbatim>
<br>
</f:verbatim>
<h:commandButton action=”inicio” value=”#{msg.pagina_sucesso_botao_voltar}” />
</h:form>
</f:view>
</body>
</html>

Código da página falha.jsp

<%@ taglib uri=”http://java.sun.com/jsf/html” prefix=”h” %>
<%@ taglib uri=”http://java.sun.com/jsf/core” prefix=”f” %>
<f:loadBundle basename=”br.com.projetox.view.bundle.messages” var=”msg”/>
<html>
<head></head>
<body>
<f:view>
<h1>
<h:outputText value=”#{msg.pagina_falha_label_titulo}”/>
</h1>
<h3>
<h:outputText value=”#{msg.pagina_falha_label_site}”/>
</h3>
<h:form id=”helloForm”>
<h:outputText value=”#{msg.pagina_falha_label_texto}”/>
<f:verbatim>
<br>
</f:verbatim>
<h:commandButton action=”cadastro” value=”#{msg.pagina_falha_botao_voltar}” />
</h:form>
</f:view>
</body>
</html>

Pronto! Ou melhor, quase pronto!


Já inserimos os códigos de todas as páginas, do arquivo de propriedades e até do nosso bean, falta agora configurar o arquivo faces-config.xml, que é a alma de um projeto JSF!
 
Mas isso colocarei em outro post…




PRÓXIMO PASSO (PARTE 5) 

JSF, Início Rápido – Parte 3

PASSO ANTERIOR (PARTE 2).


Se você chegou até aqui acho que você já leu a introdução, e a parte 2 do tutorial de JSF.
Presumindo que estas tarefas já estejam feitas, as pastas e o bean criados, é hora de falar do arquivo messages.properties.
 
Este arquivo é utilizado abrangentemente, em vários frameworks, não somente em JSF. Mas afinal pra serve este bendito arquivo?


Este arquivo nada mais é que algum txt, que contém nomes de váriáveis e seus conteúdos, ele nem ao menos precisa ter esse nome, poderia ser sorvetechocolate.properties, também funcionaria, porém como tudo em java precisa seguir certos padrões de programação, principalmente para futuras manutenções, este nome foi adotado.
 
O arquivo funciona da seguinte maneira:

variavel_nome1.variavel_sobrenome.variavel_maisumnome = valor1
variavel_nome2.variavel_sobrenome.variavel_maisumnome = valor2
variavel_nome3.variavel_sobrenome.variavel_maisumnome = valor3

Em suas páginas, ao invés de escrever os textos diretamente no JSP você importa estas “variáveis” do messages.properties, e assim o texto é escrito na página, sem ter sido inserido diretamente entre as tags html.


Isso é útil por que?
Para manutenções, por exemplo, o telefone do PABX da empresa mudou, se você não estiver utilizando algum “messages.properties” ou similares, provavelmente você terá que abrir página por página e alterar todos os telefones, e é quase certeza que alguma página irá passar em branco, porém se você estiver utilizando o messages.properties, e mapeando a variável “telefone.pabx”, basta alterar o valor desta variável no messages.properties e pronto! Todas as páginas serão atualizadas, sem complicações.


Internacionalização, digamos que sua empresa tem um portal, todo gerenciavel, em determinado dia acionistas estrangeiros compram ações da sua empresa e querem o site em inglês. Se você não estiver utilizando algum mapeamento de textos como o messages.properties, provavelmente vai ter que abrir página por página, coletar texto por texto e traduzir cada um, compilar o site inteiro novamente, mas com o messages.properties devidamente configurado e utilizado isso não será preciso, e o tempo para traduzir o site será muito pequeno, aliás, não demandará tempo algum, basta anexar o messages.properties no e-mail e enviar para o departamento responsável e informar “Aqui estão todos os textos do site, traduz ai que eu vou pra casa descansar”.


Agora que ja sabemos o que é, como funciona e pra que serve este famoso quebra-galhos, messages.properties, podemos configurá-lo em nossa aplicação.
Na parte 2 deste tutorial criamos o arquivo messages.properties dentro do pacote br.com.projetox.view.bundle, mas não colocamos nenhum conteúdo nele.
Abra o arquivo messages.properties e insira as seguintes linhas de código:

##### Textos da Página Principal #####
pagina_principal_label_titulo=JSF Inicio Rápido
pagina_principal_label_site=http://codeerror.wordpress.com
pagina_principal_label_link=Página de Cadastro
##### Textos da página de cadastro #####
pagina_cadastro_label_titulo=JSF Inicio Rápido
pagina_cadastro_label_site=http://codeerror.wordpress.com
pagina_cadastro_label_nome=Nome
pagina_cadastro_label_email=E-mail
pagina_principal_botao_ok=Ok
#### Textos da página Sucesso ####
pagina_sucesso_label_titulo=Cadastro efetuado com sucesso!!!
pagina_sucesso_label_site=http://codeerror.wordpress.com
pagina_sucesso_label_texto=Parabéns, o projeto JSF Inicio Rápido está dando resultados!
pagina_sucesso_botao_voltar=Voltar
#### Textos da página Falha ####
pagina_falha_label_titulo=Falha ao realizar o cadastro…
pagina_falha_label_site=http://codeerror.wordpress.com
pagina_falha_label_texto=Acho que você não preencheu os campos na página anterior, por favor preencha!
pagina_falha_botao_voltar=Tentar novamente

Este arquivo está totamemte intuitivo, os nomes das variáveis foram criados com base em nome da página, tipo de texto e nome do campo.
Por exemplo a primeira linha:
pagina_principal_label_titulo= JSF Inicio Rápido
pagina_principal_label_titulo é o nome da variável, este nome que invocaremos nas páginas JSP da aplicação.
JSF Inicio Rápido é o valor da variável, este que será apresentado na tela sempre que a variável for solicitada.


Os textos precedidos por sustenido (#) são comentários, que inseri para separar mais ainda as variáveis, facilitando futuras manutenções no código.
Agora podemos criar as páginas JSP da aplicação, mas isso fica pra outro post.




PRÓXIMO PASSO (PARTE 4).

JSF, Inicio Rápido – Parte 2

Já leu a introdução?

Então vamos à parte 2 deste tutorial.
Agora vamos criar algumas páginas JSP e Java, para começar a transformar nosso projeto em um “projeto”.

Mas primeiro, deixa eu explicar a finalidade destas páginas.
Vamos desenvolver um projetinho simples de JSF, para exemplificar a comunicação e configuração das páginas e do projeto em si, para isso iremos construir uma páginazinha index com uma opção de cadastro, ao clicar no link será aberta uma página de cadastro com 3 campos: Nome, e-mail e um “botão” submit, ao enviar este formulário os beans serão populados e estas informações serão exibidas em outra página, com um botão de voltar para a página inicial.

Ficará mais ou menos assim:


Página inicial / Menu:

 
Página de cadastro:

 
Página de Falha no cadastro (Caso não tenha sido digitado nada na tela):

 
Página de cadastro (Após clicar no botão “Tentar novamente” da página de erro):

 
Página de sucesso (Ao preencher os campos de cadastro corretamente):

 
Página principal (Ao clicar no botão “Voltar” da página de Sucesso.)



Agora que já sabemos como o projeto irá ficar no final, podemos começar a construir as páginas.
Aqui vale uma explicação sobre as páginas. Em JSF nenhuma tag especial consegue ser executada se a página não for chamada “página.jsf”, se você chamar em algum link “página.jsp”, por exemplo, o console irá acusar um erro, informando que as tags da página solicitada são inválidos. Não se esqueça disso!

Crie a seguinte estrutura de arquivos (dentro das pastas indicadas nas imagens, crie as pastas que não existirem):


 
Então teremos os seguintes arquivos criados:
testeBean dentro das pastas (pacote) br.com.projetox.view.bean;
messages.properties dentro das pastas (pacote) br.com.projetox.view.bundle;
index.jsp dentro da pasta WebContent;
falha.jsp dentro da pasta WebContent/pages;
inicio.jsp dentro da pasta WebContent/pages;
menu.jsp dentro da pasta WebContent/pages;
sucesso.jsp dentro da pasta WebContent/pages;

Agora que criamos todos os arquivos, vamos preenchê-los com códigos, começando do BEAN.
Abra o arquivo testeBean.java e crie duas váriáveis String, uma nome e outra email (exatamente com estes nomes) e faça os gets e sets das variáveis. Crie também um método testar(), para executar alguma ação e retornar algum “endereço” para a aplicação.
Segue o código:

//----INICIO DO CÓDIGO DA CLASSE testeBean.java
package br.com.projetox.view.bean;
 /**
 * @author codeerror.wordpress.com
 */
 public class testeBean {
 private String nome;
 private String email;
   public String testar(){
      String retorno = "falhou";
      if(!this.nome.equals("") && !this.email.equals("")){
         retorno = "sucesso";
      }
      return retorno;
   }
   public String getNome() {
      return nome;
   }
   public void setNome(String novoNome) {
      this.nome = novoNome;
   }
   public String getEmail() {
      return email;
   }
   public void setEmail(String novoEmail) {
      this.email = novoEmail;
   }
 }
//----- FIM DO CÓDIGO DA CLASSE testeBean.java

Sim eu sei, falta JavaDoc, mas precisamos economizar linhas aqui no post…
Deixa eu explicar o que significa cada coisa.

As variáveis são private String, por que queremos variáveis do tipo String, e private por que não é pra mais ninguém (nenhuma outra classe) acessar estas variáveis diretamente, isto é um padrão de desenvolvimento.

O método testar() verifica se os campos nome e e-mail possuem algum valor, se eles possuirem algum valor o método irá retornar “sucesso” caso eles estejam em branco, o método irá retornar “falha“, irei falar o significado destes retornos mais pra frente, mas já da pra se ter uma idéia.

Depois do método testar() estão os gets e sets das variáveis. Estes métodos são necessários (e muito) para praticamente tudo em java, eles que controlam a entrada e saida das variáveis, por exemplo o método getNome() retorna o valor contido na variável nome, o método setNome(String novoNome) copia o valor da variável novoNome para a variável nome do bean.

Agora vamos falar do arquivo messages.properties, mas a explicação deste arquivo é um pouco extensa, e este post já está bem grande, então continuarei no proximo post!

PRÓXIMO PASSO (PARTE 3).