Integração de JSF com JSP Tagfiles
Frederico Guedes Pereira
Vocês têm algum material sobre a integração de JSF com JSP tagfiles? Basicamente eu gostaria de encapsular num tagfile fragmentos recorrentes de componentes JSF, para evitar duplicacao desnecessária dentro de uma página ou de várias páginas da aplicação. Estes tagfiles seriam parametrizados e os parâmetros abasteceriam valores de atributos dos componentes JSF. Exemplo:
<%@attribute name="valor" required="true" rtexprvalue="true" %>
<%@tag body-content="empty"%>
<%@taglib prefix="h" uri="http://java.sun.com/jsf/html" %>
<!-- begin:labelItem.tag -->
<h:panelGroup>
<h:graphicImage url="images/topic.gif" />
<h:outputText value="${valor}" />
</h:panelGroup>
<!-- end:labelItem.tag -->
Acontece que a EL "${valor}" é JSP e não pode ser usada num componente JSF. Se alguém conhece algum material (artigo ou livro) que aborde este assunto manda para a lista, ok?
Grato,
Fred
Maurício Linhares
2008/2/8 Frederico Guedes Pereira <fredgued...@gmail.com>:
--
Maurício Linhares
http://alinhavado.wordpress.com/ (pt-br) |
http://codeshooter.wordpress.com/ (en)
João Pessoa, PB, (83) 3231-5419
Torquato Neto
coisa chata é que pra quem utiliza o eclipse (nao sei dizer se tb
acontece no netbeans), o auto-complete (crtl+space) nao funciona mais
para as tag de jsf, jstl, uma vez que nao vai mais declarar a taglib e
sim, colocar um namespace com a url da taglib na tag "<html>". Se
alguem conhece um plugin para o eclipse ou alguma soluçao.. fico
grato, valeu
On 8 fev, 12:34, "Maurício Linhares" <mauricio.linha...@gmail.com>
wrote:
> 2008/2/8 Frederico Guedes Pereira <fredguedespere...@gmail.com>:
Maurício Linhares
arquivos do Facelets.
2008/2/8 Torquato Neto <torqu...@gmail.com>:
>
> com Facelets vc consegue fazer o esquema do template tranquilo, a
> coisa chata é que pra quem utiliza o eclipse (nao sei dizer se tb
> acontece no netbeans), o auto-complete (crtl+space) nao funciona mais
> para as tag de jsf, jstl, uma vez que nao vai mais declarar a taglib e
> sim, colocar um namespace com a url da taglib na tag "<html>". Se
> alguem conhece um plugin para o eclipse ou alguma soluçao.. fico
> grato, valeu
>
--
Maurício Linhares
http://alinhavado.wordpress.com/ (pt-br) |
http://codeshooter.wordpress.com/ (en)
Elaine Cristina
Frederico Guedes Pereira
Eu vou dar uma olhada, mas gostaria que a solução estivesse em "casa" mesmo e não num produto externo (mais jars, mais configuracoes, mais erros, etc.etc.). Será que há alguma previsão para melhorar a integração da EL do JSP com a do JSF nas versões futuras das APIs?
Fred
Maurício Linhares
De qualquer forma, é uma prova de coragem, boa vontade e muita
paciência, escrever aplicações JSF no braço, sem usar Facelets ou um
framework de suporte como o Seam, poucas coisas são mais abomináveis
do que configurar o faces-config ou tentar pegar um parâmetro do
request e inicializar uma variável em um managed bean com esse valor.
Ou, melhor ainda, colocar objetos de acesso a banco de dados (como
DAOs ou repositórios) ou serviços como sendo propriedades dos managed
beans
Eu não teria mais estômago pra fazer isso não, acho que já teria
morrido de úlcera =D
É bom você dar uma olhadinha nessas coisas viu Fred, porque JSF
purinho é ruim de descer =P
vinicius souto
Torquato Neto
funciona pra facelets. nao queria precisar usar o exadel estudio ou
outra ide, vale a pena baixar e testar, valeu
> Em 09/02/08, Maurício Linhares <mauricio.linha...@gmail.com> escreveu:
>
>
> > No JSF 1.2 as duas linguagens foram fundidas.
>
> > De qualquer forma, é uma prova de coragem, boa vontade e muita
> > paciência, escrever aplicações JSF no braço, sem usar Facelets ou um
> > framework de suporte como o Seam, poucas coisas são mais abomináveis
> > do que configurar o faces-config ou tentar pegar um parâmetro do
> > request e inicializar uma variável em um managed bean com esse valor.
> > Ou, melhor ainda, colocar objetos de acesso a banco de dados (como
> > DAOs ou repositórios) ou serviços como sendo propriedades dos managed
> > beans
>
> > Eu não teria mais estômago pra fazer isso não, acho que já teria
> > morrido de úlcera =D
>
> > É bom você dar uma olhadinha nessas coisas viu Fred, porque JSF
> > purinho é ruim de descer =P
>
>
> > > Eu vou dar uma olhada, mas gostaria que a solução estivesse em "casa"
> > mesmo
> > > e não num produto externo (mais jars, mais configuracoes, mais erros,
> > > etc.etc.). Será que há alguma previsão para melhorar a integração da EL
> > do
> > > JSP com a do JSF nas versões futuras das APIs?
>
> > > Fred
>
> > > > 2008/2/8 Frederico Guedes Pereira <fredguedespere...@gmail.com>:
Frederico Guedes Pereira
Eu vou fuçar, até porque isso faz parte do carma da nossa profissão. Mas eu fico com o pé atrás quando você diz que "só com JSF é ruim de fazer". O que eu vejo é que cada vez mais temos que colocar mais uma camada para "facilitar as coisas" e elas só estão piorando e so tornando cada vez mais complicadas de integrar. Daqui a pouco inventam um treco chamado "Flubb", um framework para facilitar o Seam + facelets + DAOs + EJBs; e depois o "Dendho" que é outro framework para facilitar o uso do Flubb. E a gente só FlubbDendho as aplicações para ficar na crista de onda...
Valeu!
Fred
Maurício Linhares
purinho, do jeito que vem da "loja" é praticamente inútil, qualquer
coisa além do trivial, você tem que escrever um monte de código de
"encanação", um caso clássico é usar selects HTML, tipo quando uma
notícia tem uma categoria, que vem de uma coleção de categorias.
O framework é tão genérico, mas tão genérico, que pra resolver esse
caso simples eu preciso, pelo menos, implementar um converter pra
minha classe de domínio, carregar essa coleção em uma propriedade de
um managed bean e referenciar ela lá no <f:selectItems/>, já que eu
não posso colocar ela relacionada diretamente com o próprio select
(diferente do que eu faria com um DataTable, por exemplo, a própria
API não é unificada, não existe um "jeito" jsf de ser). Se você pega
um ASP.NET da vida, tudo é igual, todos os componentes visuais se
ligam a propriedades dos objetos ou a datasources, e são "preenchidos"
com esses dados, em JSF cada componente costuma defivir o seu próprio
jeito de carregar os dados, o seu próprio modelo, complicando ainda
mais a vida do usuário.
Pra complicar ainda mais, coisas básicas como callbacks pra eventos
que estão acontecendo durante o ciclo de vida de um managed bean são
simplesmente inexistentes, você não sabe quando o managed bean está
criado e vai começar a responder a uma requisição, não sabe quando
acabou a requisição dele, não sabe se é a primeira vez ou a milésima
que o cliente está requisitando esse mesmo managed bean, fato esse que
chega a ser abominável pra um framework que deveria ser baseado em
componentes, a própria página não é um componente (mais uma vez,
diferente do ASP.NET, onde a página é um componente e você preenche a
página em vez de managed beans que são da página mas não parecem ter
relacionamento nenhum com ela).
JSF, pra mim, é mais uma prova de que "design by commitee", com um
monte de gente que não escreve aplicações metendo o bedelho e querendo
fazer a coisa genérica demais, só dá em merda. A coisa era tão absurda
que o próprio Craig McTãnãnã (não vou caçar o nome dele, é fácil de
vocês acharem) que foi o criador do Struts e era uma das mentes por
trás do JSF foi uma das primeiras pessoas a anunciar um framework pra
simplificar o desenvolvimento de aplicações JSF, o Struts Shale. Se
ele sabia quais eram os problemas que o JSF tinha e ele era um dos
chefões, por que ele não resolveu o problema na raiz em vez de criar
mais um framework pra atrapalhar a vida dos desenvolvedores?
Desde que eu fiz o meu primeiro sistema pra web em Java (na época era
um site de notícias pra empresa aonde eu estagiava) eu precisava de
uma ferramenta de templates pra homogeneizar a aparência do site que
eu estava fazendo (aquela coisa de ter um cabeçalho padrão, ter
rodapés padrão) e eu achava includes do JSP um modo terrívelmente
grosseiro de resolver o problema, já que mesmo com os includes eu
ainda repetia um bocado de código. Na época, pra resolver o problema,
eu usei a engine de templates do Struts, o Tiles, não me deu trabalho,
as páginas funcionavam exatamente do jeito que eu queria. Um tempo
depois eu precisei fazer uma atualização no sistema e achei que talves
fosse a hora de usar JSF pra aprender mesmo, quando comecie a
pesquisar, vi que JSF não tinha nada parecido com o Tiles, o que era
um absurdo, pois o mínimo que se esperava de um framework de
desenvolvimento web baseado em componentes era que ele resolvesse o
básico dos problemas e o uso de templates padrão é praticamente regra
em qualquer aplicação web, tive então que ficar usando JSP com Tiles
por muito tempo.
Mas sem me alongar muito, JSF puro e simples é sofrível, um retrocesso
em frameworks web em Java (e criar componentes é tão complicado que
existem frameworks pra criar componentes em JSF!), com Facelets e o
Seam ele já se torna útil pra fazer telas de cadastro de listagem, mas
mesmo assim o modo de redenrização complica demais a sua vida quando
você quer mexer com coisas mais avançadas com JavaScript (como usar
Ajax) ou interagir com outros tipos de apresentação, como Flash. Eles
queriam criar uma soluão genérica demais, terminaram criando o
framework web Java mais "específico" de todos.
PS: E antes que eu me esqueça, usar POST pra TUDO também é uma das
piores "qualidades" do JSF, porque isso é, pura e simplesmente,
estraçalhar com tudo o que foi feito com o protocolo HTTP desde o
surgimento da internet.
2008/2/9 Frederico Guedes Pereira <fredgued...@gmail.com>:
> Maurício,
>
> Eu vou fuçar, até porque isso faz parte do carma da nossa profissão. Mas eu
> fico com o pé atrás quando você diz que "só com JSF é ruim de fazer". O que
> eu vejo é que cada vez mais temos que colocar mais uma camada para
> "facilitar as coisas" e elas só estão piorando e so tornando cada vez mais
> complicadas de integrar. Daqui a pouco inventam um treco chamado "Flubb", um
> framework para facilitar o Seam + facelets + DAOs + EJBs; e depois o
> "Dendho" que é outro framework para facilitar o uso do Flubb. E a gente só
> FlubbDendho as aplicações para ficar na crista de onda...
>
> Valeu!
> Fred
--
Maurício Linhares
http://alinhavado.wordpress.com/ (pt-br) |
http://codeshooter.wordpress.com/ (en)
João Pessoa, PB, (83) 8867-7208
Frederico Guedes Pereira
Agora sim você disse tudo que eu queria ouvir! Concordo plenamente quando você diz que não ter um "Tiles JSF" nativo foi uma grande falha da especificação JSF. Realmente, era isso que eu tava comentando aqui com o pessoal. O lance dos componentes de selecao (selects) também é ridículo, concordo também. Por essas e outras é que as tecnologias Java para Web têm me decepcionado. E aí fica a pergunta, se Java no cliente (Applets) não colou, se Java enterprise mudou porque era dificil demais (será que agora ficou mais fácil?), se Java para web peca em coisas ridiculamente básicas, o que sobra da tecnologia? Está com cheiro de um Cobolzão do século 21...
Fred
Maurício Linhares
As tecnologias web apenas seguem a cultura burocrática que foi criada
ao redor da linguagem e da plataforma. Tudo em java tem que ser
"genérico", "flexível", parece que ninguém nunca se deu ao trabalho de
pesar se era realmente necessário tanta genericidade ou flexibilidade.
E eu acho que isso não acaba porque toda essa enrolação é um prato
cheio pra os famigerados "arquitetos" de software, que adoram repetir
siglas e conversar bullshitagem pras pobres víti.. ops, clientes =P
Um dia alguém há de perceber que jogar tanto dinheiro no lixo não é
uma boa idéia =D
2008/2/11 Frederico Guedes Pereira <fredgued...@gmail.com>:
> Opa, Maurício,
>
> Agora sim você disse tudo que eu queria ouvir! Concordo plenamente quando
> você diz que não ter um "Tiles JSF" nativo foi uma grande falha da
> especificação JSF. Realmente, era isso que eu tava comentando aqui com o
> pessoal. O lance dos componentes de selecao (selects) também é ridículo,
> concordo também. Por essas e outras é que as tecnologias Java para Web têm
> me decepcionado. E aí fica a pergunta, se Java no cliente (Applets) não
> colou, se Java enterprise mudou porque era dificil demais (será que agora
> ficou mais fácil?), se Java para web peca em coisas ridiculamente básicas, o
> que sobra da tecnologia? Está com cheiro de um Cobolzão do século 21...
>
> Fred
--