CMM não funciona e NUNCA vai funcionar!

Capability Maturity Model, em outras palavras: burocracia inútil que não serve para nada. Peço desculpas aos (leigos) pessoas que adotaram ou estão felizes com este processo de desenvolvimento de software, mas sinto lhes informar que: essa ilusão tem hora certa para acabar. Quando seria? Já está sendo! É, isso mesmo! Só você ainda não percebeu, mas o CMM começa a explodir quando é adotado pela empresa (na maioria, fábricas de software!) – pense um pouco: Os cronogramas normalmente costumam atrasar? Quem mais trabalha costuma ganhar menos? Há pessoas na equipe que sequer sabem o que é ‘if – then – else’? Há pessoas na equipe de desenvolvimento que estão fazendo faculdade de administração, turismo, educação física, ou qualquer outra coisa sem nenhuma ligação com software? As pessoas são chamadas de recursos? O software é testado por testadores? Os testadores realmente NÃO SABEM AO CERTO o que testar? Antes de qualquer coisa, devem-se preencher quilos e quilos de documentos? Esses documentos são realmente usados? Há pessoas que estão sendo pagas para verificar se esses documentos inúteis são criados? O tempo perdido na criação dos documentos são maiores do que o de desenvolvimento do software em si? Alterações no cronograma é algo que acontece com freqüência? Os analistas de sistemas nem lembram mais como programar? O programador não pensa, apenas digita o caso de uso em português estruturado? O produto primeiro é analisado, programado e depois testado? O cliente pede algo e só volta a ser consultado depois que a cascata foi e voltou dezenas de vezes? Entre outras perguntas…

Se você respondeu tudo ou quase: ‘sim’, parabéns, sua empresa já está apta a ganhar outro nível CMM. Mas será que o gerente da sua empresa já parou para pensar que isso gera software atrasado, de má qualidade, com maiores custos e um re-trabalho enorme? Provavelmente ele está encantado com a linha de produção de software, que parece funcionar como uma fábrica de sapatos.

É tão difícil colocar na cabeça que isso tudo é puro merchant ? Software deve ser desenvolvido com agilidade, praticidade, flexibilidade e participação intensa do cliente –e principalmente- por pessoas, não por recursos. Desenvolvedores não são robôs de fábrica. Desenvolvedores só produzem com qualidade quando estão animados com o processo, com o desafio, com seus colegas, e, claro, em não ter o mesmo salário de um inútil que não faz nada.

Até quando isso vai durar?

Referências: http://www.agilemanifesto.org/

Entendendo o Padrão de projetos: Strategy

Antes de mais nada, gostaria de enviar um abraço aos amigos da comunidade do Orkut “Java BR (cmm=19706)” – Pessoal sempre ajudando quem precisa, boas discussões e um bom ponto de divulgação de vagas de emprego na área, etc.

Entendendo o Padrão de projetos: Strategy – por Robson Farias

Um dos ‘design patterns’ mais importantes catalogados é o Strategy. Um padrão que visa a reutilização, organização e flexibilidade de seus algoritmos. Um marco importântissimo no desenvolvimento de software Orientado a Objeto.

Neste ‘post’ tentarei explica-lo, utilizando a linguagem Java para os exemplos.

Duas das principais dicas que esse padrão prega é:

- Programe sempre para interfaces

É importante ressaltar que, neste contexto ‘interface’ não significa apenas aquelas classes abstratas marcadas com a palavra reservada ‘interface’; mas sim para qualquer modelo reutilizável e abstrato, seja explicitamente uma interface ou uma classe abstrata, o que interessa é ser um modelo bem definido de uma abstração.

- Dê preferência a composição ao invés de herança.

Herança te limita a implementações. É-UM neste caso força o futuro de seus objetos serem sempre dependentes das implementações herdadas. – Já composição (TEM-UM), lhe permite desfrutar de coisas como, erhm.. o padrão de projetos Strategy.

Definimos então um problema:

Uma empresa do ramo de vendas pela internet disponibiliza diversos tipos de produtos para vendas on-line, a empresa é famosa por sempre ter os melhores descontos e promoções. Atualmente, o sistema desta empresa trata os produtos com base no seguinte modelo:

package sem.strategy;

import java.math.BigDecimal;

public abstract class Produto {

public BigDecimal desconto() {

return 5;

}
}

Todos os produtos cadastrados, herdam desta classe. O produto que requer um desconto diferente precisa sobre-escrever a função desconto.

Certo dia, o gerente da empresa teve a brilhante idéia de solicitar ao pessoal do desenvolvimento a seguinte melhoria: A empresa passaria a oferecer descontos padrões para diferentes datas especiais, como Natal, Dia das mães, dia dos namorados, etc. – a equipe de desenvolvimento, que não conhecia o padrão Strategy, logo pensou em entupir as funções ‘desconto()’ sobre-escritas nas classes dos Produtos com ‘if´s’ verificando se a data em questão era uma data especial. Obviamente, que, sempre que surgiam novas datas especiais ou se fossem descartadas outras, o código era retrabalhado, alterado, o sistema parava e era re-implantado novamente, o que gerava uma manutenção mais custosa.

Foi então que um novo desenvolvedor, conhecedor do padrão Strategy, sugeriu seu uso neste caso, o que ele fez:

criou uma interface Promocao (QUE SERÁ NOSSA ESTRATÉGIA), e a definiu da seguinte maneira:

package com.strategy;

import java.math.BigDecimal;

public interface Promocao {
BigDecimal desconto();
}

Então, criou diferentes tipos de implementação para esta promoção, sendo elas:

class PromocaoDeNatal implements Promocao {

@Override
public BigDecimal desconto() {
return 10;
}

}

class PromocaoDiaDosNamorados implements Promocao {

@Override
public BigDecimal desconto() {
return 15;
}

}

class PromocaoQueimaDeEstoque implements Promocao {

@Override
public BigDecimal desconto() {
return 40;
}
}

E então, refatorou a classe abstrata produto assim:

package com.strategy;

import java.math.BigDecimal;

public class Produto {
protected Promocao promocao;

public BigDecimal desconto() {
return promocao.desconto();
}
}

Agora, cada produto poderia determinar um tipo de promoção diferente, a qualquer momento (em tempo de execução) ou não. E a cada nova promoção, bastasse criar uma nova implementação e usar.

Exemplo de uma TV determinando sua promoção:

public class Celular extends Produto {
public Celular() {
this.promocao = new PromocaoDeNatal();
}
}

Note que foi usado uma inversão de controle no constructor do Celular, mas também pode ser criado métodos de acesso a variavel de instância para que possa ser encapsulado isso. O ideal mesmo, é que se utilize um container de Injeção de dependências, como o Spring. Explicado em outro artigo.

Concluimos que, o padrão Strategy é util sob famílias de objetos que necessitam de uma estratégia para mudar seu comportamento de forma plugável em tempo de execução.

Obviamente este foi um exemplo simples (desconsiderem o fato d´eu não ter testado os códigos), que poderia ser feito de diversas outras formas (eu usaria Enum particularmente), mas para melhor entendimento por parte do leitor, foi uma boa escolha. Espero que tenham gostado, qualquer coisa, postem aí! )

UML: http://www.tml.tkk.fi/~pnr/GoF-models/gif/Strategy.gif

Referências: Head First, Design Patterns.

Inversão de controle (IoC) e Injeção de dependências (DI), o que é ?

Uma das maiores dúvidas do pessoal que está iniciando no entendimento do Java EE, é entender os conceitos e padrões definidos pela comunidade. Neste “post” tentarei explicar o que é e, para que serve a Inversão de controle com injeção de dependências em arquitetura e desenho de aplicações. Por uma questão exemplar, os códigos aqui contidos não estarão no formato “copy-paste-and-compile-success”, mas irão lhe dar um ótimo empurrão para sair caçando materiais Internet à fora, etc. Os exemplos serão detalhados na linguagem de programação Java.

Martin Fowler, escreveu um bom artigo em seu site sobre estes dois padrões, recomendo como uma leitura introdutória a esta (ou vice-versa), não se preocupe que lá tem um link para uma versão em português. Como para mim, não será suficiente para você (caso ainda não entenda bulufa de nada disso), então recomendo a não parar por aí e realmente usar na prática os padrões. O link pode ser conferido aqui: http://martinfowler.com/articles/injection.html

Muitas pessoas costumam confundir inversão de controle com injeção de dependências, até mesmo tem quem o diga que se trata da mesma coisa. Mas não é bem assim (você verá o porquê mais adiante, pois não foi à toa que prego: Inversão de controle COM injeção de dependências).

O pior defeito de quem inicia neste ramo é sempre procurar entender um conceito a fundo sem ao menos parar para pensar no próprio nome do conceito, este por sinal já pode ser tudo que lhe seja necessário para entender o tal. É assim com Inversion of control and Dependency Injection.

- Inversão de controle: O que viria ser inverter o controle? Vamos pensar o seguinte: Há um cargo em sua empresa de gestor de TI, este cargo exige que a pessoa saiba controlarPessoas(), administrarRecursos() e gerenciarOSetor(). Você contrata um bom profissional para executá-lo (José) conforme o perfil acima e o coloca no CONTROLE. Passa dois anos e aquela pessoa começa a demonstrar deficiências em determinado aspecto, ai então você contrata outra pessoa (João) com as qualificações necessárias e.. e.. INVERTE O CONTROLE da gestão de TI da empresa! (Pobre José!) Pode parecer um tanto exótico este exemplo, mas você já conseguiu notar que as minhas simples colocações em forma de métodos nas habilidades do cargo já começam a esclarecer a ligação com a forma prática (ou seria programática) de se fazer.

- Injeção de dependências: Seguindo nosso mesmo estranho exemplo, vamos supor que você não quer saber de cuidar do RH da sua empresa, e coloca um profissional para tal, então a partir daí quem faz o papel de contratar, demitir e é ele. Logo, quando um executor de determinado cargo precisa ser invertido, este profissional escolhe outro e .. e.. INJETA A DEPENDÊNCIA no cargo, conseqüentemente invertendo o controle.

(Neste momento estou pensando se eu confundi mais do que ajudei… )

Vamos fazer o seguinte, .. vou começar a falar mais tecnicamente e cada vez que você não entender nada, sobe até os últimos dois tópicos e leia os conceitos que até aqui parecem estranhos.

Desenho orientado a interfaces

Sabemos que uma das boas práticas (blueprints) no desenvolvimento de aplicações, é esquecer da implementação no momento que estiver especificando. Isso torna seu projeto INDEPENDENTE de implementação, logo você está promovendo o baixo acoplamento. Ta, ta, parei.

Vamos lá, com base no nosso exemplo em português (ou quase) estruturado acima, temos:

interface Gestor {

void controlarPessoas();

void administrarRecursos();

void gerenciarOSetor();

}

//este setor é responsável por inverter controles

class RH {

void escolherGestor(Gestor gestor) {

minhaEmpresa.setGestor(gestor);

}

}

class João extends Pessoa implements Gestor {

//considere os metodos implementados aqui..

}

class Jose extends Pessoa implements Gestor {

//e aqui

}

class Aplicação {

public static void main(String [] argumentos) {

RH rh = new RH();

//antes era o José, mas hoje é o João

//Apenas invertemos o controle, mas não injetamos a dependência

Gestor gestor = new João(); // new Jose();

Rh.escolherGestor(gestor);

}

}

(Aqui você deve estar procurando entender a utilidade disso)..

Veja que, quando nós alteramos uma implementação, o que é alterado é apenas o que vem depois do “=”, polimorficamente falando, pois tanto como João quanto Jose implementam Gestor e podem estar ali. Mas o foco do padrão de inverter o controle de determinada missão não é isso. O foco é além de ter o baixo acoplamento, é centralizar esta configuração em um único lugar. É aí que entra os FRAMEWORKS DE INJEÇÃO DE DEPENDÊNCIAS. Entre eles, posso ressaltar o Spring, PicoContainer, Guice, entre outros muito utilizados pela comunidade. O que eles fazem é o papel do RH do nosso exemplo, se tornando nossos empregados para cuidar de injetar as dependências das nossas classes e/ou inverter o controle de outras, quando necessário.

De uma forma exemplar, vamos considerar o seguinte: Dentro da nossa aplicação existe 400 lugares onde o Gestor é instanciado usando a implementação do José (Gestor gestor = new Jose()), quando resolvermos inverter o controle, teríamos um duro trabalho de refatorar ponto-a-ponto e substituir new Jose() por new João(). Isso seria extremamente chato uma vez que você possa pensar na possibilidade do João um dia não atender o requerido e ter que ser substituído novamente, em outras palavras: re-trabalho. Mas pense, não seria fantástico se pudéssemos centralizar a escolha de quem vai implementar Gestor em um arquivo só, e alguém mais responsável que nós, fizesse esse trabalho árduo de injetar essa implementação ? É exatamente desta forma que os frameworks trabalham.

Nosso arquivo de configuração aqui nomeado: framework-config.xml,

Dentro dele a seguinte estrutura:

<IoC classe=br.com.Gestor>

<DI injete=br.com.Jose/>

</IoC>

Agora nos 400 lugares da nossa aplicação onde é necessário uma injeção de dependências explicitas, não iremos mais nos preocupar com a instanciação da implementação, deixaremos isso com o framework.

Considerando a nossa classe que possui membros que precisam receber as injeções:

class RH {

Gestor gestor; //note que aqui há uma DEPENDÊNCIA de uma implementação

}

Bom, como pode ter sido analisado no xml de configuração do nosso pseudo-framework cada vez que você criar a classe RH o container do seu framework vai percorrer de alguma forma o xml de configuração e verificar onde injetar e o que injetar. Ex:

RH rh = meuFrameworkDeDIPreferido.instancieEInjecteAsDependencias(RH.class)

(Nota: Ficaria melhor criar uma Factory para isso, assim você também ficaria independente de framework de DI, algo como: RH rh = Factory.getInstance(“rh”); e o getInstance cuidaria de quem iria construir a sua classe.)

Feito isso, podemos ficar tranqüilos que o nosso framework a partir daí, irá se encarregar de fazer o restante do trabalho (não fique com medo que você não receberá nenhum NullPointerException ao tentar utilizar gestor).

Desta forma, o dia que precisarmos substituir Jose por João, apenas iríamos alterar nosso arquivo xml, e substituir a linha “<DI injete=br.com.Jose/>” por “<DI injete=br.com.João/>” e puff, as dependências continuariam sendo injetadas e o controle daquela interface seria invertido sem alterar absolutamente nada no código.

Espero que tenham entendido este conceito tão importante nos dias de hoje e não deixem de deixar um feedback caso continuarem com dúvidas. Valeu, até a próxima!

Robson

Referências:

http://martinfowler.com/articles/injection.html

http://www.picocontainer.org/injection.html

http://static.springframework.org/spring/docs/2.0.x/reference/beans.html

 

Iniciando com JSF no Red Hat Developer Studio

    Olá pessoal. Estes dias, navegando pela internet atrás de uma boa IDE para se trabalhar com JSF, me deparo com alguns comentários, a respeito do RHDS (antigo Exadel). Baseado no Eclipse, e apesar de ser uma ferramenta paga, eles haviam disponibilizado os seus betas e RCs livremente, para à comunidade testar. Minha sorte, é que o RC1 está muito bom, e por enquanto, ainda não achei problemas grotescos, que podem vir a ameaçar a integridade do sistema. Então, para quem não tem condições de pagar pela IDE, aqui está uma versão livre dela, é só clicar, baixar e instalar: ftp://ftp.redhat.com/pub/redhat/rhdevstudio/beta/r…hdevstudio-win32-1.0.0.CR1.jar

 

O intuito deste post, é apresentar para quem está com dificuldade em sair do modo baixo nível (edições de xml´s à mão) e demonstrar a grande facilidade que a IDE oferece para a maioria dos casos mais “chatos de se configurar”. Iremos construir uma pequena aplicação em JSF dentro do famoso contexto: “Olá mundo”. Por enquanto é apenas isso. Mais para frente, vejo a possibilidade de brincar com o Struts, Ájax, Hibernate, Spring, etc.

 

- Antes de continuarmos, baixe e instale o servidor de aplicações JBoss: http://www.jboss.org

 

Vamos ao que provavelmente trouxe você até aqui (desligue o som do PC, TV, tire o irmão do quarto e diga à namorada que precisa urgente ir ao mercado com sua mãe):

 

1 – Criando um projeto JSF no RHDS:

 

Menu File -> New -> JSF Project (Caso o JSF Project não esteja a vista, siga: Menu File -> New -> Other -> JBoss Tools Web -> JSF -> JSF Project)

 

Em project name, digite: OlaJSF

Em JSF Environment, escolha: JSF 1.2

Clique em Finish.

 

2 – Configurando o faces-config.xml

 

Expanda à arvore do projeto: OlaJSF/WebContent/WEB-INF e dê um duplo-clique sobre o arquivo faces-config.xml abrindo-o no editor default: JBoss Tools XML Editor (Caso não abra neste, siga: Botão direito em cima do arquivo, Open with… e o selecione.)

 

Agora você deve estar de frente com o editor. Como pode ver, é como um pequeno mapa. Nele iremos configurar nossos rules e cases.

 

Vamos adicionar então, duas páginas no nosso mapa, seguindo o procedimento:

Botão direito em cima de qualquer parte da área -> New View. No campo: From-View-Id, digite: pages/inputname, o resto deixe como está e clique em: Finish.

 

(Como você pode ter notado, ele, além de adicionar o ícone da página ao mapa, já a criou fisicamente também, bem como sua pasta (pages), ficando no seguinte diretório em sua árvore do projeto: OlaJSF/WebContent/pages/inputname.jsp)

 

Efetue o mesmo procedimento para criar a página: pages/showname

Se você fez tudo certo até aqui, terá então, dois ícones no seu diagrama representando nossas respectivas páginas.

 

3 – Criando as transições

 

Uma transição consiste em uma conexão entre as páginas.

 

Para criarmos nossas transições, devemos estar com o faces-config.xml aberto em modo diagrama. (Neste momento, salve seu projeto, para se prevenir de fatalidades como queda de energia).

 

Ao lado direito do diagrama, você pode observar uma pequena flechinha preta em degrau, coloque o mouse sobre ela, e aparecerá o seguinte tooltip: “Create New Connection”. Clique nela, e depois atribua seu ponto inicial clicando sobre o ícone que representa a página “inputname” em nosso diagrama, arrastando sua conexão até o ícone que representa a página: “showname”, clique, e verá a conexão ser renderizada pelo nosso diagrama. (Ctrl+s para salvar)

 

4 – Adicionando os managed beans

 

Nossos managed beans, são os modelos que participam da nossa página. Iremos criar um.

Em nosso mesmo ambiente (diagrama do faces-config.xml) podemos observar no rodapé, três abas, sendo que a primeira é a do diagrama em si (Diagram), e a segunda: Tree, e é nesta que devemos ir agora. Clique lá.

 

Note que o cenário mudou.

 

Ao lado esquerdo agora temos uma árvore de configurações. Clique em: Managed Beans, ao miolo da tela, abrirá o modo edição do mesmo.

 

Clique no botão: “Add…”, irá abrir a tela para adicionarmos nosso managed bean. Siga a seguinte configuração em ordem:

Scope: request

Class: olajsf.PersonBean

Name: personBean

 

Caso não esteja marcado, marque o checkbox: Generate Source Code. Clique em Finish.

 

Como pode observar, nosso cenário agora consta: Metade sobre nosso bean recém criado, e outra metade chamada: Properties, e é lá que devemos trabalhar agora. Clique sobre o botão “Add…” e siga a seguinte configuração em ordem:

Property-Name: name

 

O resto você pode deixar tudo como está. O valor default de uma propriedade é: String.

 

Pronto. Salve tudo novamente.

 

Para quem se perdeu, ou está em dúvida se esta fazendo certo o processo, agora vai o código do faces-config.xml:

<?xml version=“1.0″ encoding=“UTF-8″?>

<faces-config version=“1.2″ xmlns=“http://java.sun.com/xml/ns/javaee”

 xmlns:xi=“http://www.w3.org/2001/XInclude”

 xmlns:xsi=“http://www.w3.org/2001/XMLSchema-instance” xsi:schemaLocation=“http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-facesconfig_1_2.xsd”>

 <managed-bean>

  <managed-bean-name>personBean</managed-bean-name>

  <managed-bean-class>olajsf.PersonBean</managed-bean-class>

  <managed-bean-scope>request</managed-bean-scope>

  <managed-property>

   <property-name>name</property-name>

   <value/>

  </managed-property>

 </managed-bean>

 <navigation-rule>

  <from-view-id>/pages/inputname.jsp</from-view-id>

  <navigation-case>

   <from-outcome>showname</from-outcome>

   <to-view-id>/pages/showname.jsp</to-view-id>

  </navigation-case>

 </navigation-rule>

</faces-config>

 

Caso o seu esteja diferente disso, conserte as diferenças editando seu faces-config.xml em modo: Faces Config Editor.

 

Você deve estar se perguntando: Poxa! Tudo isso até agora, para fazer pouco mais de 20 linhas de configuração? – Sim! Notará a diferença quando for fazer uma aplicação realmente complexa.

 

5 – Editando nossas páginas JSP

 

Agora vamos editar nossa página JSP, começaremos pela: pages/inputname.jsp que está dentro da pasta: pages. Dê um duplo-clique sobre ela para abrir no editor padrão: JBoss Tools JSP Editor. Você verá um miolo dividido em dois: em cima o código e em baixo a parte de visualização, para os puristas: WYSIWYG. Para melhor trabalharmos, vamos esquecer a parte de código por enquanto, e se focar na visualização. Note que no rodapé deste painel, há as seguintes abas: Visual/Source / Visual / Source / Preview – Clique sobre a Visual, para focarmos somente nesta parte.

 

Caso a paleta de ferramentas não esteja expandida (ao canto esquerdo), o faça clicando sobre o ícone em forma de paleta de tinta, a esquerda superior do editor. Expanda a pasta: JSF HTML para visualizar os componentes que iremos trabalhar.

 

Clique sobre o componente: Form e o arraste até a parte pontilhada da nossa visualização. – Neste momento irá se abrir a tela de propriedades do Form, no atributo: ID, digite: showname e clique em finish.

 

Arraste para dentro dos pontilhados do form criado, o componente: outputLabel, abrirá sua tela de atributos, e para a propriedade Value, digite: “Entre com seu nome: ”

 

Arraste para dentro dos pontilhados do form, o componente: inputText, abrirá sua tela de atributos, e na propriedade Value com o foco sobre ela, aparecerá no fim do seu campo, o botão “…”, clique nele, e abrirá uma tela de seleção de atributos. Escolha o atributo “name”, do nosso managed bean: personBean, expandindo a seguinte raiz: Managed Beans / personBean / name, o valor do campo Value, ficará assim: #{personBean.name} – Na tela de atributos ainda, atribua o valor: name, para o campo: Id da sub-aba Advanced.

 

Precisamos colocar agora um botão, para processar tudo isso. Arraste o seguinte componente (Ainda da pasta JSF HTML) para o lado do inputText: commandButton. Na tela de atributos, foque no atributo Action, clique no botão “…”, e selecione: View Actions / showname, clique em OK. No campo value, digite: “show!” (que nada mais é do que o label que representa o texto do botão). Close. Salve tudo.

 

Para quem se perdeu, ou está em dúvida se esta fazendo certo o processo, agora vai o código do inputname.jsp:

 

<%@ taglib uri=“http://java.sun.com/jsf/html” prefix=“h” %>

<%@ taglib uri=“http://java.sun.com/jsf/core” prefix=“f” %>

 

<html>

      <head>

            <title></title>

      </head>

      <body>

            <f:view>

                 

            <h:form id=“showname”><h:outputLabel value=“Entre com seu nome:”>

                 

            </h:outputLabel><h:inputText value=“#{personBean.name}” id=“name”/><h:commandButton action=“showname” value=“show!”/>

           

           

            </h:form>

            </f:view>

      </body>    

</html> 

 

Vamos configurar agora a outra página: pages/showname.jsp, como de costume, abra ela no mesmo editor que a anterior, dando um duplo-clique sobre a mesma, e abra em modo Visual.

 

Traga até a o corpo da página um outputText da pasta JSF HTML que se encontra na paleta, e na tela de atributos, configure seu atributo Value para: “Olá :”

 

Arraste outro outputText para depois do anterior, e na tela de atributos, foque o campo Value, e clique sobre o botão que irá aparecer: “…”, selecionando o nosso campo: Managed Beans/personBean/name, ficando: #{personBean.name} – OK e Close. Salve tudo.

 

Para quem se perdeu, ou está em dúvida se esta fazendo certo o processo, agora vai o código do showname.jsp:

 

 

 

<%@ taglib uri=“http://java.sun.com/jsf/html” prefix=“h” %>

<%@ taglib uri=“http://java.sun.com/jsf/core” prefix=“f” %>

 

<html>

      <head>

            <title></title>

      </head>

      <body>

            <f:view>

                 

            <h:outputText value=“Olá :”/><h:outputText value=“#{personBean.name}”/>

           

            </f:view>

      </body>    

</html> 

 

 

Por fim, devemos criar a página de apresentação, que irá redirecionar para a página inputname. Clique com o botão direito em cima da pasta: WebContent -> New -> JSP File – Na tela que abrirá, siga a configuração:

Name: index

Template (Selecione): JSPRedirect

 

O resto deixe como está – Finish.

 

Edite o conteúdo do forward, para efetuar o redirecionamento, passando a página como valor, ficando assim: <jsp:forward page=”/pages/inputname.jsf” />

 

OPA! Mas a minha página inputname, é com final .jsp! – Sim, mas conforme é configurado no arquivo web.xml, o nosso mapeamento esta definido para extensões jsf!

 

Salve tudo.

 

Para quem se perdeu, ou está em dúvida se esta fazendo certo o processo, agora vai o código do index.jsp:

 

<!doctype html public “-//w3c//dtd html 4.0 transitional//en”>

<html>

<head></head>

      <body>

            <jsp:forward page=“/pages/inputname.jsf” />

      </body>

</html>

 

6 – Testando nossa aplicação:

 

1º – Inicie o servidor do JBoss, clicando no botão que parece um “play” verde, no toolbar da IDE.

2º – Clique com o botão direito sobre o projeto -> Run As… -> Run on Server – Na tela que aparecer, selecione o JBoss, e clique em Finish.

 

Caso você tenha feito tudo certo, basta você digitar seu nome e clicar no botão “show”, para ver a aplicação funcionar e lhe mostrar um simples: “Olá: Fulano”.

 

Bom, por hoje é só. Espero que tenham gostado da IDE (ou para quem apenas acompanhou os códigos) e do Jsf!

 

Até a próxima!

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

A leitura e a sociedade (Se você se acha alfabetizado, lhe desafio a ler este texto!)

Entender e interpretar. A um bom tempo venho analisado estas duas condições. Desde que comecei a tomar gosto pela leitura, ainda criança, sempre obtive um estímulo diferente das minhas vontades atuais. Com assuntos e histórias sempre divertidas, porém supérfluas. Foi assim que conheci o Gibi da Turma da Mônica! Ei, ei. Espere. Continue lendo. Verá o porquê no segundo parágrafo.

            Em uma vida de criança, não há problemas. Nem mesmo preocupações, estresses, ou <coloque-aqui-qualquer-outro-problema-do-mundo-oriúndo-desses-humanos>, etc. Então, o pequeno, consegue obter um encanto através dos desenhos, balõezinhos, e quadrinhos. Foi assim que conheci pela primeira vez, a amiga: concentração. Amiga em termos. Às vezes (quase sempre), ela resolve brigar comigo, e com você. Mas não com quem terminar de ler este texto. Você está me entendendo? Se sua resposta for: Sim, continue lendo. Senão, já pode ir ver à novela.

            Vinte anos de idade. Fazendo faculdade e trabalhando. Este é o meu estado atual. No meio de um mundo totalmente louco, onde um humano quer ferrar com o outro. Oportunidades de trabalho desaparecem antes mesmo de surgirem (seria o mal do Q.I. (quem indica)? Se conseguiu interpretar, explicarei mais adiante à solução, senão, ainda dá para pegar o próximo capítulo da novela). É algo que realmente lhe prende a tentar viver sempre um passo a frente do seu humano concorrente (que amanhã tentará sua cadeira).

Perante todos estes problemas mercantilistas, uma boa forma de pensar a frente do cérebro do seu próximo, é estimulando a leitura técnica. Oras.. o que viria a ser uma leitura técnica? É simples: Uma leitura técnica é aquela na qual você lê cinco vezes a mesma coisa, e não entende nada, mas, sabe que é necessário registrar aquilo no seu cérebro. Apresento a você a: Força de vontade! (Você já deve ter ouvido falar dela, mas nunca foram apresentados). Definição expressa: Ter força de vontade não é persistir, e sim prevalecer perante um objetivo. (beeem.. diferente da idéia do: “tente outra vez” ala Raul Seixas.) Quando se tem força de vontade, você não apenas persiste cinco, dez, vinte, mil vezes. Mas, sim o necessário até prevalecer perante o problema, em nosso caso: a i-n-t-e-r-p-r-e-t-a-ç-ã-o, pronto! Tudo escrito até aqui, até então, foi para dizer uma coisa óbvia, na qual você até já imaginava, a qual é o maior problema na hora de ler, de 95% dos casos, desses humanos (ahh, esses humanos!). Interpretar algo pode ter duas interpretações:

1ª) Você interpreta. 2ª) Você acha que interpreta

Qual a solução? Conferir se realmente sua interpretação tem harmonia com o entendimento que o escritor está querendo lhe passar. (Opa! Acabei de diferenciar algo que parecia ter o mesmo significado: Entender e interpretar.) O que isso quer dizer? Que uma interpretação é como se fosse uma crítica, algo pessoal, abstrato ao seu ser. Entendimento é um alívio, perante uma leitura complicada. (Você vai saber quando entendeu ou não, compreende? A novela já acabou…)

Das ocorrências, posso assegurar que em muitos casos, o problema pode ser a TV (Se não entendeu, tente desligar a TV e ler novamente), em outros, pode ser o seu lindo animalzinho, que não para de latir. Ou até mesmo, aquele povo na sua casa batendo boca até altas horas.

Da solução, você deve buscar em seu interior. Olhe aquele monte de letras e encare. Leia, releia! Vá até o fim. Não, mas nunca, desista daquela frase. Qualquer palavra perdida pode ser crucial para o entendimento. Faça isso sempre longe da sociedade. Se isole. Só assim você vai conseguiu seu objetivo: Ler, interpretar e entender. Afinal, um texto pode ter vários significados, e estará sempre lhe colocando a prova: Absorver o verdadeiro significado! Afinal de contas, a largada é diferente da chegada, mas são as mesmas. (Me envie um e-mail, se quer exemplos)

            Onde isso tudo se torna interligado? Posso considerar este parágrafo como a conclusão do meu texto. Pois, resumidamente, digo que é um absurdo você ter lido até aqui, e não ter obtido o entendimento. Vou dar uma dica: Quem você contrataria para ser o auxiliar de escritório da sua empresa? Seu sobrinho ou uma pessoa sábia e estudiosa? Claro que seu sobrinho, ora! (Não se deixe influenciar por nenhum texto informativo. Ganhe suas próprias influências. (dica de escoteiro)). Refazendo a questão: Quem você contrataria para gerenciar sua empresa? Um abraço, até a próxima!

 

Robson