Java Erro

Acessibilidade, parte 2

2012-01-10T22:43:00.001-02:00

Continuando com a postagem anterior, a parte 1 sobre o tema "acessibilidade", e é claro que você já está por dentro do assunto após ter lido todo aquele texto, mas agora vou deixar um de lado a visualização, para falar um pouco sobre navegação, afinal, poder mexer é tão importante quanto poder ver.

Mas antes de tentar dar algumas dicas de navegação, temos que entender o que é a navegação, e qual a importância dela.

Pra começar, se você está vendo esse blog de programação, existe uma enorme possibilidade de você possuir um teclado e um mouse. O que? Está surpreso com essa frase? Estou falando sério, lembre-se de que nem todos os seus possíveis leitores/clientes possuem um teclado e um mouse! Mas voltando a você, provavelmente você está usando o mouse para navegar por esse site, mas vamos fazer um pequeno teste (primeiro leia esse parágrafo, depois faça o teste). Coloque o ponteiro do mouse sobre o relógio do sistema, feche os olhos, não vale roubar, feche os olhos totalmente e tente clicar no link “Início” que está lá em cima, no topo do meu blog, você consegue?

Acho que você não conseguiu, pois ainda está lendo essa postagem, o que podemos entender com esse exercício? O mouse foi criado para quem tem uma visão boa. Mas, vamos fazer outro teste. Fique com os olhos abertos, mas coloque os dois braços atrás da cabeça, como se estivesse sendo abordado pela polícia, agora sem usar as mãos, tente clicar no botão “Início” e depois voltar para essa postagem. Acho que dessa vez você consegue, mas vai ser muito incômodo não é mesmo? Não precisa dizer como você está controlando o mouse, isso não importa muito, apenas precisamos perceber que o mouse foi feito para quem, além de uma boa visão, possui ao menos um braço ou uma boa coordenação motora para poder controlá-lo com outra parte do corpo.

Agora vamos fazer um último teste, esconda seu mouse e tente navegar nesse site. Você consegue? Sim, claro que consegue, mas vai ser um pouco mais chato, nesse caso temos que utilizar a tecla “TAB” que é a tecla utilizada para navegar pelo site sem utilizar um mouse, essa tecla vai passando por cada elemento da página, veremos mais detalhes adiante.

Em suma, um site com uma navegação acessível, atende, diversos tipos de pessoas e equipamentos, não importa se o usuário possui deficiência visual, motora, se ele não possui um mouse ou qualquer que seja o motivo. Mas como fazer isso? Calma, agora que entendemos o problema, podemos pensar em possíveis soluções.

O primeiro passo é eliminar do seu site qualquer menu feito em flash ou similares, por que esses tipos de menus, só são acessados com o mouse, mesmo se você colocar um script para aceitar o teclado, ainda não vai funcionar por que o “componente” precisa estar ativo para que o teclado funcione. Difícil de entender essa parte? Eu explico, vá em algum site de jogos online, que geralmente são feitos em flash ou Java applet, escolha um jogo e deixe a página dele carregar mas assim que você escolher o jogo NÃO CLIQUE NO JOGO, apenas deixe a página dele carregar e tente jogar. Você não vai conseguir, é por que o applet ou flash não está “ativo”, se você pressionar as setinhas cima, baixo, esquerda e direita, você vai movimentar a página e não o personagem do jogo, se você quiser ativar o controle do jogo, vai ter que clicar no applet ou flash, para somente após isso, conseguir utilizar o teclado. Se você possui um menu feito em flash ou applet ou qualquer coisa do tipo, delete-o e crie um novo menu via HTML, pode utilizar imagens, muitas imagens, mas lembre-se do assunto anterior, não deixe seu site muito “pesado”. Além dessa dificuldade, seu leitor/cliente pode tentar acessar o site de um celular ou de um computador um pouco mais antigo que não possua suporte para a ferramenta que você está tentando disponibilizar, nesse caso também vai ficar muito difícil navegar pelo seu site.

Ainda nos menus, mas também no resto do site, se você está tratando algum tipo de evento do mouse via script, tipo “onmouseover”, “onclick”, “onmouseout”, esse menu ou item só vai funcionar se seu leitor/cliente possuir e conseguir utilizar um mouse, mas se for um deficiente visual, ou alguém que não possua mouse, essa pessoa não conseguirá navegar pela página.

Duas alternativas plausíveis, a primeira é remover esses eventos e menus que capturam o evento do mouse, outra solução é adicionar eventos de teclado! Se você está capturando um “onclick” capture também quando a tecla “barra de espaço” for acionada, se está capturando o “onmouseover” adicione também um evento “onfocus”, se está utilizando o evento “onmouseout”, capture também o evento “onblur”, sempre procure similares para teclado, em todos os eventos de mouse que estiver utilizando.

Outro fator importante para a navegação é a ordem dos elementos, esqueçamos mais uma vez o mouse, desconecte ele e guarde em algum lugar, navegue pela sua página utilizando a tecla “TAB”, você consegue chegar ao conteúdo rapidamente ou tem que passar por milhares de botões e propagandas antes? Se você está demorando mais do que 5 “tabs” para chegar ao conteúdo, EU acho que já é muito, alguns acham até que o primeiro “tab” já deve cair no conteúdo, mas ai você tenta fazer isso nesse blog e vê que não consegue chegar no conteúdo da postagem antes de passar por todo tipo de link, correto? Realmente, mas esse blog não é meu, é do wordpress.com, eu não edito o código fonte do site, apenas o da minha postagem, infelizmente.

Mas como criar uma navegação? Utilizando um comando html simples, o “tabindex”.
Tabindex é um atributo que existe na maioria das tags html, e com ele é possível estabelecer uma ordem de navegação para os objetos, definindo com valores numéricos, de preferência positivos, alguns navegadores aceitam valores negativos, mas não são todos.

Exemplos:

<a href=”x.com.br” tabindex=”1”>aaa</a>
<a href=”x.com.br” tabindex=”2”>bbb</a>
<input type=”submit” value=”ccc” tabindex=”3”/>

No exemplo acima, o primeiro tab vai deixar o link “aaa” selecionado (não vai acionar o link, vai apenas dar o foco para ele), o segundo tab vai marcar o link “bbb”, o terceiro tab vai marcar o botão “ccc”.

Você pode deixar lacunas entre os tabindex, por exemplo, 1-2-3-6-7-9-15-29-30-100, neste caso os tabs vão acessar os objetos na ordem que for definida, se um número não for encontrado, então o próximo é procurado, e assim vai até encontrar um número.

Não é necessário inserir as tabulações na ordem que os objetos estiverem dispostos no código fonte, você pode colocar um tabindex=”1” para um objeto que está no final da página e um tabindex=”2” para um objeto que está no começo, isso não importa, se fizer isso o primeiro tab vai acessar o objeto que está com a tabulação “1” e o segundo tab vai acessar o objeto “2”.

Resumindo o capítulo, quando estiver criando ou editando o código fonte de uma página, invista alguns minutos tentando navegar pelo site sem o mouse e veja se é possível, se não conseguir então será necessário efetuar alguns ajustes.

Assim encerro esta postagem, e para a próxima prepararei uma matéria sobre leitores de tela e a utilidade (ou falta de utilidade) de tabelas em sites acessíveis.

Enjoy!

Performance em aplicações Java. O problema é você!

2011-11-20T11:59:00.001-02:00

O título dessa postagem já é um “spoiler”, mas o que eu quero dizer realmente com “O problema é você”?

Antes de sair apontando o dedo para o pessoal de rede dizendo que o servidor não presta ou o cabeamento está cheio de baratas (provavelmente o servidor é ultrapassado e o cabeamento está cheio de baratas), mas antes de culpar o servidor, aponte o dedo para o espelho, e melhore esse código feio que está fazendo!
Pense que em uma aplicação, não é apenas o “front-end” que precisa ser bonito, a área por traz das cortinas tem que ser mais bonita ainda. Você gosta quando precisa arrumar um programa que o código foi feito por um estagiário do período cenozoico? Pois bem, provavelmente o próximo programador que olhar para o seu código vai ter a mesma impressão: “P.q.p! Esse código deve ter passado pelas mãos sujas de um estagiário!”.Particularmente eu não gosto de assinar um código feio, só coloco meu nome em um código depois de arrumá-lo e deixá-lo legível.

IMPORTANTE: Código feio e gambiarra são coisas extremamente diferentes, gambiarras fazem partes da vida de qualquer programador, seja ele estagiário ou especialista, porém só porque precisamos fazer uma gambiarra não significa que devemos deixar o código em hebraico.Mas o que tem a ver código legível com deixar o programa mais rápido?

Tudo!

Uma cultura de “código limpo” e “código bonito” leva a uma outra cultura, de “programa rápido”, pois você se acostuma a fazer um código melhor, que consequentemente, funcionará de forma mais rápida. Além de um fator importante, a performance do programador que for arrumar ou melhorar o programa. Com certeza quem for mexer no código-fonte desse programa vai terminar a alteração muito mais rápido se não precisar utilizar o tradutor do google para traduzir de “hebraico para javanês”.Mas o que, especificamente, pode ser feito para deixar a aplicação mais rápida?Siga os passos abaixo, que verá a diferença.
Em alguns casos, o usuário não perceberá a diferença, mas você sim, porque o servidor vai parar de cair e você vai parar de ser acordado as três da madrugada para dar “stop/start” na aplicação.

Laços FOR
Entenda que “for” convencional é mal, “foreach” e “iterator” são bons.Em um laço for convencional, é necessário criar vários objetos para controle do loop e do próprio conteúdo da lista, e isso consome mais processamento e memória do que um foreach ou iterator, porque esses dois já trabalham de uma forma que, se bem utilizados, não há a necessidade de criar objetos de controle.Exemplo de foreach:

ArrayList<Objeto> lista = new ArrayList<Objeto>(Numeros.CEM);
for(Objeto variavel : lista) {
System.out.println(variável.getNome());
}

Exemplo de Iterator

ArrayList<String> array = new ArrayList<String>(Numeros.CEM);
Iterator<String> it = array.iterator();
while(it.hasNext()) {
System.out.println(it.toString());
}

Métodos dentro de laços
Isso não se faz, a cada iteração do loop um método de terceiros é consultado.Se o valor não muda, é melhor atribuí-lo à uma variável, diminuindo o tempo de processamento do laço.Exemplo de como não fazer:

ArrayList lista = new ArrayList();
for (int i = 0; i < lista.size(); i++) {
System.out.println(lista.get(i));
}

Nesse exemplo, de como não fazer, a chamada ao método “lista.size()” será efetuada em cada iteração do laço, que pode ser while ou do..while, e se o laço possuir dez mil iterações, serão dez mil chamadas ao método que contará sempre os dez mil registros da lista.

Exemplo de como se deve fazer, economizando processamento.

ArrayList<String> array = new ArrayList<String>(Numeros.CEM);
int tamanho = array.size();
int x = Numeros.ZERO;
while(x < tamanho) {
}
for (int i = 0; i < tamanho; i++) {
}

Imports não utilizados.
Sempre que passar por uma classe, remova os imports não utilizados, pode ser manualmente ou com o atalho “CTRL+SHIFT+O” do eclipse.Apesar de não parecer, os imports inutilizados ajudam a deixar a classe mais pesada, por que quando ela é compilada (pelo javac), todas as classes importadas são compiladas juntas.
Isso também vale para imports com * no pacote, é bem difícil você utilizar todas as classes de um determinado pacote, e provavelmente você não vai querar compilar todas as classes de um pacote junto com a sua, ou quer?

Objetos e Tipos Primitivos
Sempre que possível, não utilize objetos (Integer, Double, Float) mas sim tipos primitivos (int, double, float) que são mais leves.Quando for trabalhar com faixas numéricas pequenas, utilize também um tipo pequeno, por exemplo o byte para apenas códigos 1, 2, 3, etç. Use o short para faixas de 0 a 32767 (ou negativos nessa mesma faixa).Um objeto exige muito mais espaço na memória do que um tipo primitivo, por exemplo, o int só precisa de uma faixa na memória para guardar o valor da variável, já o Integer precisa de um espaço bem maior, para guardar a classe Integer, que possui além do valor, várias outras variáveis e métodos internos.Quando houver a necessidade de trabalhar com um int que nunca pode ser nulo, impeça o usuário de acionar algum método sem preencher o campo da tela.

Listas sem objeto ou tamanho.
Sempre que utilizar uma lista, indique de que tipo é essa lista, dessa forma economizamos memória e processamento, não sendo necessário criar objetos e fazer o cast em cada item dessa lista.
Sempre defina um tamanho inicial para a lista. Quando não informamos um tamanho para a lista, o compilador entende que seu tamanho inicial será 10. Quando essa lista ultrapassa os 10 itens, o compilador cria uma nova lista com mais 10 itens, ou seja, 20 itens, e copia a primeira lista para a segunda lista, se ela ultrapassar os 20 itens, o compilador cria uma nova lista com mais 10 itens, ou seja, 30 itens, e copia todos os objetos da segunda lista para a terceira lista. Se você não definir um tamanho e sua lista possuir mil objetos, esse processo irá se repetir 100 vezes, consumindo memória e processamento.Para contornar esse problema, sempre defina um tamanho inicial para suas listas, e esse número deve se aproximar do tamanho que a lista terá.
Por exemplo, se eu estiver criando uma lista departamentos de uma empresa, vou criar uma lista com tamanho inicial igual a 100, por que não existem milhares de departamentos em uma empresa.Se eu estiver criando uma lista de funcionários de uma empresa multi-nacional, vou definir um tamanho inicial de 1000 para a minha lista, fazendo isso, mesmo que a lista possua dez mil objetos, eu já diminui o processamento em cem vezes, por que ela não vai precisar ser copiada de 10 em 10, mas sim de 1000 em 1000.

Exemplo de como não fazer:

ArrayList lista = new ArrayList();

Exemplo de como se deve fazer:

ArrayList<Objeto> lista = new ArrayList<Objeto>(Numeros.CEM);

Pesquisas e ordenações em Listas
“Não tente reinventar a roda”, não há a necessidade de criar um algoritmo com laços e variáveis para fazer uma pesquisa ou ordenar uma lista, a Sun já criou formas mais fáceis e leves para isso.Algoritmos como quicksort, bubblesort, binariesort, só são utilizados para aprender lógica de programação e em linguagens estruturadas, em orientação a objetos só se deve recorrer a este tipo de algoritmo em casos “extremamente extremos”, onde não existe nenhuma outra possibilidade de se resolver o problema utilizando a própria linguagem ou o framework.
Para fazer pesquisas, use o MAP (ou similares), que já foi criado para esse tipo de funcionalidade.
Para ordenar uma lista, implemente o Comparator.

Exemplo de MAP.
No próprio for, onde você recupera ou cria os dados, você pode criar um MAP no lugar do List ou ArrayList que já está utilizando. O MAP funciona no esquema “chave / valor”. Na chave você define o termo que será pesquisado, e no valor você insere o objeto inteiro.

Criação de um MAP:

Map<Integer, String> mapa = new HashMap<Integer, String>();
for (Objeto obj : minhaLista) {
mapa.put(obj.getCpf(), obj);
}

Lembre-se de utilizar para “chave” alguma coisa que não se repita, como CPF, por exemplo.Também é possível utilizar algum controle próprio, como números, ou qualquer outra coisa.
Para pesquisar alguma coisa nesse mapa, deve-se verificar se existe algum objeto com a chave informada (containsKey), e se existir, pega esse objeto, simples assim. Nem precisa de loop.

  if(mapa.containsKey(111222333)) {
Objeto = mapa.get(111222333);
}

Para ordenar uma lista, de forma simples e “direta”.

ArrayList<Objeto> lista = new ArrayList<Objeto>(Numeros.CEM);
  Collections.sort(lista, new Comparator<Objeto>() {
      public int compare(Objeto r1, Objeto r2) {
          if (r1.getIdade() < r2.getIdade()) {
              return Numeros.MENOS_UM;
          } else if (r1.getIdade() > r2.getIdade()) {
              return Numeros.UM;
          } else {
              return Numeros.ZERO;
          }
      }
  });

Explicando, eu tenho uma lista qualquer e quero ordená-la, então eu utilizo o método sort da classe Collections, esse método precisa da lista que será ordenada e de um “Comparator” dessa lista, você pode criar uma classe ou método que retorne esse comparator ou pode cria-lo na hora, como fiz no exemplo acima.
O comparator precisa ter um método compare que recebe dois objetos, do mesmo tipo de objeto da lista, esse método compare deve retornar -1 se o primeiro objeto for menor, ou deve retornar 1 se o primeiro objeto for maior, ou deve retornar zero se os dois forem iguais. Você que define o que vai decidir se um objeto é maior ou menor, você pode comparar o que quiser, qualquer uma das variáveis do objeto, o que o sort precisa é dos retornos -1, 1 e 0.

Strings e Constantes.
Utilizar strings diretamente nos métodos é mau.Utilizar constantes em uma classe própria para constantes é bom.
Exemplo de como não fazer:
String texto = “alguma coisa”;
int retorno = 0;

Exemplo de como fazer:
Classe de constantes (ViewConstants, Números, etç.) String texto = ViewConstants.TEXTO;
onde TEXTO está marcado como “public static final String” na classe de constantesInt retorno = Numeros.ZERO; onde ZERO está marcado como “public static final int” na classe de constantes numéricasSe você tem uma classe muito popular, que é acessada muitas vezes, e dentro dessa classe tem varias variáveis e objetos, sempre que a classe for acessada novos objetos e variáveis são criados, ocupando mais e mais memória do servidor. Para evitar isso, crie uma classe para armazenar todas as strings e constantes de sua aplicação, mas lembre-se de sempre marcar suas constantes com “static final”, dessa forma as variáveis serão criadas apenas uma vez, e utilizadas por todas as classes da aplicação, sem que mais memória seja utilizada.

Concatenação de Strings
Sempre que é utilizada a concatenação de Strings, novos endereços da memória são separados para essa tarefa, e esses endereços só são liberados quando o método ou a classe morre, se o garbage collector fizer seu trabalho assim que o método ou classe morrer, dessa forma, para evitar o uso excessivo de memória, aconselha-se utilizar o StringBuffer para esse trabalho.

Exemplo de como não fazer:
String texto = “texto1”;
texto += “ ”;
texto += “texto2”;

Exemplo de como se deve fazer, economizando memória.
StringBuffer texto = new StringBuffer();
texto.append(“texto1”);
texto.append(“ ”);
texto.append(“texto2”);

No “exemplo de como não fazer”, se você concatenar a string “A” com a string “B”, e depois com a string “C”, e com a string “D” e assim por diante, você estará ocupando um largo espaço na memória, pois a cada concatenação, uma nova String é criada, para armazenar o resultado da sua soma. O processo é similar ao da copia da lista, explicado anteriormente.
Utilizando o StringBuffer, você gasta apenas o endereço que o StringBuffer já está utilizando, não sendo necessário criar várias outras variáveis de apoio.

Comentários Javadoc e in-line
Essa prática não desempenha nenhum papel fundamental na performance do sistema, mas garante uma boa performance dos programadores que estiverem mexendo no código, conforme mencionado nas primeiras linhas desse post, pois um método complicado que estiver bem comentado sempre será mais fácil de entender, não precisando perder tempo para descobrir o que um IF, um for, uma variável ou o próprio método está representando.
Os comentários, podem ser colocados na assinatura do método, em forma de javadoc e também antes de cada código, utilizando comentários de linha.
Saiba mais sobre javadoc aqui.Exemplo:/**
*
* Nome: Fazer alguma coisa
* Propósito: Esse método recebe um “Objeto” devidamente preenchido e verifica se
* deve ser gravado completo ou se deve ser feita uma gravação individual no banco de dados.
* @param Objeto, esse objeto precisa que a variável idade de cada indivíduo esteja preenchida,
* recomenda-se utilizar a validação na tela, não deixando chegar nenhum nulo no java
*
*/
public void doSomethig(Objeto param) {
//Verifica se é para gravar todos ou um de cada vez
if(param.getIdade() > ClasseSistema.getXpto()) {
ServiceImplQualquer.gravarInformacoes(param);
} else {
//Grava os objetos um a um, mas precisa que a idade de cada objeto
  //esteja preenchida, utilizando a validação da tela
for (ObjetoX objetoX : param.getLista()) {
ServiceImplQualquer.gravarUmDeCada(objetoX);
}
}
}

Sem medo do JavaDoc

2011-11-20T11:50:00.001-02:00

O “JavaDoc” falando em termos gerais, é um gerador de documentação que a sun criou para ser utilizado por programadores, para documentar todo o código fonte visível de uma aplicação.Fazer o javadoc da aplicação que você está fazendo é muito importante, tanto para você quanto para outros programadores que utilizarão o seu programa, por exemplo, se você estiver fazendo uma biblioteca (jar), se não tiver javadoc quem for utilizar o seu jar estará perdido, e até você mesmo poderá se perder quando estiver melhorando ou fazendo algum ajuste no código, eu mesmo esqueço qualquer lógica que eu tenha criado a mais de algumas horas, por isso todo código que eu faço é muito bem comentado e documentado, isso não me toma muito tempo e é bom fazer isso enquanto o método está sendo criado, por que a regra de negócio dos métodos e das classes ainda estão na memória (na sua memória).Vamos para um exemplo prático!
Para poder comprovar o efeito do javadoc, você vai precisar de uma ide.Se você já manipulou arquivos em java, precisou em algum momento definir delimitadores de diretórios “/” para unix e “\” para windows. Mas você não precisa fazer um código pra descobrir o sistema operacional do usuário do seu programa, o java já te informa tudo o que você precisa do sistema operacional utilizado pelo usuário, com o código System.getProperty(), esse método recebe uma String, que indica qual propriedade do sistema operacional você quer, mas eu não sei o que eu tenho que informar, eu sei apenas que eu quero um “separador de diretórios”, então o que fazer?Escreva na sua IDE, dentro de algum método java.lang.System.getProperty(“”), esse método não vai nos servir pra nada, por que não informamos qual a propriedade do sistema que queremos, mas não se desespere, a sun faz JavaDoc. Selecione o método getProperty e aperte a tecla F2 (eclipse) ou apenas coloque o mouse sobre o método até aparecer uma janelinha conforme abaixo.Está ai, tudo o que o método faz, explicado em cada detalhe, da até pra navegar.
Se descer mais um pouco a barra de rolagem vai ver alguns links na seção “See Also“, clique no link “getProperties()“, um outro javadoc vai aparecer, mas agora o javadoc do método getProperties, contendo todas as possíveis variáveis que devem ser informada no método getProperty, no nosso caso seria a “file.separator”, mas olha como tem várias variáveis que podemos utilizar, legal né?Essa não é a unica forma de ver um javadoc, da também para ver de uma forma geral em um navegador. Quando você termina o seu projeto, se ele estiver com todos os javadocs criados, você pode “exportar” essa documentação para o formato html e ele fica exatamente dessa forma: http://download.oracle.com/javase/6/docs/api/ Esse é o javadoc da JRE/JDK, a documentação, da linguagem java. Seu programa pode ter uma documentação exatamente igual a essa, se você documentar os métodos corretamente.Percebeu a importância do javadoc?Apenas os javadocs de objetos “public” são exportados ou ficam visíveis, mas sempre documente todos os seus métodos mesmo private, afinal nunca se sabe quando você vai precisar dessa documentação, e existe a opção de exportar a documentação de objetos private e protected também, mas vamos ver isso mais adiante.Um javadoc não difere em nada de um comentário de bloco /* comentário de bloco */ a diferença é que ele começa com dois asteriscos /** javadoc */, até a cor muda, se você não alterou as cores da sua ide, um comentário normal, começando com um asterisco, tem a cor diferente de um comentário javadoc, que começa com dois asteriscos.Um javadoc aceita tags HTML, e eu aconselho escrever o javadoc como se estivesse fazendo uma página web mesmo, mas não precisa de comandos complexos, ficar alinhando criando div, nada disso, vamos ser simplistas, limite-se a usar negrito <b></b>, itálico <i></i>, sublinhado <u></u>, tabelas se necessário <table><tr><td></td></tr></table>, parágrafos <p></p> e quebras de linha <br>, mais que isso já é desnecessário. Os links são criados automaticamente com tags próprias.O javadoc tem alguns comandos próprios para definirmos coisas como versão, autor, descrever os parametros e o retorno, explicar as exceções que são lançadas, entre outros. Todos os comandos javadoc começam com @.Exemplo prático

/**
* Método principal
* <p>Esse método executa alguma ação</p>
* @param args, um vetor de argumentos que podem ser informados
* @author coreerror
* @exception Vai ser lançada uma NullPointerException
* @version 1.0.1
* @return Vai ser retornada uma lista de String
*/
public static void main(String[] args) {
java.lang.System.getProperty(“file.separator”);
}

Esse comentário azul antes do método é o javadoc, nele eu coloquei o nome do método, coloquei também em um parágrafo informando o que o método faz, expliquei os parâmetros com a tag @param, falei que fez esse método com a tag @autor, expliquei as exceções com a tag @exception, indiquei a versão do método com @version e disse também o que o método irá retornar com @return. Não repare que o javadoc não tem nada a ver com o método, isso ai é só pra exemplificar, eu sei que o método não retorna nada e não lança nenhuma exception.Se você colocar o mouse sobre a palavra main (o nome do método), vai ver esse comentário sendo exibido como um javadoc:

Existe também a tag @see, essa tag deve ser utilizada quando você quer que o javadoc de outro método ou classe seja visto, e um link vai ser criado automaticamente para o método ou classe que você indicou, lembra que no javadoc do System.getProperty você clicou no link getProperties? É exatamente isso, sempre coloque @see para as dependencias do seu método, para as classes que devem ser informadas por parâmetro para seu método, se ele receber objetos, ou em caso de classes, coloque @see para os construtores e para oturas classes que trabalham em conjunto com ela, etç. Quando você quer referenciar um método de alguma classe no javadoc você não deve utilizar o ponto @see System.getProperty, mas sim um “sustenido“, também conhecido como “jogo da velha” @see System#getProperty, isso também vale para referenciar métodos ou variáveis que estiverem na mesma classe @see #outroMetodo() @see #algumaVariavel

/**
* @see System
* @see System#getProperty(String)
* @see #getClass()
*/
public static void main(String[] args) {
java.lang.System.getProperty(“file.separator”);
}

Se você quer criar um link em algum lugar que não seja a seção “See Also” você também pode, por exemplo, se na parte que você está explicando o que o método faz e como ele funciona você já quiser ir linkando as classes e métodos envolvidos, basta utilizar o comando {@link Classe}, com chaves e tudo, no lugar da palavra “Classe” você coloca o nome da classe ou da Classe#Método.

/**
* Método principal
* <p>Esse é um método da classe {@link MainClass} e
* acessa a classe {@link System}</p>
*/
public static void main(String[] args) {
java.lang.System.getProperty(“file.separator”);
}

Para exportar o javadoc e criar um site igual ao da sun que está linkado mais acima você pode ir da forma menos chata, pela IDE, clicar com o botão direito sobre o projeto e selecionar a opção Exportar, depois escolhe Java/JavaDoc na caixa de diálogos que irá abrir, nas telas seguintes seleciona as opções da documentação, onde os arquivos serão salvos, quais classes participarão desse documento, se você quer a documentação dos componentes public, protected, private ou apenas a documentação dos pacotes, da pra selecionar os jars envolvidos na sua aplicação e várias outras opções. Mas se você é guerreiro, pode ir pelo console e utilizar o comando “javadoc”, dentro da pasta onde suas classes estão.Ex.:

javadoc -d doc c:\home\codeerror\projetoTeste\src\*.java

Todos as opções que podem ser selecionadas através da IDE também podem ser indicadas na linha de comando, são inúmeras opções, sugiro digitar no console “javadoc -help” para analisar as que você precisa.Agora que você está craque em javadoc, vai colocar em cada código que fizer, vou colocar uma pequena tabela abaixo com os comandos mais relevantes e pra que eles servem.

@author	Nome de quem fez o código
@category	Você pode criar categorias para seus códigos, como “utilidades” ou “maipulação” ou “services”, etç,
@deprecated	Informa se esse método está depreciado, ou seja, irá deixar de existir na próxima versão do programa
@exception	Indica as exceções que podem ser lançadas pelo método/Classe
@param	Explica o parâmetro, deve ser criado um @param para cada parametro recebido pelo método. Tente explicar detalhadamente, como por exemplo “Informar o objeto X com todas as variáveis preenchidas” ou “informar um numero de 0 a 10?
@return	Explica o que será retornado pelo método, indique também as possíveis variações de retorno, como “pode retornar verdadeiro se 1 for menor que 2 ou falso se 2 for maior que 1?.
@see	Cria um link de referência para outra classe ou método
@since	Esse é para controle de versão, aqui você informa quando o método foi adicionado na classe, ou quando a classe foi adicionada ao pacote
@throws	Similar a @exception
@version	Aqui você pode indicar a versão da classe ou do método
{@link XX}	Cria um link para uma classe ou método, o nome da classe ou método deve ser colocado no lugar das letras “XX”

Enjoy!

JavaScript + JSF, será que dá certo? (parte 2)

2011-11-20T11:07:00.001-02:00

Em um outro post sobre JSF + Javascript comentei como manipular os objetos no jsp via javascript, agora vou postar algo ainda mais útil que isso, ainda no quesito gambiarra necessária.
Imagine que você tem algumas variáveis de controle em seu código Java, mas precisa que essas variáveis sejam enviadas de alguma forma para o jsp para que você faça alguma ação via javascript, como por exemplo, efetuar uma validação no código Java e se tudo estiver certo continuar a execução, mas se algo estiver errado volta para a tela, exibe uma mensagem e pinta os campos de alguma cor destacando o que está errado. Nesse caso a ação de pintar os campos e até mesmo a mensagem, dependendo da sua aplicação, é uma ação delegada ao javascript.
Mas como fazer para que a minha variável de controle no Java seja enxergada no javascript?
Na minha época de estagiário, eu certamente faria algo do tipo:
Deixa a variável de controle no Bean, adiciona um campo “inputtext” oculto no jsp e faz esse campo receber o valor da variável de controle, via javascript eu mando um getElementById pegar o valor desse campo e começo a utilizar.
Maravilha, gambiarra melhor que essa fica difícil de fazer, nem da vontade de mexer mais no código depois disso, deixa lá para as gerações futuras saberem quem fez essa maravilha de código.
Uma coisa que eu costumo dizer é: Para que ter o trabalho de fazer algo que já fizeram, e provavelmente melhor do que você?
O Tomahalk já faz algo do tipo sem precisar ficar colocando campo oculto na tela, não precisa se preocupar mais com essa gambiarra, se preocupe com as outras.
O que iremos fazer é utilizar um comando do tomahalk que pega uma variável qualquer do seu bean e passa o seu valor para uma variável global em javascript (a variável é global mas funciona apenas no jsp em que ela foi declarada). Para utilizar essa “poderosíssima” ferramenta, precisaremos primeiro importar a taglib necessária no jsp, mas não se desespere, se você está utilizando JSF é bem provável que possua esse jar no meio de sua pasta lib.
Importe a seguinte taglib (eu estou chamando apenas de “T” para economizar as teclas digitadas):

<%@ taglib uri="http://myfaces.apache.org/tomahawk" prefix="t"%>

Agora, em qualquer lugar de seu jsp, mas para ficar menos feio, próximo ao seu javascript, importe a variável que precisa utilizando o comando t:jsValueSet

<t:jsValueSet name="" value=""/>

Em NAME você precisa colocar o nome que essa variável terá no javascript, pode ser qualquer coisa, atésorveteDeChocolate, mas será muito mais agradável se colocar um nome que faça referência ao que ela representa.
Em VALUE você deve colocar a variável de seu bean.
Ex.: Digamos que eu tenha uma variável de controle em meu bean chamada controleMensagem, essa variável é booleana.
NOTA: Os nomes no Java e no javascript podem ser iguais, eu coloquei diferente para não confundir as coisas.
Feito isso, agora eu só preciso utilizar a variável no javascript:

if (exibeMensagem) {
alert("preencha direito o campo x!");
}

No exemplo acima eu estou utilizando minha variável dentro do IF, porque condiz com o exemplo que eu passei, mas você pode utilizar em qualquer outra situação dentro de qualquer javascript no jsp em que o jsValueSet foi declarado, a variável não precisa nem ser booleana, pode ser de qualquer tipo.
Espero que esse post ajude a eliminar muitas gambiarras em seu código!

JavaScript + JSF, será que dá certo?

2011-11-20T01:51:00.001-02:00

Quem é analista de sistemas ou programador com certeza já passou por isso, a aplicação está pronta, já na fase de homologação no cliente e o encerragado solta uma pérola querendo alterar a validação de alguns campos, e o melhor “PARA ONTEM!“.

Poderíamos alterar as classes de tratamento para contemplar as novas requisições, porém isso demanda um certo tempo, é custoso e algumas vezes a validação é tão simples que não compensa alterar toda a arquitetura da página para incluí-la, mas então o que fazer? Podemos apelar para o quebra-galhos web universal o JavaScript!

Mas espera um pouco, JavaScript e JSF não combinam muito… Então o que fazer?
Existem alguns “macetes“ para conseguir fazer o JavaScript se comunicar com os componentes criados pela aplicação JSF, e estes macetes você só aprende aqui!

Primeiro:

Tente sempre trabalhar com GetElement!
A estrutura padrão de Html/JavaScript diz que os componentes da página são renderizados de forma hierárquica (document.form.objeto.propriedade), para acessar o valor de um input por exemplo você deveria solicitar “document.formulario.objeto.value”, porém esta forma é um tanto quanto falha, em websites muito dinâmicos nem sempre é possível saber o caminho completo de um componente, então entra em ação o GetElement!

GetElement funcionana mais ou menos assim: Você informa algum parâmetro, e ele varre toda a tela procurando aquele parâmetro, não importa onde ele está se dentro ou fora do formulário, não importa que objeto seja!

Vamos utilizar como exemplo a busca por ID, já que todos os objetos possuem um id, mesmo que você não informe os ids dos seus objetos, eles são criados automaticamente, mas isso é uma má pratica, sempre nomeie seus objetos!

Então digamos que:
Ao clicar no “submit” queremos obter o valor de um input e se for menor que 10 devemos exibir um alerta informando o usuário, pintar o campo de amarelo e enviar o foco para ele.

Então devemos colocar na tag form a pripriedade onsubmit=”nome_ta_função()”, mas até aqui é normal.

Na função que está o “pulo do gato”:

variavel = document.getElementById(“id_do_campo”).value;
Note que não precisamos indicar o caminho inteiro do campo, apenas que ele está “neste documento“, seu ID e o que queremos dele, no caso o value.

Agora que possuímos o valor, podemos fazer a validação!

if(parseInt(variavel) < 10){

alert(“o valor do campo ” + document.getElementById(“id_do_campo”).name + ” é menor que 10 “);
//Note que aqui a frase será “O valor do campo XXX é menor que 10″

//Agora vamos pintar o fundo do campo!
document.getElementById(“id_do_campo”).style.background = “yellow”;
//Nesta linha alteramos o BackGround do campo para amarelo, através do estilo!

document.getElementById(“id_do_campo”).focus();
//Nesta linha passamos o foco para o campo.

}

Ok, ok, mas eu fiz tudo isso ai e fica dando uma mensagem de erro “Objeto nulo ou inválido….“.

Muito bem, realmente o objeto é nulo, estes comandos funcionam perfeitamente mas em HTML puro, em JSF o javascript não vai conseguir encontrar o campo pelo id normal, por que ele não existe!

O que acontece em JSF é que na renderização das páginas ele nomeia os IDs para NOME_DO_FORMULÁRIO DOIS PONTOS ID_DO_CAMPO.

Ou seja…

Se nosso campo está dentro de um formulario cujo nome é “cadastroForm” e demos o nome de “numero” para nosso input, na renderização da página o JSF vai renomerar automaticamente o id do campo paracadastroForm:numero.

Então… quando você for chamar o campo pelo getElementById, informe formulario:campo, e não somente o id do campo!

E agora funcionou?

Desta forma não é necessário encapsular JavaScript dentro do JSF, nem precisamos alterar a arquitetura inteira para criar uma simples validação, basta utilizar esta dica para desenvolver uma validação simples em JavaScript e em pouquíssimo tempo devolver para o usuário.

Gerar executáveis em java! JAR e EXE

2011-11-20T01:45:00.001-02:00

Sim, você não leu errado, é exatamente isso o que está escrito.
Mas como? Por que?? Pra que??? Você deve estar se perguntando! E eu respondo: “Simplesmente por que eu quero” ou melhor ainda “Estou acostumado com programas executáveis” (não é o meu caso), ou por qualquer que seja o motivo.

Antes de chegar ao X da questão, deixe-me falar algumas coisas e sugerir outras.

Primeiramente gostaria de comentar sobre a dificuldade que temos em apenas tocar neste assunto (gerar um executável em java) em comunidades próprias dessa linguagem, porque Java não foi criado pra este propósito, e blá-blá-blá, e o pessoal simplesmente não dá nenhuma informação, apenas vem com críticas destrutivas. Realmente, java não foi criado para este propósito, e gerando um arquivo *.EXE você perde a portabilidade e etç, mas não me importo eu quero gerar um executável!

Opções! E por que escolhê-las:

JAR
Você conhece o JAR? É um coleguinha do RAR e do ZIP.
A linguagem Java dispõe de uma opção muito interessante, largamente utilizada na distribuição de programas e bibliotecas, e consiste simplesmente em um grupo de classes compactados, da mesma forma como você compacta seus arquivos em um ZIP ou um RAR, você pode compactar suas classes em um JAR. Claro que não dá pra usar o Winzip ou o Winrar pra gerar um arquivo JAR, mas você pode utilizar esses programas ou qualquer outro do tipo paraler e descompactar o JAR.

Como fazer? Muito simples.
A primeira opção é utilizando uma IDE, como Eclipse ou NetBeans. No caso do eclipse, você clica com o botão direito em cima da pastinha raiz do seu projeto, vai até Exportar e escolhe a opção Java Arquive File (JAR), segue algumas orientações na tela como escolher onde o arquivo será salvo e o nome do arquivo, clica em um botãozinho e pronto, seu jar está criado, mas digamos que você não use uma IDE, você criou todas as suas 999 classes na mão, utilizando o notepad! Como fazer?

Se você é um guerreiro, e quer continuar lutando, pode utilizar o console para criar seu jar, mas é um pouco mais dificil que utilizando uma IDE.

Primeiro você vai precisar escolher qual é sua classe principal (Main class), não importa se seu projeto é pequeno, grande ou gigante, com certeza ele tem uma classe principal, que deve ser iniciada primeiro.
Agora que você sabe o nome da sua classe principal, abra o notepad e escreva os seguintes dizeres.

Main-Class: <sua classe>

Muito importante, aliás, extremamente importante, pule uma linha quando terminar de escrever isso ai acima, senão nada funciona. Esse arquivo será o MANIFEST, o jar utiliza isso pra saber o que fazer quando alguem o executar.

Feito isso, salve esse arquivo em qualquer lugar, eu não me importo, apenas salve com um nome facil de decorar.

Agora vá até o console e digite:

jar cmvf <<NOME-DO-JAR>>.jar <<SEU-ARQUIVO-MANIFEST>>.txt <<A PASTA DA SUA APLICAÇÃO>>

Calma, eu explico.
O que está em vermelho é um código que precisa ser digitado para criar o jar, da mesma forma como você digitaJAVAC para compilar uma classe, esses dois (jar cmvf) servem pra “compilar” um jar.
Na parte <<NOME-DO-JAR>>.jar, você deve sobstituir obviamente <<NOME-DO-JAR>> pelo nome que você quer dar ao jar quando este for compilado, por exemplo “minhaAplicacao.jar”.
Em <<SEU-ARQUIVO-MANIFEST>>.txt você vai trocar o <<SEU-ARQUIVO-MANIFEST>> pelo nome do arquivo que você criou, que contém o nome da sua classe principal (você lembra o nome do arquivo “né”?).
E por ultimo, você troca <<A PASTA DA SUA APLICAÇÃO>> pelo caminho inteiro até a pasta raiz onde seus arquivos .CLASS estão.

Pronto, você criou um jar!

Esse arquivo jar, para ser executado precisa que alguem vá até o console e digite:

java –jar programa.jar

Não dá para apenas clicar duas vezes e abrir, quer dizer, dá sim, você tem que configurar o computador da vítima, ou melhor, do usuário, para associar a extensão .jar ao arquivo java.exe ou javaw.exe, da pra fazer esquemas assim alterando chaves no registro, mas isso é outra história.

Formas de utilizar/distribuir.

Você sabe que pra executar algum programa feito em java, é preciso que o usuário tenha alguma JRE instalada no computador “né”? Se o usuário não a tiver, seu programa não vai rodar.
Se você não quiser fazer o povo baixar e instalar a jre pra utilizar seu programa, você pode embutir uma jre junto aos seus arquivos e entregar tudo pro usuário.
Ficaria mais ou menos assim, você baixa a JRE, separa as coisas inúteis que vem junto com ela (tipo exemplos, programas pra rodar applet, documentos, etç) deixa só o necessário pra tentar reduzir o tamanho final da pasta. Depois você coloca seu JAR dentro das pastas da JRE, em qualquer lugar, isso não me importa em nada, apenas escolha um lugar e joga o jar lá.
Depois você cria um arquivo BAT ou se você souber programar em C, VB, Delphi ou qualquer outra coisa, cria um arquivo que execute o comando “java –jar programa.jar”, porém com uma diferença, você não vai mandar o console executar o “JAVA” que está ou não instalado na máquina do usuário, você vai mandar o console executar o programaJAVA.EXE ou JAVAW.EXE que está dentro da pasta BIN da JRE e passar como parametro o nome do seu jar. Pronto, basta enviar a pasta inteira pro seu usuário e mandar clicar duas vezes no arquivinho BAT que você fez.

Outra dica legal é alterar o nome do programa JAVA.EXE para qualquer coisa parecida com o nome do seu programa, é claro que se você alterar o nome de JAVA.EXE para XPTO.EXE, você tem que chamar XPTO –jar programa.jar. Se você fizer isso, no gerenciador de tarefas vai aparecer o nome do seu programa e não “java.exe”.

EXE
Bem, se mesmo com as dicas acima você ainda quiser criar um arquivo EXE vou explicar aqui como faz, mas funciona basicamente da mesma forma como acima.

Existem duas formas, a primeira é você pegar um programa que Cria Instaladores, e configurar o instalador pra fazer tudo o que foi dito acima (associar arquivos jar ao programa java.exe ou javaw.exe, copiar o jar para algum lugar, colocar um atalho na area de trabalho, etç, etç, etç), ou:

A segunda forma, utilizar o programa JSmooth.

Para utilizar o JSMooth, você precisa ter um jar criado, então siga um dos passos acima primeiro, depois abra o JSmooth, fala onde está seu JAR, onde está a JRE (se quiser que a jre vá junto com o programa, se não quiser o usuário terá que ter a jre instalada), escolhe o nome e onde salvar o arquivo, clica no botãozinho mágico e “voalá” seu EXE está criado.

Não vou explicar detalhadamente como se utiliza esse programa, por que eles já fizeram um tutorial extremamente detalhado que nem da vontade de criar outro tipo de explicação, você pode acessar o tutorial do programa nesse link.

Para baixar o programinha mágico, tenta acessar esse site aqui, o site oficial do programa.
Se por qualquer motivo eles pararem de disponibilizar o programa, como aconteceu com o plugin da sysdeo, eu coloquei em um servidor próprio a ultima versão disponível até março-2011, a versão 0.9.9.7, que pode ser baixadaneste link, mas recomendo ir no site oficial para baixar o programa mais atualizado.

Boa sorte!

JSF – Inicio Rápido – Final

2011-02-19T18:57:00.000-02:00

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
Consultor Java – JavaManhttp://codeerror.wordpress.com
http://javaerro.blogspot.com

JSF, Inicio Rápido – Parte 5

2011-02-19T18:54:00.000-02:00

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

2011-02-19T18:50:00.000-02:00

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

2011-02-19T18:41:00.000-02:00

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

2011-02-19T18:35:00.000-02:00

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

JSF, Inicio Rápido – Introdução

2011-02-19T18:29:00.000-02:00

Java Server Faces, ou JSF para os mais íntimos é basicamente um framework que trabalha com modelos de interfaces gáficas sobre eventos, é um framework baseado no conceito MVC para desenvolvimento web.

MVC é o conceito Model-View-Controler, que consiste em separar seu código em camadas de visualização, controle e negócios, mas a princípio esta sigla é inútil. Mais para frente retomarei o assunto.

Em JSF todo o controle é feito por um Servlet (FacesServlet) por um conjunto de manipuladores de ações e eventos e alguns arquivos de configuração. Não vou entrar muito no detalhe de cada bit que compõe a arquitetura senão daria uma biblia.

O que importa é que JSF é um framework “simples”, fácil de configurar e utilizar, ágil e quebra muito o galho.

A principal diferença entre Struts e JSF é:
O Struts sempre chama Actions primeiro(Classes, o famoso *.do) e JSPs depois, isso é configurado no Struts-config.xml.
O JSF chama JSPs primeiro (*.JSF) e dentro destas páginas você decide o que quer fazer.
Mas o retorno configurado é basicamente o mesmo, você configura um arquivinho XML, informa um parâmetro e dentro diz uma string de retorno e seu destino, ou várias strings de retorno e vários destinos.

Fácil né?
Se você é iniciante em JSF ou em Struts não se desespere essa é só uma comparação, a parte legal vai começar em algumas linhas.

O Objetivo deste post (e dos próximos) é apresentar a quem interessar um tutorial fácil de JSF, literalmente uma “Receita de bolo”. Como não da pra explicar tudo em um único post, separei por partes e irei postando aqui todos os links. também existe no menu um link próprio para JSF contendo todas os posts da categoria.

Então vamos ao que interessa:

Parte 1.
- Pra que lado eu atiro?
Primeiro você precisa ter um ambiente configurado, se ainda não configurou o seu, clique neste link e veja como configurar, tem também este link que mostra como configurar o plugin Sysdeo do Tomcat no Eclipse.
Se você ja configurou o ambiente e já está com o Eclipse ou outra IDE preparada, podemos começar.

Vou mostrar como funciona a organização e fornecer todos os arquivos separadamente, mas irei fornecer o projeto final completo para download no final.

Crie um novo projeto com um nome qualquer e defina a seguinte estrutura de pastas:

É com esta estrutura de pastas que iremos trabalhar.

Na pasta ant armazenaremos os arquivos de build.
Na pasta JavaSource armazenaremos todos os pacotes e classes.
Na pasta WebContent colocaremos todos os JSPs.
A pasta WEB-INF deve obrigatóriamente estar dentro da pasta WebContents, é nela que colocaremos os arquivos de configuração do JSF. Crie também dentro da pasta WEB-INF mais duas pastas, uma com o nome classes e outra com o nome lib.
A pasta works não serve para nada, ao menos para nós, ela será usada pelo servidor, para ir guardando os arquivos “temporários”, compilando as classes, etç, etç.

Agora que criamos a estrutura de classes, vamos criar os arquivos.
Dentro da pasta WEB-INF, crie um arquivo chamado faces-config.xml.
Ainda na pasta WEB-INF, crie outro arquivo chamado web.xml.

No arquivo faces-config.xml escreveremos todas as configurações do JSF, como managed-beans e regras de navegação.
No arquivo web.xml, escreveremos as configurações do projeto, como por exemplo: “Ô Tomcat, esse troço aqui é JSF!” ou “Tomcat, quando eu escrever algumacoisa.JSF, faz o favor de entender!”, entre outros.

Agora é necessário baixar as bibliotecas JSF, afinal é um framework.
Clique aqui para baixar as bibliotecas, descompacte o conteúdo deste arquivo em qualquer lugar e copie tudo que for JAR para a pasta lib.

Então até agora já criamos a estrutura de pastas, criamos os arquivos de configuração e baixamos as bibliotecas, então o projeto deve estar como a figura abaixo:

Esse é o fim de primeira parte, o proximo passo será a criação dos JSPs e Java necessários para nossa aplicação.

PRÓXIMO PASSO (PARTE 2).

Swing: JFrame e Imagem

2011-02-16T21:09:00.000-02:00

Se você está querendo criar um “programinha” ou um “programão” em java, certamente vai querer colocar uma ou algumas imagens nas janelas que criar, porém ao procurar algum código swing ou, se estiver utilizando o netbeans ou algum outro editor visual (arrastar e soltar), repara que não existe uma opção para inserir imagens no jFrame.

Mas como fica o programa nesse caso? Não existe forma de colocar uma imagem na janela?
Claro que tem, existem diversas formas de se fazer isso, mas vou falar de uma forma em específico, a forma mais simples.

Veja, no exemplo abaixo, uma imagem inserida dentro de um JFrame.

Para colocar essa imagem no JFrame eu não coloquei a imagem no JFrame.
Confuso? Eu explico.

Realmente não dá, ou não é tão “acessível” com os códigos convencionais do swing, colocar uma imagem diretamente na janela, como se coloca qualquer componente como labels, botões, etç. Mas é extremamente simples colocar uma imagem em um componente como um label ou botão.

O mais indicado para esse caso é o JLabel, ficando basicamente assim, você tem seu JFrame e insere nele um JLabel, esse label no lugar de exibir um texto vai exibir uma imagem!

Simples né?
Vamos ver se o código também fica simples:

{
labelImagemFundo = new JLabel();
getContentPane().add(labelImagemFundo);
labelImagemFundo.setIcon(new ImageIcon(getClass().getClassLoader().getResource(“java_job.gif”)));
}

Enjoy!

Swing – WindowListener

2011-02-16T20:58:00.000-02:00

Iniciando a seção Swing (não pense em outra coisa, esse blog é de Java!!), vou postar um código-exemplo de WindowListener, mais precisamente o evento “Fechando a janela”, com esse exemplo é possível escolher qualquer comportamento ao fechar a jenela, só vai depender da sua criatividade:
Quer impossibilitar o fechamento? A vontade!
Quer enviar a janela para a bandeja do sistema? Você pode! (este exemplo não ensina a fazer isso, mas darei algumas dicas desta “POG” no final).

Enfim, vamos ao que interessa, capturar o evento windowClosing, ou fechando a janela para os mais íntimos.

//Importação das bibliotecas que iremos precisar
import java.awt.event.WindowAdapter;
import java.awt.event.WindowEvent;
import javax.swing.JFrame;
import javax.swing.JOptionPane;
import java.awt.*;
import javax.swing.*;
public class JanelaTeste extends JFrame{
private static void criaJanelaExemploGUI() {
   //Cria uma nova janela, instanciando um JFrame, afinal para fechar
   //uma janela, primeiro precisamos da janela!  JFrame frame = new JFrame(“Janela Teste – Brincando com o botão Fechar”);

  //Seta o comportamento padrão para a ação “Fechar” da janela.
  //Neste caso, estamos informando “Não faça nada ao fechar”   frame.setDefaultCloseOperation(JFrame.DO_NOTHING_ON_CLOSE);

//Esse bloco não tem a menor necessidade, coloquei apenas para ter algo
//adicional no código, neste caso a primeira linha dentro do TRY recolhe
//todos os looks instalados na máquina, depois eu seleciona o terceira da lista.
//lembrando que o array começa em zero, então 0, 1, 2…
  try {
      UIManager.LookAndFeelInfo[] instalados = UIManager.getInstalledLookAndFeels();
      UIManager.setLookAndFeel(instalados[2].getClassName());
  }catch(Exception e) {
      e.printStackTrace();
  }

//Seta uma dimensão para a janela, que será assumida na inicialização;
//porporção larguxa x altura
  frame.setSize(400,100);

  //Adiciona o WindowListener ao frame, este listener possibilita capturar todos os eventos
  //da janela, ex.: Fechando, Minimizando, Restaurando, Recebendo Foco, Perdendo Foco, etç.
  frame.addWindowListener(new WindowAdapter() {
    //aqui estou informando que quero o evento fechando a janela    public void windowClosing (WindowEvent e) {
       //Nesta parte devemos colocar todo o que queremos que aconteça quando o botão
       //fechar for pressionado, neste caso apenas é exibida uma mensagem simples
       //e depois a aplicação é encerrada.      JOptionPane.showMessageDialog(null,“A janela será fechada.”,
       “Você clicou em fechar.”,JOptionPane.PLAIN_MESSAGE);

      System.exit(0);
    }
  });

  //Deixa o frame visivel aos olhos dos mortais.  frame.setVisible(true);
}

public static void main(String[] args){
  criaJanelaExemploGUI();
}
}

Alguns comentários adicionais…

No comando “frame.setDefaultCloseOperation(JFrame.DO_NOTHING_ON_CLOSE);“, estou setando a operação padrão de fechamento do frame, neste caso a opção desejada foi uma constante da classe JFrame, a constante DO_NOTHING_ON_CLOSE, não faça nada ao fechar, porém não existe somente esta, outras constantes podem ser passadas como parâmetros:
DISPOSE_ON_CLOSE: Induzir ao Fechar, fecha a janela.
HIDE_ON_CLOSE: Esconder ao Fechar, se quiser ver a jenela novamente basta aplicar um “setVisible(true)”.
EXIT_ON_CLOSE: Sai ao fechar, sai do sistema.

Dentro do listener (windowListener), estamos invocando o evento windowClosing, para fiscalizar quando a janela é fechada, existem vários outros eventos úteis que podem ser utilizados, como por exemplo:
windowClosed: Invocado quando a janela é fechada
windowLostFocus: Invocado quando a janela perde o foco.
windowIconified: Invocado quando a janela é minimizada.
windowOpened: Invocado quando a janela é aberta.
E outros mais, que podem ser consultados na API da classe WindowAdapter.

Agora sobre enviar a janela para a bandeja do sistema (ao lado do reógio), que comentei no inicio do tópico, bem isso não existe nenhum programa (ao menos em java) faz isso, o que acontece é o seguinte: Em determinado momento, quando é decidido que o programa tem que ir para a bandeja do sistema, deve-se esconder a janela, isso mesmo “setVisible(false)”, desta forma a janela some da visão do usuário, porém continua ativa.
Mas como fazer aquele icone com um menu bonitinho do lado do relógio? Para isso é preciso utilizar algumas artimanhas da classe TrayIcon para colocar um icone na bandeja, mas o icone por si só não faz nada! É preciso também criar um MouseAdapter (mouseClicked, mousePressed, etç, basta seguir o mesmo exemplo do WindowAdapter acima), para capturar o evento do mouse clicando neste icone e quando isso for feito devemos abrir um JPopupMenu, para abrir um menuzinho com as opções “Mostrar Janela”, “Sair”, “Etç, etç, etç”.
Dependendo da sua criatividade e boa vontade, da até pra fazer um efeitozinho da janela sendo “enviada” para a bandeja, exemplo: Um loop que vai alterando o tamanho e a posição da janela fazendo-a ficar menor e mais próxima do relógio antes de a escondermos.

Fazer um exemplo/modelo de uma janela sendo enviada para a bandeja do sistema está na minha lista de tarefas, em breve postarei aqui!

JSF – actionListener, outra possibilidade…

2011-02-16T20:55:00.000-02:00

ActionListener é uma outra funcionalidade (propriedade) da taglib commandButton, utilizado nas páginas JSPs.
Apenas para recapitular, um commandButon (taglig do JSF) simula um botão Submit do HTML, porém com inúmeras possibilidades, como por exemplo o action.
Existe também uma outra propriedade, que serve basicamente para chamar métodos, ela se chama ActionListener, e é invocada sempre antes da propriedade Action.

Mas qual a utilidade dela se já podemos utilizar o action?
Inúmeras são as possibilidades para o uso das duas propriedades em conjunto, action e actionListener, por exemplo, podemos definir um padrão para nosso projeto onde em todas as propriedades action só informamos as strings de navegação, e as chamadas de métodos devem ser feitas unicamente pelo actionListener, tudo é válido quando não queremos ter trabalho em futuras manutenções. Outro uso para estas tags em conjunto seria chamadas diferentes para camadas diferentes (MVC), a propriedade actionListener se encarrega de chamar os métodos responsáveis pelo controle de negócios, e a propriedade action se encarrega da camada de visualização, enfim, é útilsó depende do projeto.

Como utilizar?

Existem três passos básicos, e tudo começa no JSP, com a propriedade do commandButton.
Primeiro:

<h:commandButton
action=”string_mapeada_no_faces_config_xml”
actionListener=”#{meuBean.metodoActionListener}”
value=”Texto_do_botao” />

Na tag commandButton estamos informando que a ação (action) será uma string que foi mapeada no faces-config.xml(a página jsp que será exibida quando este botão for acionado), também pode-se chamar um método cujo retorno seja alguma string mapeada no faces-config.
Na tag actionListener estamos invocando o metodo metodoActionListener do nosso bean.

É importante informar (novamente) que a propriedade actionListener é executada antes da propriedade action, ou seja, primeiro o servidor irá executar o método que está definido na propriedade actionListener, depois que este método acabar o servidor vai prosseguir para a página ou método informado na propriedade action.

Segundo:
O método tem que ser void!
Bem, não precisa ser exatamente void, se você fizer este método com algum retorno não vai dar erro, porém o retorno não vai ser utilizado pra nada, então vamos evitar código e processamento desnecessário.

Terceiro:
O método DEVE receber como parâmetro um ActionEvent, do pacote javax.faces.event.
Este parâmetro é passado automaticamente pelo servlet durante a execução, e deve ser informado para que a comunicação entre a página e o bean ocorra através do actionListener.
Então nosso método ficaria assim:

import import javax.faces.event.ActionEvent;
public void metodoActionListener(ActionEvent e){
//alguma coisa é feita aqui.
}

Agora divirta-se!

web.xml – Alguns conceitos e exemplos…

2011-02-16T20:53:00.000-02:00

Em várias postagens deste blog este arquivo foi mencionado, bem como algumas configurações, mas o que é este arquivo? Pra que serve?

O arquivo web.xml está presente praticamente em todas as aplicações web – Java, não importa se você utiliza o framework A, B ou C, sempre terá um arquivo chamado web.xml dentro da pasta WEB-INF, isso por que este arquivo contém todas as informações do seu projeto. Este arquivo é lido diretamente pelo seu servidor, e é através dele que o servidor fica sabendo qual framework você está utilizando, quais os níveis de segurança que ele deve utilizar, qual o tempo de vida de seus servlets, até mesmo qual será sua página inicial.

Nota: O arquivo web.xml é case-sensitive, ou seja AAA é diferente de aaa, então cuidado ao escrever. Por padrão, todas as tags são escrita com letras minúsculas, e hífens (-) são utilizados para separar palavras (Exemplos: error-code,web-app, param-name, etç.)

O arquivo web.xml precisa de uma inicialização, um cabeçalho padrão que define como o servidor fará a leitura do arquivo.

<?xml version=”1.0″ encoding=”ISO-8859-1″?>
<!DOCTYPE web-app PUBLIC “-/Sun Microsystems, Inc.//DTD Web Application 2.3//EN” “http://java.sun.com/dtd/web-app_2_3.dtd”>

Agora que o servidor sabe como interpretar este arquivo, ele precisa de um começo e de um fim, todas as tags de configuração do arquivo web.xml devem obrigatoriamente ser inseridas entre as tags <web-app> e </web-app>.

Outra tag muito utilizada é a tag display-name, que define o título padrão do seu projeto, a mensagem informada dentro desta tag será utilizada por todas as páginas da aplicação.
Exemplo: <display-name>Meu projeto!!!</display-name>

É possível também definir alguns parâmetros universais para seu projeto, por exemplo, queremos definir uma variável global para armazenar o nome do site, e em qualquer página podemos capturar e exibir este valor. Para isso utilizamos a seguinte configuração no web-xml:

<context-param>
<param-name>nomeSite</param-name>
<param-value>Meu Projeto!</param-value>
</context-param>

Onde param-name guarda o nome do parâmetro, é esta informação que devemos solicitar em nossas páginas, eparam-value é o valor que esta variável irá nos retornar sempre que à chamarmos.
Para recuperar esta variável em qualquer lugar da aplicação, basta utilizar o seguinte comando (retorna String):getServletContext().getInitParameter(“nomeSite“);

Uma coisa muito importante é a configuração dos servlets no web.xml!
Calma, não é preciso configurar cada jsp, somente as classes que irão trabalhar de forma visual, diretamente na tela do usuário, jsps apesar de serem servlets não precisam ser configurados.

Para configurar um servlet temos as seguintes tags:

<servlet>
<servlet-name>meuServlet</servlet-name>
<description></description>
<servlet-class>com.meu.pacote.ServletTal</servlet-class>
<load-on-startup>1</load-on-startup>
</servlet>

Aqui funciona mais ou menos assim:
As tags <servlet> e </servlet> indicam que entre elas está a configuração de um servlet.
A tag servlet-name contém o apelido que iremos dar ao nosso servlet, e é este apelido que será invocado pela aplicação quando formos utilizar este servlet, é uma tag obrigatória.
A tag description é apelas ilustrativa, ela não é funcional, serve para escrevermos uma breve descrição desta servlet, muito importante para futuras manutenções, porém não é obrigatória, coloca quem quer.
A tag servlet-class também é obrigatória, ela indica onde está a classe propriamente dita, aqui devemos informar o caminho completo do servlet, com pacote e tudo mais.
A tag load-on-startup não é obrigatória, mas se você colocá-la, estará informando ao servidor que este servlet deve ser carregado sempre que o projeto for iniciado, e o número que informamos dentro desta tag indica a ordem em que ele deve ser carregado, se na aplicação quisermos que 10 servlets sejam carregadas durante a inicialização do projeto, então devemos colocar esta tag load-on-startup na configuração de todas as 10 servlets, e em cada uma definimos a ordem de inicialização com números inteiros. Não precisa ser exatamente na sequencia, nem começar do 1, mas tem que ser inteiros! Se várias servlets possuirem o mesmo número, o servidor carrega alguma aleatóriamente.

É possível também chamar algum servlet diretamente pela URL, por exemplohttp://localhost:8080/Projeto/Chamandoservlet. Mas para isso é necessário uma pequena configuraçãozinha…

<servlet-mapping>
<servlet-name>meuServlet</servlet-name>
<url-pattern>/ChamandoServlet</url-pattern>
</servlet-mapping>

A tag url-pattern indica qual url deve ser informada para ativarmos nossa servlet.
A tag servlet-name indica o nome da servlet que deve ser chamada, aqui devemos informar o nome de alguma servlet mapeada no passo anterior.

É possível também determinar o tempo de vida das sessões de sua aplicação, muito útil quando se tem uma aplicação que transporta na sessão dados importantes.

<session-config>
<session-timeout>10</session-timeout>
</session-config>

Neste caso estamos configurando o tempo das sessões em 10 minutos, ou seja, se a aplicação ficar parada por 10 minutos, as sessões são eliminadas na memória!

Outra configuração interessante é a configuração dos arquivos iniciais, estes arquivos são procurados sempre que alguem acessa algum diretório da sua aplicação, sem informar um arquivo, por exemplo, para acessar algum site você informa apenas www.site.com.br e não www.site.com.br/paginaInicial.jsp, se os arquivos de inicialização estiverem configurados, digitando apenas www.site.com.br o servidor saberá que tem que mostrar a páginapaginaInicial.jsp.

<welcome-file-list>
<welcome-file>index.jsp</welcome-file>
<welcome-file>paginaInicial.jsp</welcome-file>
</welcome-file-list>

Com estas tags, sempre que um diretório da sua aplicação for chamado o servidor vai procurar dentro deste diretório um arquivo index.jsp ou um arquivo paginaInicial.jsp e exibi-los.

Estas são as principais tags genéricas do arquivo web.xml, existem trocentas outras tags para este arquivo, porém da pra se virar com estas dicas por enquanto!

JSF – HTTP Status 500

2011-02-16T20:51:00.000-02:00

Descrição: The server encountered an internal error () that prevented it from fulfilling this request.
Exceção:
org.apache.jasper.JasperException: Can’t find bundle for base name “xxxxxx“
java.util.MissingResourceException: Can’t find bundle for base name “xxxxxx“
java.util.ResourceBundle.throwMissingResourceException
java.util.ResourceBundle.getBundleImpl
com.sun.faces.taglib.jsf_core.LoadBundleTag.doStartTag
org.apache.jsp.pages.menu_jsp._jspx_meth_f_loadBundle

O que é?
“Erro 500, falha interna do servidor.
Este erro ocorre sempre que o servidor não consegue interpretar algo estranho no código, todos os códigos de erro que começam com 5 (500, 501, 502, etç.) significam basicamente isto, falha ao tentar entender o código, porém o erro 500 é genérico, o servidor não conseguir realizar a solicitação do código, mas também não sabe por que, os demais erros cujo prefixo é 5, o servidor ao menos sabe por que ocorreu o erro.”

Como resolver?
Repare que as linhas da exeção indicam todas as mesmas coisas:
Can’t find bundle for base name ou throwMissingResourceException, trazendo isso para o português ficaria mais ou menos “Não foi possível encontrar o pacote que se chama XXXXX“, ou seja, nosso pacote não foi encontrado, mas que pacote? basta reparar no que vem descrito depois de Can’t find bundle for base name, no caso do exemplo “XXXXXX“, este é o nome que à página está procurando, mas não o encontrou.
Verifique se este arquivo (properties, bean, xml, etç.) realmente existe e está no local indicado, se ele realmente existir, verifique se o nome tanto do arquivo quando do caminho está correto (br.com.projeto.pasta1.pasta2.arquivo, etç.) e não se esqueça que java é case sensitive, minhaClasse é diferente de MinhaClasse.

JSF – HTTP Status 500

2011-02-16T20:50:00.000-02:00

Descrição: The server encountered an internal error () that prevented it from fulfilling this request.
Exceção:
javax.servlet.ServletException: Error testing property ‘XXXX’ in bean of type null javax.faces.webapp.FacesServlet.service
javax.faces.el.PropertyNotFoundException: Error testing property ‘XXXX’ in bean of type null

Como resolver?
As mensagens de erro falam “a propriedade XXXX do bean NON ECZISTE!”Neste caso, existe um campo (input) na página que faz referência à uma variável de algum bean.

Primeiro verifique se a variávei existe, e se está com mesmo nome (não esqueça do case sensitive!).
Se o nome da variável estiver correto, verifique se ela possui os métodos gets e sets.
Se os métodos estiverem corretos, procure no faces-config.xml se o bean está corretamente mapeado.
Se tudo isso estiver certo, só resta uma alternativa, verifique no seu JSP se o nome do bean está exatamente igual ao alias dele definido no faces-config.
E boa sorte!

Tomcat – HTTP Status 404

2011-02-16T20:40:00.000-02:00

Tipo: Status report
Mensagem: [[Nome do Projeto]]
Descrição: The requested resource [[Nome do Projeto]] is not available.
Exceção:
Não é exibida exceção no navegador, mas ela pode ser encontrada nos logs do tomcat, pelo console onde o tomcat está sendo iniciado.

LifecycleException: Container StandardContext [[Nome do Projeto]] has not been started.
org.apache.catalina.core.StandardContext
org.apache.catalina.core.ContainerBase
org.apache.catalina.core.StandardHost
org.apache.catalina.core.ContainerBase
org.apache.catalina.core.StandardEngine
org.apache.catalina.startup.Catalina
java.lang.IllegalArgumentException: Document base [[Endereço]] does not exist or is not a readable directory.
org.apache.naming.resources.FileDirContext
O que é?
404 é um erro do tipo “client error“, ou seja, “erro no cliente“, basicamente o cliente (computador do usuário) fez alguma solicitação incorreta, neste caso (404) o cliente tentou solicitar algo que não existe, por exemplo, digitou uma URL que o servidor não conhece.

Como resolver?
1º – Verifique se digitou a URL corretamente, observe o case sensitive!
2º – Se o problema não é “de usuário” pode ser a configuração do projeto, então verifique os logs do tomcat no console, se estiver aparecendo mensagens como as descritas à cima, “Document base XXX does not exist…” ou “StandardContext has not been started” é provável que a configuração do arquivo server.xml esteja incorreta.
Se seu tomcat está com os contextos configurados no server.xml, procure o contexto da sua aplicação “<context path=”/Projeto” docBase=”algum_lugar”>” e verifique se o docBase está realmente apontando para a pasta certa da sua aplicação.
A pasta certa é aquela que abriga o WEB-INF, por exemplo, a pasta WEB-INF está dentro da pasta WebContent, então no docBase deve estar algo como “c:\blábláblá\Projeto\WebContent\“.
Se os seus contextos estão configurados via catalina, então abra o xml que está com o nome do seu projeto dentro da pasta Catalina (exemplo: PastaDoTomcat \ conf \ Catalina \ localhost \ Projeto.xml) e proceda da mesma forma como no arquivo server.xml, verifique se o caminho descrito no docBase do contexto está correto.

Container, o que é isso?

2011-02-16T20:11:00.000-02:00

Container é uma especie de caçamba, uma caixa de metal grande, aquela parte de tras de um caminhão “baú”.

Exemplo de container:

Mas o que seria um container em programação?

Seria basicamente, em orientação à objetos, um objeto que contém outros objetos, exatamente como o container demonstrado acima, um objeto grande que contém outros menores e os transporta de um lugar para outro, os objetos do container (de programação) podem ser incluídos ou excluídos em tempo de execução!

Agora falando mais especificamente em Java!
Um container possui os componentes da aplicação, como por exemplo os servlets (JSPs são servlets!), e quando você digita no navegador http://localhost:8080/MeuProjeto, o servidor não passa a solicitação para o JSP diretamente, ele passa o controle para o Container e este se encarrega de administrar o ciclo de vida desse servlet, a segurança, o suporte à exibição na tela, etç.

Alguns exemplos de Servlet Conteiners (containers web):

Comerciais:
JBoss
Oracle Application Server
WebSphere (IBM)
Netweaver (SAP)
JRun (Adobe)
GlassFish (Código Aberto)

Não Comerciais (Free!!!)
Tomcat
Jetty
Winstone
Apache Gerônimo

Lançar exceções quando quiser

2011-02-16T20:07:00.000-02:00

Algumas vezes criamos um programa/site/portal com muita dificuldade e o fazemos funcionar perfeitamente na máquina de desenvolvimento e até mesmo em servidores de teste, mas quando chega no cliente algo acontece, o fantasma de Murph aparece para fazer suas leis entrarem em cena e mensagens de erro do servidor pipocam na tela, como por exemplo o odiado erro 500…

Nessas horas algumas das coisas mais comuns:

“Por hora não é necessário resolver a situação”, ou.
“Quem configura o servidor não está conseguindo acertar os ponteiros do servidor”, ou.
“Após explicar ao usuário que isso não é um erro, ele pediu para alterar a tela “, ou.
Qualquer outra coisa que impeça o reparo deste erro e nos forçam simplesmente a tratá-lo.

Como é um erro 500, muitas vezes ele nem passa por classes, então nossos try-catch podem não surtir efeito.
Pode-se então mapear códigos de erro, como explicado NESTE post, facilitando muito a vida, porém surge uma questão.

Como podemos simular erros, como o erro 500?

A resposta vem de forma fácil, basta criar um JSP com uma simples linha de comando e o erro informado nesta linha irá aparecer na tela.

<%@ page import=”javax.servlet.http.HttpServletResponse” %>
<%
response.sendError(HttpServletResponse.SC_INTERNAL_SERVER_ERROR,”");
%>

Neste exemplo estamos simulando o erro 500, indicado pela String HttpServletResponse.SC_INTERNAL_SERVER_ERROR.

Neste link da wikipédia contém uma listagem com todos códigos de erro HTTP, com a descrição em inglês.
Neste link da Sun, documentação da linguagem J2EE, estão descritas todas as Strings de erro que podem ser utilizadas pelo response.sendError().

MVC - É pra comer?

2011-02-16T20:03:00.000-02:00

Model-View-Controler, ou MVC para os mais íntimos, isso não é uma linguagem, não é um framework, tão pouco uma IDE, mas então o que pode ser?

MVC é um padrão de desenvolvimento para projetos, principalmente, de grande porte cuja manutenção/mudança é constante, trabalhando com este padrão de desenvolvimento que separa o projeto em três partes, a manutenção e até o desenvolvimento ficam mais fáceis.

Como funciona?

Model – Camada de negócios.
View – Camada de visualização.
Controller – Camada de controle e validações.

Nota: Apesar de muitas biografias dizerem que não existe “camadas” na MVC, estas também não informam o que realmente é esta separação, porém a separação destas partes do projeto são, a grosso modo, realmente separadas em camadas, que é a definição utilizada aqui.

Durante a programação do projeto, deve-se separar todas as classes, jsps, imagens, xmls e demais arquivos em algumas camadas, em se tratando de Java, podemos trabalhar com pacotes.

MODEL, tudo aquilo que se refere à regras de negócio deve ser guardado no(s) pacote(s) da camada model.
VIEW, tudo que for relativo à tela, o que o usuário pode enxergar pertence à camada view e deve ser colocado no(s) pacote(s) referente à view, no caso dos jsps e imagens não á necessidade pois é subentendido que mesmo não estando em pacotes, todos os arquivos jsp, HTML, javascript, css, etç pertencem a esta camada.
CONTROLLER, aqui é onde a porca torce o rabo, ou melhor, onde a discussão se inicia, uma das práticas da MVC diz que esta camada serve para fazer a comunicação entre a VIEW e a MODEL, porém uma outra prática da MVC informa que esta camada serve apenas para efetuar as validações da camada VIEW.

A partir deste ponto, irei falar sobre duas formas diferentes de MVC, pois hoje em dia existe uma vasta discussão que nunca chega ao fim sobre a “verdadeira” forma da MVC. Por tanto irei comentar sobre as duas variações desta arquitetura, para você poder ter uma noção de como funciona e procurar realmente o que quer pra você.

Primeiro, irei apontar a camada controller como uma comunicação entre as outras duas camadas, segue imagem.

Neste caso, é possível notar que a camada view não enxerga de forma alguma a camada model.

Vejamos no exemplo:
Em um cadastro on-line, possuímos as páginas e imagens que o cliente pode ver e tocar com o mouse (view), temos as validações (controller) e após isso temos as regras de negócio e gravação em banco de dados (model).
Neste mesmo exemplo, o cliente preenche todos os dados na tela e clica em no botão de envio do formulário, neste momento todos os dados são repassados para a camada controller, as classes desta camada fazem a verificação dos dados informados, verificam se estão corretos, fazem a validação do CPF, etç. Se algo estiver errado o controller retorna uma mensagem de erro para a camada view, que a exibe na tela, se estiver tudo correto a camada controller repassa estas informações para a camada model.
A camada model, recebe as informações e verifica se o cliente é menor de idade (regra de negócio), em caso positivo estas informações são armazenadas na tabela X, caso negativo (cliente maior de idade) as informações são armazenadas na tabela Y.

Existe também a definição que inutiliza a camada Controller, informando que esta só serve para realizar validações, é um suporte da camada view.

No mesmo exemplo do cadastro citado acima, quando o cliente clica no botão de envio do formulário, este é repassado à camada controller que efetua as validações e repassa para a camada model, até aqui está igual a definição anterior, porém, em uma tela que não existe validação de formulário, por exemplo “escolha as opções A ou B”, como não há validação neste caso (validação de campo nulo pode ser realizada direto no jsp/html) ao ser acionado o botão de ação, a camada view repassa as informações diretamente para a camada model.

Nesta definição possuímos duas estradas virtuais, na imagem representada pela seta vermelha (ida e volta passando pelo controller) e pela seta verde (ida e volta sem passar pelo controller).

Mas como fazer as separações?

Se fosse fácil não teria graça…As camadas têm que ser muito bem planejadas, e deve ser impressa a seguinte frase “Não importar classes e métodos do pacote xx.xxx.xxx pelo pacote xx.xxx.xxx”, esta frase deve ser colada na mesa de cada desenvolvedor…

Como MVC é um padrão de desenvolvimento, não existe uma barreira que impeça você de, por exemplo, fazer a validação do CPF na camada de modelo, ou efetuar uma gravação em banco de dados na camada de visualização, porém se a MVC for seguida muito tempo e sangue serão economizados e casamentos poderão ser mantidos (viradas de noite prestando manutenção em código pode causar divórcio).

Algumas práticas em Java podem ser utilizadas para ajudar a manter o padrão de desenvolvimento, por exemplo a utilização de Implements e classes Abstratas, que bloqueiam a utilização em determinadas ocasiões, os modificadores de acesso Private, Public e Protected devem ser utilizados com sabedoria também, para restringir e/ou permitir acesso as classes e métodos corretos.

Agora, com a faca e o queijo na mão, boa sorte na implementação da MVC