Arquivo Discussoes de Programacao e Tecnologia Sou totalmente leigo em JSF e na última pesquisa aqui no GUJ apareceu muita gente usando.
Então deixo a pergunta, para entender quais são as vantagens e desvantagens de JSF.
[color=blue]Por que vc usuaria JSF ao invés de WebWork para desenvolvimento para Web ?[/color]
depende do tipo de aplicação …
aplicações que são praticamente só baseadas em formulários, JSF da um ganho de produtividade beem grande, agora um GUJ da vida, não vale a pena implementar usando JSF por exemplo …
pelo menos é a minha opinião baseada das experiências que eu tive com os dois …
O forte de JSF então seria os componentes/tags da camada view, para exibir/construir o HTML ?
acho que o forte é a programação orientada a eventos, ideal para formulários, similar a programação desktop …
mas os componentes de input, são muito bons,
se estiver usando o myfaces tem mais um monte para layout também (tipo tabbed pane, … )
o data table é beem interessante (pelo menos o extended do my faces, tem suporte pra ordenação, paginação, … )
a possibilidade e facilidade de criar componentes novos, incluindo adicionar componentes um dentro do outro via código java (não sei se expliquei ou só compliquei … ) 
como ponto fraco, acho que:
os formulários só utilizarem post
não ser exatamente intuitivo a maneira de pegar parametros via URL.
Ao meu ver, sim. A parte de view do JSF eh muito boa, e acho que havera uma grande contribuicao da comunidade com componentes, diferente do que aconteceu com o JavaBeans (o original). O projeto MyFaces da Apache eh um exemplo disso.
Mas por outro lado, a parte de controller do JSF nao eh muito amigavel para o programador que quer trabalhar com aquilo “na mao”. Nao podia ser diferente, jah que nao foi projetado pra ser utilizada assim. Por enquanto eh melhor pensar em algum tipo de integracao entre actions/webwork* + view/JSF, ou tentar se virar com a ferramentinha da Sun.
Eu prefiro o WebWork. Já tive algumas raivas com JSF que me deixaram bastante frustrado. Por exemplo:
[list]Eu não consigo por exemplo colocar um caption em uma datatable porque o JSF não suporta. Como os caras deixaram passar isso? Uma coisa tão básica? Tão simples? Uma obrigação do JSF, em minha opinião, seria gerar código HTML padronizado com o W3C e isso não acontece sempre.[/list]
[list]Fazer um combobox é tão complicado que até o struts ganha dele nesse caso. Eu teria que pegar a minha coleção de objetos que eu quero escolher no combobox e transformar em uma coleção de objetos ListItem (não lembro se é isso mesmo). Isso com o tempo encheu o meu saco… Criei um decorator para facilitar, mas mesmo assim! :shock: [/list]
[list]O problema que o urubatan falou, de o formulário só usar post.[/list]
[list]JSF abre portas para que os programadores façam aplicações web estilo SmartUI, que eu não simpatizo muito. Claro que isso aqui também depende do programador.[/list]
[list]O XML de configuração do JSF é uma das coisas mais confusas com as quais eu já trabalhei.[/list]
[list]Ter que fazer um navigation handler para poder implementar qualquer coisa muito diferente do feijão com arroz de envia formulário, mostra dados é complicado. O controller não é amigável, como disse o ZehOliveira.[/list]
Pontos positivos do JSF:
[list]Os projetos paralelos são legais. Existe um chamado facelets que facilita muito a programação e a “customização” de componentes. Vale a pena dar uma olhada.[/list]
[list]Os componentes de input realmente são bons.[/list]
[list]Para aplicações que são apenas front-end para bancos de dados, como o urubatan falou, certas coisas ficam bem fáceis. Pega os dados da tabela e joga em um datatable (sem caption :() que ele cuida de paginação, ordenação, etc. [/list]
Mas enfim, para mim, usar JSF não foi uma experiência tão interessante quanto usar WebWork, Tapestry, Mentawai, Wicket… Aliás, por falar em desenvolvimento Web, a próxima coisa que eu quero aprender é a usar o Spring WebFlow cooperando com SpringMVC ou Tapestry. Alguém já testou o WebFlow?
David, só algumas observações sobre as suas frustrações
Eu prefiro o WebWork. Já tive algumas raivas com JSF que me deixaram bastante frustrado. Por exemplo:[list]Eu não consigo por exemplo colocar um caption em uma datatable porque o JSF não suporta. Como os caras deixaram passar isso? Uma coisa tão básica? Tão simples? Uma obrigação do JSF, em minha opinião, seria gerar código HTML padronizado com o W3C e isso não acontece sempre.[/list] </blockquote> na verdade ele suporta, beem fácil, mas não muito intuitivo … é só dentro do h:datatable você colocar: <f:facet name=“title”> <h:outputText value=“Este é o caption da table”/> </f:facet>Realmente, isto é chato
isto se usar uma ferramenta pra editar ele resolve
tem plugin pro eclipse, e se tu usar o java studio creator tu não precisa nem ficar sabendo que ele existe, só vai mexer mesmo se for criar um componente novo …não quiz dizer frontent pra banos de dados, disse aplicações baseadas em formulários, existem um monte de aplicações voltadas a formulário que tem muita lógica de negócio …
Mas enfim, para mim, usar JSF não foi uma experiência tão interessante quanto usar WebWork, Tapestry, Mentawai, Wicket… Aliás, por falar em desenvolvimento Web, a próxima coisa que eu quero aprender é a usar o Spring WebFlow cooperando com SpringMVC ou Tapestry. Alguém já testou o WebFlow?
Bom saber… Depois eu vou dar uma testada. Mas eu juro a você que eu falei aquilo porque eu nunca vi isso em nenhum canto. Procurei no google, no JSF in Action, no Mastering JSF e no Core JSF (não são todos meus, peguei emprestado :D) e não encontrava. Desisti de procurar quando vi em certo lugar que isso estava para ser colocado na nova versão da especificação. Mas é bom saber que é possível!
<f:facet name=“title”>
<h:outputText value=“Este é o caption da table”/>
</f:facet>
Sorry. Realmente eu interpretei mal.
não quiz dizer frontent pra banos de dados, disse aplicações baseadas em formulários, existem um monte de aplicações voltadas a formulário que tem muita lógica de negócio …
Uma vantagem tremenda do JSF é fazer parte de uma especificação.
e isto responde os projetos secundários…
no ww agora tem o datepicker, editor WYSIWYG, tabbed pane, etc… isto nao é coisa que só a JSF pode fazer…
na verdade os caras nao inovaram nada. fizeram tudo que já existe. Agora é só a Sun dizer que existe um padrao para começar a aparecer projetinhos e empresas como IBM… Oracle, etc a dar suporte com IDE´s… lamentável.
Prefiro o WW. Faço uma action que não faz extends de ninguem e tem get/set. É lindo!. Chamo minha action de uma função “main” ou da web, tanto faz.
o fato de a JSF ter componentes visuais não é devido a ser um padrão? será que se a JSF não fosse padrão teria tanta aceitação? provavelmete não.
e tb nao gostei do xml deles ehehe.
e no WW agora tem o ActionMapper (estou fazendo um sistema inteiro sem o xwork.xml)… e o ajax no webwork integrado ao dojo toolkit ficou show de bola!
um colega meu foi trabalhar para a IBM a pouco tempo…
eles estão usando JSF…
meu colega conhecia somente o Sruts…
e está achando a JSF uma bela mer**… e estão tendo que customizar várias coisas …
resumindo: ele comparou com Struts e prefere o Struts.
sei lá, nunca fui muito a fundo na JSF, mas só de olhar já nao gostei… então eu tento estudar um pouquinho e gosto menos ainda…
é meio complicado demais não é?
É impressão minha ou JSF é mais para aplicações web do que sites?
Eu sinceramente não vejo a hora de HTML+HTTP virar passado para aplicações e achoi que JSF é algo que amarra mais ainda Java à esse mundinho onde uma linguagem de hipertexto serve para tudo…
Enfatizando algumas coisas que já foi dito e adicionando algumas opiniões.
A utilização de JSF deve ser levada em consideração quando um sistema tem como caracteristica muitas telas com formulários padrão, listagens , consultas padrão…
Alguns pontos positivos:
Componentização. Permitindo a utilização de componentes padrões ou extender e personalizar seus próprios componentes.
Com a padronização dos componentes UI, cada vez mais empresas e particulares tendem a desenvolver mais componentes, como exemplo:
http://myfaces.apache.org/sandbox/index.html
http://myfaces.apache.org/tomahawk/index.html
http://myfaces.apache.org/tobago/
ADF
http://developers.sun.com/prodtech/javatools/jscreator/learning/tutorials/2/about_components.html
Controle de estado dos componentes.
Exemplo: Manutenção dos dados entre uma requisição e outra.
Controle de renderização ou não do compomente. (Isto sem ifs na jsp).
Validação server-side e/ou cliente-side(ADF).
Utilização de Drag and Drop dos componentes. (ferramentas muito pessadas, tendem a evoluir)
Integração com outros frameworks. Ex. http://struts.apache.org/struts-faces/index.html
Como já foi dito, faz parte de uma JSR.
Managed Beans (“actions”) são controlados pelo framework JSF (Inversion of Control).
Ao contrario do que foi dito, na minha opinião, controller não deve nada a outros frameworks. Bem simples basta criar um JavaBean e configuar a navegação no XML.
Alguns pontos negativos:
Relativa perda de controle de HTML e javascripts que você queira adicionar em sua página.
Configurações em aquivos XML. (Sem uma boa ferramenta, se torna improdutivo)
Apesar do JSF não depender de ferramentas (IDE), sem uma boa ferramenta o desenvolvimento de torna improdutivo.
Complica o que deveria ser simples, como montagem de um combobox, listagem com radio
Não tão maduro quanto outros frameworks.
Pouco material /suporte disponível. (Sem comparado com outros frameworks)
um colega meu foi trabalhar para a IBM a pouco tempo…
eles estão usando JSF…
meu colega conhecia somente o Sruts…
e está achando a JSF uma bela mer**… e estão tendo que customizar várias coisas …
resumindo: ele comparou com Struts e prefere o Struts.
sei lá, nunca fui muito a fundo na JSF, mas só de olhar já nao gostei… então eu tento estudar um pouquinho e gosto menos ainda…
é meio complicado demais não é?
Não concordo com seu amigo…já trabalhei com Struts (trabalho ainda) e trabalho com JSF…
JSF é muito mais muito mais produtivo que Struts, sem contar e tem uma melhor arquitetura.
Concordo que só os compomentes padrão JSF, não são suficientes para a maioria dos casos, mas por isso que estão surgindo componentes de terceiros por aí…e criar um componente customizado não é tão dificil…
Complicado? Quando eu comecei trabalhar com struts também achava complicado…
Prefiro o WW. Faço uma action que não faz extends de ninguem e tem get/set. É lindo!. Chamo minha action de uma função “main” ou da web, tanto faz.
Os MBs (Managers Beans) também não estendem ninguém…
Agora quero saber? O que o xml do WW tem de melhor? hehehehe
Fala pessoal!
Atualmente estou usando o Spring para fazer o modelo e JSF para o meu View/Controller, tudo isso no JDeveloper utilizando os componentes UI do ADF.
A produtividade aumenta consideravelmente sem se perder o controle da arquitetura da aplicação, o que geralmente ocorre quando usamos wizards para “facilitar” o nosso trabalho.
Quem não conhece o JSF aconselho baixar o JDev 10.1.13 e começar fazendo este exemplo aqui http://www.oracle.com/technology/obe/obe1013jdev/jsfintro/jsfintro.htm.
Agora, quem estiver querendo fazer alguma coisa em JSF e estiver fazendo “na mão” aí realmente é bastante improdutivo para aplicações do mundo real.
Essa configuração de navigation do JSF parece coisa do diabo, eita diacho verboso e chato de fazer.
EJB2 viveu por muito tempo na espera de uma boa ferramenta. Não estou dizendo que JSF vai seguir o mesmo caminho, muito pelo contrário, acho que JSF vai dá certo. A questão é manter os olhos abertos para o fato de que uma tal ferramenta ainda não é realidade, é apenas uma promessa como foi a de EJB2.
É impressão minha ou JSF é mais para aplicações web do que sites?Eu sinceramente não vejo a hora de HTML+HTTP virar passado para aplicações e achoi que JSF é algo que amarra mais ainda Java à esse mundinho onde uma linguagem de hipertexto serve para tudo…
Concordo plenamente!
Penso que o HTML+HTTP já não atendem as necessidades para o desenvolvimento web atual e acabando complicando muito mais do que ajudando. Claro que os frameworks ajudam muito a contornar os problemas gerados pelo HTTP mas imaginem como seria bom se, por exemplo, tivéssemos um protocolo que tivesse controle de estado. Os frameworks ficariam muito mais focados no negócio do que em contornar os problemas de um protocolo que foi criado somente para a transferência de textos na web e que acabou sendo usado para outras finalidades.
Ao invés de surgir um framework por semana para “perfumar a me***”, penso que já estaria mais do que na hora de haver uma evolução a nível de protocolo. Isso sim facilitaria bastante!!
É impressão minha ou JSF é mais para aplicações web do que sites?Eu sinceramente não vejo a hora de HTML+HTTP virar passado para aplicações e achoi que JSF é algo que amarra mais ainda Java à esse mundinho onde uma linguagem de hipertexto serve para tudo…
Concordo plenamente!
Penso que o HTML+HTTP já não atendem as necessidades para o desenvolvimento web atual e acabando complicando muito mais do que ajudando. Claro que os frameworks ajudam muito a contornar os problemas gerados pelo HTTP mas imaginem como seria bom se, por exemplo, tivéssemos um protocolo que tivesse controle de estado. Os frameworks ficariam muito mais focados no negócio do que em contornar os problemas de um protocolo que foi criado somente para a transferência de textos na web e que acabou sendo usado para outras finalidades.
Ao invés de surgir um framework por semana para “perfumar a me***”, penso que já estaria mais do que na hora de haver uma evolução a nível de protocolo. Isso sim facilitaria bastante!!
Acho que então alguem esqueceu de avisar o Google q HTML+HTTP não atende as necessidades do desenvolvimento WEB atual.
É impressão minha ou JSF é mais para aplicações web do que sites?Eu sinceramente não vejo a hora de HTML+HTTP virar passado para aplicações e achoi que JSF é algo que amarra mais ainda Java à esse mundinho onde uma linguagem de hipertexto serve para tudo…
Concordo plenamente!
Penso que o HTML+HTTP já não atendem as necessidades para o desenvolvimento web atual e acabando complicando muito mais do que ajudando. Claro que os frameworks ajudam muito a contornar os problemas gerados pelo HTTP mas imaginem como seria bom se, por exemplo, tivéssemos um protocolo que tivesse controle de estado. Os frameworks ficariam muito mais focados no negócio do que em contornar os problemas de um protocolo que foi criado somente para a transferência de textos na web e que acabou sendo usado para outras finalidades.
Ao invés de surgir um framework por semana para “perfumar a me***”, penso que já estaria mais do que na hora de haver uma evolução a nível de protocolo. Isso sim facilitaria bastante!!
Acho que então alguem esqueceu de avisar o Google q HTML+HTTP não atende as necessidades do desenvolvimento WEB atual.
A questão não é a eficácia e sim a eficiência. 
É óbvio que conseguimos burlar as deficiências do HTTP mas o meu questionamento foi relativo a uma complexidade a mais gerada por essa “adaptação” do protocolo às necessidades atuais.
É impressão minha ou JSF é mais para aplicações web do que sites?Eu sinceramente não vejo a hora de HTML+HTTP virar passado para aplicações e achoi que JSF é algo que amarra mais ainda Java à esse mundinho onde uma linguagem de hipertexto serve para tudo…
Concordo plenamente!
Penso que o HTML+HTTP já não atendem as necessidades para o desenvolvimento web atual e acabando complicando muito mais do que ajudando. Claro que os frameworks ajudam muito a contornar os problemas gerados pelo HTTP mas imaginem como seria bom se, por exemplo, tivéssemos um protocolo que tivesse controle de estado. Os frameworks ficariam muito mais focados no negócio do que em contornar os problemas de um protocolo que foi criado somente para a transferência de textos na web e que acabou sendo usado para outras finalidades.
Ao invés de surgir um framework por semana para “perfumar a me***”, penso que já estaria mais do que na hora de haver uma evolução a nível de protocolo. Isso sim facilitaria bastante!!
Acho que então alguem esqueceu de avisar o Google q HTML+HTTP não atende as necessidades do desenvolvimento WEB atual.
A questão não é a eficácia e sim a eficiência.
É óbvio que conseguimos burlar as deficiências do HTTP mas o meu questionamento foi relativo a uma complexidade a mais gerada por essa “adaptação” do protocolo às necessidades atuais.
Mas ai basta entao alguem fazer esta adaptação e este alguem pode ser o JSF, que ai nao acredito + nesta falta de adaptação com o HTTP, alias, acredito muito no AJAX para acabar com este paradigma da deficiencia do HTTP.
Agora vc concluiu que o JSF é a melhor opção por que é uma especifiçação !!! Ok! É um direito seu. Eu discordo que esse deva ser o motivo para decidir qualquer coisa. Vide EJB.
As pessoas estão felizes programando com JSF ? Estão produtivas ? Os sistemas são fáceis de entender e manter depois de prontos ?
Se vc está trabalhando num projeto assim com JSF, parabéns !!! Mas vc me parece ser a minoria…
O que eu vejo por aí e projetos ridículos, confusos, perdidos, etc. Eu trabalhei 2 anos na Accenture. É realmente impressionante como muitas empresas pagam com prazer mais de 500 mil reais por projetos ridcularmente complicados e super-dimensionados. Não dá para vender algo simples por 500 mil reais, né?
As pessoas hojem estão programando com JSF pela mesma razão que estavam programando com EJB a 2 anos atrás. Alguém falou que é bom e poderoso, algumas empresas grandes estão apoiando e especificando, então vamos usar que deve ser bom mesmo. Deve ter muita empresa enteressada em vender RAD para JSF, do mesmo jeito que algumas ganharam dinheiro vendendo Application Servers a 30 mil dólares por processador (Weblogic !!!). E teve muito gerente esperto que pagou !!!
Acho que no final é tudo uma questão de gosto mesmo. Eu simplesmente não consigo entender porque uma aplicação web deve ser feita do jeito descrito aqui: http://www.exadel.com/tutorial/jsf/jsftutorial-kickstart.html
Tem gente que vai achar maravilhoso, produtivo, simples, prazeroso, etc.
Fazer o que, né ? Gosto não se discute. Cada um na sua. O que vai contar no final das contas, independentemente do framework que vc usar, é O PROJETO ESTÁ FEITO ? ESTÁ FUNCIONANDO BEM ? ESTÁ DANDO DINHEIRO ? ESTÁ FÁCIL DE ENTENDER, BEM DESACOPLADO E LIMPO ? VC FEZ EM 1 MES OU 1 ANO O PROJETO ?
Essas perguntas é que valem, e não qual framework que vc usou. Isso para o mundo real/empresarial.
Eu nunca aceitaria um emprego/projeto para usar EJB/JSF/STRUTS etc. No máximo Mentawai / WebWork / Rife. Vou estar fazendo um favor pra mim e para o empregador.
Eu tenho muito cuidado quando peço para alguém dar uma olhada no Mentawai. A proposta é: olha durante 30-60 minutos. Faça alguns testes. Se nesses 30-60 minutos vc não se encontrar, ficar perdido, não entender várias coisas então abandone o Mentawai e parta para outro framework.
Olha esse link aqui sobre IoC: http://forum.mentaframework.org/posts/list/193.page
Se vc não achar isso fácil de entender e usar, então eu não sei o que pode ser mais simples, prático e ágil. Se alguém souber então fala…
Quer fazer uma injeção de dependência de uma Connection em qualquer bean que precise de uma connection (não são poucos, userDAO, transaction, bookDAO, etc.) ??? Então coloca essa linha no seu ApplicationManager.java:
filter(new DIFilter("connection", Connection.class));
Só isso, uma linha e tudo que precisar de uma connection vai receber uma connection. Como é que se faz isso com JSF ou Struts ? Configura tudo no XML ??? Dependencia por dependencia ??? Ok. Gosto não se discute…
JSF, Struts, SpringMVC não… Rife, WebWork, Stripes, Mentawai. Sim !
Tapestry e Wicket são legais também, depois dá uma olhada.
JSF, Struts, SpringMVC não… Rife, WebWork, Stripes, Mentawai. Sim !
Tapestry tem uma das piores curvas de aprendizado que eu já vi. O conceito dele é excepcional mas não é fácil colocar ele pra rodar.
Ele fica longe do modelo de simplicidade procurado em frameworks web hoje em dia. Sem dúvidas, é muito melhor que o JSF -possui um ótimo modelo de componentes -, mas não é por isso que se torne simples de usar.
Tapestry tem uma das piores curvas de aprendizado que eu já vi. O conceito dele é excepcional mas não é fácil colocar ele pra rodar.
Do pouco que mexi com ele fiquei decepcionado com a falta de praticidade em alguns aspectos... pra fazer um simples combo por exemplo, com dados de uma lista de objetos (id e nome, p.ex.) - que parto.
Editado: depois o pessoal acha que Rails eh puro hype:
<select id="empresa_id_categoria" name="empresa[id_categoria]">
<option value=""></option>
<%= options_from_collection_for_select @categoria_list, "id", "nome", @empresa.id_categoria %>
</select>
OK, nao tem nada demais. Mas eh desse tipo de mentalidade que precisamos na infra-estrutura do Java. Os 20% dificeis tem que ser possiveis, concordo, mas os 80% triviais nao precisam tornar-se complexos por isso.
Marcio Kuchma
Editado: depois o pessoal acha que Rails eh puro hype:<select id="empresa_id_categoria" name="empresa[id_categoria]"> <option value=""></option> <%= options_from_collection_for_select @categoria_list, "id", "nome", @empresa.id_categoria %> </select>
Tem algo bem similar nas tags do WW2, por sinal - mas nada que se pareca com o suporte a Ajax ou o ActiveRecord.
No mentawai é assim:
<mtw:select name="empresa" list="empresas" emptyField="true" />
Empresas é um ListData que está no ListManager ou é uma Collection/Array que pode estar no onput da action.
E ele já se preocupa em marcar o valor certo se houve erro de validação do formulário (o valor vai voltar no input da action).
Como o RoR faz isso ?
Por que o pessoal do Tapestry não pode fazer algo assim também ? Talvez porque o foco do Tapestry seja poder e não simplicidade. Assim como C++ em relação a Java.
:roll:
Concordo que o Tapestry é um pouco complicado, mas eu acho ele bem legal. O Wicket (http://wicket.sourceforge.net/) é um framework bem semelhante ao Tapestry mas muito mais simples e sem XML.
(…) mas nada que se pareca com o suporte a Ajax (…)Nunca fiz nada que use AJAX com Rails, então é uma pergunta de ignorante mesmo: o suporte ao AJAX do Rails não é o oferecido pelo Prototype? Ou existe algo mais?
Empresas é um ListData que está no ListManager ou é uma Collection/Array que pode estar no onput da action.E ele já se preocupa em marcar o valor certo se houve erro de validação do formulário (o valor vai voltar no input da action).
Eu fiz uma tag semelhante a do menta, mas é uma tag de iteração. Dentro do corpo dela eu defino a forma do option.
Algo assim:
<my:select collection="lista" var="item" name="meuSelect">
<my:option value="${item.codigo}">${item.descricao}</my:option>
</my:select>
Acho até simples e é suficiente para 100% das minhas necessidades.
Um ListData possui ListDataItems, que são id (inteiro) + label (String).
ListData é interface, então vc pode ter várias implementações de acordo com suas necessidades. O mentawai já vem com BaseListData e SimpleListData. Algumas pessoas fizeram um DBListData e colocaram lá no forum do Mentawai.
Além de ListData a tag select suporta também maps. Falei besteira quando falei que suporta Collection e arrays, já que precisa de uma chave e um valor.
Se vc mete um Map no output ele vai chamar toString() da chave e toString() do valor para gerar a lista.
Uma coisa é lista estática que não muda nunca. Ex: Estados do Brasil. Isso deve estar no ListManager e ser carregado no startup.
Outra coisa é uma lista dinâmica que vc quer mostrar num combo box para o usuário. Ex: Meus amigos. Isso deve estar na sessão ou dentro do objeto do usuário e ser mostrado via output da action.
O legal do BaseListData é que ele já resolve vários problemas chatos pra vc, entre eles:
:arrow: Ordenação
:arrow: Internacionalização
:arrow: Reload automático quando vc muda o arquivo
Como RoR e JSF fazem isso ?
Então quer dizer que se eu tenho um java.util.List de usuarios, por exemplo, eu tenho que criar um ListData para encapsular a minha lista e passar esse listData para o output? Acho mais simples passar a List pro output e na view definir o que vai ser exibido, isto é, o que é chave, label e etc.
Algo como:
<my:combo collection="usuarios" valueProperty="codigo" labelProperty="login" ... />
(isso é tão intuitivo que já deve existir a rodo por aí nos frameworks)
A questão é que vc tem que usar alguma coisa como chave !!!
Geralmente vc não faz assim:
<option value=“Sergio Oliveira”>Sergio Oliveira</option>
Na grande maioria dos casos há um índice (id) para o valor.
Dá até para passar uma lista então, mas daí vou pegar o índice da lista como id do valor que ela contem.
Putz !!! Agora que eu entendi o teu esquema !!! Pô, excelente dica… O Mentawai papou mosca em relação a isso… 
(Mas vou fazer agora em 5 minutos… hehehehe)
Só não sei se é melhor do que ter um CollectionListData que vc faz assim:
ListData list = new CollectionListData(collection, "id", "name");
O CollectionListData viria junto com o framework.
Acho que sua maneira é mais simples mesmo… 
O Rails comecou usando Prototype pro suporte a Ajax, mas ja ta com bem mais features (RJS, Scriptaculous, etc). Recomendo dar uma olhada.
Só não sei se é melhor do que ter um CollectionListData que vc faz assim:Certo, você está decorando uma coleção para servir o componente de tela, legal, ficou bacana, e esse 'id' e 'name' seriam atributos da classe que está na coleção né isso ? e eu quisesse colocar como atributo um campo que está em outro objeto , tipo pais.estado.id ??, a mesma coisa pro name, pais.estado.uf ?ListData list = new CollectionListData(collection, "id", "name");
ListData list = new CollectionListData(collection, "pais.estado.id", "pais.estado.uf");
seria assim ?
Pô, um país vai ter N estados e não um só…
Acho que usar o tag pra fazer isso também é uma boa…
Vou tentar matar dois coelhos com um código só…
A tag vai usar internamente o CollectionListData. E vc pode passar por fora um CollectionListData tb…
Pô, um país vai ter N estados e não um só…Acho que usar o tag pra fazer isso também é uma boa…
Vou tentar matar dois coelhos com um código só…
A tag vai usar internamente o CollectionListData. E vc pode passar por fora um CollectionListData tb…
Dá pra fazer isso. Todas as tags do mentawai suportam isso. Como expression language…
Em vez do programador fazer isso, porque não dizer pra própria tag qual é o nome da propriedade “id” e qual é o nome da propriedade “label”?
É o que eu tou tentando dizer!!! :?
O controller não deveria saber o que é impresso na tela, só importa pra ele levar uma lista qualquer pro output. A decisão do que vai ser mostrado (id, nome, login, etc…) é da view, isto é, da tag.
Acho que esse ListData é amarrar demais, eu prefiro trabalhar com a abordagem que citei acima: uso java.util.List e digo na tag quais propriedades do objeto serão mostradas e onde.
Pois é, eu mesmo fiz umas tags que geram um select assim. Não vejo porque usar esses “listModels”.
Eu acho essa opcao ideal.
Bacana a discussao pessoal, mas nao quis focar neste exemplo apenas, afinal, foi apenas um exemplo.
Mentalidade, estilo, sensacao. Sei la. Mas no Rails voce esbarra num problema, vai na documentacao e, tcha-ran, os caras pensaram nisso (estou ficando mal-acostumado :)). Tenha a impressao de que o Rails reflete muito bem o lema “feito por desenvolvedores para desenvolvedores” (ate mesmo porque ele foi inicialmente extraido de uma aplicacao real).
Ja com frameworks web Java voce, as vezes, parece que esta lutando contra ele e nao que ele esta ao teu lado, como deveria ser. O que me lembra, nao sei porque, o “The Mythical Man Month”.
Marcio Kuchma
Ja com frameworks web Java voce, as vezes, parece que esta lutando contra ele e nao que ele esta ao teu lado, como deveria ser.Não acho que isso seja válido para todos os frameworks, mas essa sua frase descreve perfeitamente o que eu sinto com relação a Java Server Faces (e não preciso mencionar Struts, né?).
Nenhum framework vai ter todas as features desejadas por 100% dos programadores e necessárias para 100% dos projetos.
Pra isso que existe novas versões e pra isso que o framework precisa ser bastante flexível.
Exato. Pensei exatamente nisso quando coloquei “as vezes”. Nao estou desclassificando todos os frameworks Java.
Conforme o Sergio disse, possivelmente nenhum tera 100% do que 100% dos projetos precisam. Mas os 80% basicos dos 80% de projetos “comuns” que vemos por ai deveriam poder ser feitos com o pe nas costas. Afinal, se nao for isso pra que usar framework?
Marcio Kuchma
Java Server Faces é uma forma do Mundo JAVA ficar mais perto de um ideal Microsoft, porque cria dificuldades para vender facilidades. Muita gente repete por ai que JSF é mais produtivo, infelizmente repete quase que como um papagaio ou leitor fiel de revista JAVA. Porque sabe dizer que é mais produtivo mas não sabe explicar em que momento o desenvolvimento torna-se realmente produtivo.
Nem sempre a escolha de uma tecnologia é acompanhada de um balanceamento justo, ponderando as vantagens e as desvantagens, é o que acontece com Java Server faces, ganha-se muito pouco na camada de apresentação se contar todo o resto que é perdido em função deste Framework. Na verdade, como pode ser uma boa solução se é necessário muitos outros penduricalhos até se tornar utilizável? Qual é a diferença disso para uma solução incompleta?
JSF teoricamente também permite customização de tags, que neste caso tiveram o conceito entortado para componente, mas JSP também permite. O problema é FAZER uma custom tag em Faces, a complexidade é enorme, e mesmo quando consegue, uma custom tag necessariamente precisa ser extendida de um componente padrão, engessando do mesmo jeito a solução.
De longo prazo, uma solução Faces assume uma complexidade muito maior que qualquer outra solução ActionBasic. Este argumento de que existe produtividade nas telas de cadastro é uma grande mentira. E mesmo assim só acontece em cadastro sem qualquer complexidade, como por exemplo cadastro de bairro ou de cidade. Qualquer outra coisa faz o fonte virar, rapidamente, uma verdadeira mugueia.
O Seam é a única forma decente de se trabalhar com JSF. Uma solução free por quanto tempo? Boa parte dos muitos recursos para fazer esta massaroca funcionar não está mais na mão do mundo OpenSource. JBoss Tools, Rich Faces. Amostra grátis todo mundo gosta, no início é uma maravilha, tudo dá certo. O problema é que um dia termina. De uma hora pra outra a Red Hat acaba de vez com essa festa.
JSF é uma prova que nada mudou na cultura do desenvolvimento de sistemas. Desde de que o homem pisou na terra que a sua única proposta é desenvolver sistemas que permitem manutenção somente por ele mesmo. A conta é simples, se apenas um programador consegue entender esse macarrão então o seu emprego ficará eternamente salvo. Mais importante que fazer um sistema funcional é fazer um sistema que somente uma pequena fatia de programadores saibam mante-lo.
JSF é modinha, é venda de revista. Se algum dia cair em domínio público, certamente irão inventar outra coisa, afinal de contas o bom mesmo é aquilo que só um conhece, que só um pode mexer, porque ganha mais dinheiro. Uma visão egoísta e mesquinha. Aliás, uma visão bastante coerente com o trabalho em equipe. Eu faço o cadastro, você faz o resto!
Baseado em componentes visuais o JSF se torna a solução ideal para desenvolvimento de aplicações para a web com muitas vantagens:
configuração simples.
mapeamento dos beans através de anotation (2.0).
utilização do faces-config opcional.
estável.
regras de navegação simplificadas.
integração com outras bibliotecas de componentes, como por exemplo: RichFaces, PrimeFaces, IceFaces.
suportado pelos principais servidores de aplicação.