[Conclusão Resolvida]Por que as pessoa não indicam JSF e falam que é u LIXO?

Front-end
#61

O projeto de migração foi abortado depois de 5 meses com 3 programadores.
Precisavamos muita interação ajax, e com o JSF o sistema começou a ficar muito lento nas principais telas, e nada podíamos fazer para os responses fossem mais leves ou algo assim.
O sistema é este: http://www.lemontech.com.br/index.php?pg=interno&id=selfbooking
Resumindo, não deu certo.

Com o Menta, customizamos os responses com JSON, colocamos nas chaves apenas uma letras etc, para diminuir o overhead das informações, e depois disso compactamos as respostas.

#62

ao meu ver o jsf melhorou bastante a partir da versao 2…
Mas as vezes acho que o jsf é uma tecnologia meio que forçada pra java web.
acho mto dificil alguem q desenvolva com jsf nunca ter ficado dias tentando resolver algum problema, que em outras tecnologias e linguagens seria super fácil de se resolver.
Enfim, é muito burocrático!

Mas apesar de tudo, ele tem qualidade. Com MUITA força de vontade e reza brava vc consegue se virar…

#63

[quote=robertwgil][quote=saoj]
EDIT: O Robert da equipe do Mentawai fez um sistema sinistro de reserva de passagens online com Mentawai e depois migrou para JSF. O que ele fala é muito interessante… Lembre-se que um sistema de reserva de passagens tem formulários pra caramba e vc pode se dar bem usando um component-based approach.
[/quote]
O projeto de migração foi abortado depois de 5 meses com 3 programadores.
Precisavamos muita interação ajax, e com o JSF o sistema começou a ficar muito lento nas principais telas, e nada podíamos fazer para os responses fossem mais leves ou algo assim.
O sistema é este: http://www.lemontech.com.br/index.php?pg=interno&id=selfbooking
Resumindo, não deu certo.

Com o Menta, customizamos os responses com JSON, colocamos nas chaves apenas uma letras etc, para diminuir o overhead das informações, e depois disso compactamos as respostas.[/quote]

Eu trabalhei com o Robert nesse projeto de migração e também vou dar minha opinião.

Não existe o bom e o ruim, existe o melhor para cada situação.

Tínhamos um problema pontual na tela de consulta de voos. Essa tela precisava trabalhar com um grande volume de dados, nesse caso tínhamos que ter controle do html gerado e ai esta o X da questão.

Seu sistema precisa manipular o HTML, CSS e etc que é gerado pelo JSF? Então não use JSF.

No sistema em que eu e o Robert trabalhamos poderíamos ter feito a parte consulta de voos com RestFul passando por fora de todo o ciclo de vida do JSF, assim eliminaríamos o problema citado. O resto do sistema era todo CRUD e para isso o JSF é muito bom.

Infelizmente por uma decisão de empresa o projeto foi abandonado, e isso não tem haver com a tecnologia que foi utilizada mais sim com uma ?estratégia de empresa?.

Um ponto interessante é:
O melhor na grande maioria das vezes é o que você conhece bem.

#64

[quote=saoj]…
JSF é muito amarrado e burocrático. Usá-lo para um sistema web cheio de formulários e cheio de Ajax até pode se justificar.
…
Lembre-se que um sistema de reserva de passagens tem formulários pra caramba e vc pode se dar bem usando um component-based approach.
…
[/quote]

Prezado saoj, se me permite citar esses dois trechos pontuais do seu post, com todo o respeito, não concordo muito com essa visão. Você parece concordar com outros colegas do fórum que o JSF presta “apenas” para formularios, CRUDS, etc. Sinceramente, para qualquer tipo de funcionalidade que se queira na aplicação, não vejo nenhum impeditivo em usar JSF. Afinal, existem bibliotecas de componentes para trocentas funcionalidades diferentes, e sempre se pode utilizar unicamente HTML e CSS, assim como com o JSP. Com o perdão da ignorância, não compreendo direito essa crítica da comunidade, de que o JSF só presta pra formularios basicos, o resto “não dá pra fazer”. Com todo o respeito à sua opinião.

O que me leva ao ponto que o colega oliveira.caio comentou:

Prezado oliveira.caio, por gentileza, se puder pode detalhar melhor a dificuldade nesse detalhe? Trabalho com o JSF fazendo o HTML manualmente, manipulando o DOM, construindo o CSS, como eu faria uma página com qualquer outro framework, e não enxergo essa dificuldade. Ademais, as tags previstas na especificação renderizam tags basicas do HTML (input, button, a, select, e outras) e não geram nenhum CSS nem Javascript.

Concordo em absoluto. :wink:

Obrigado.

#65

Caro Alias. Vc pode discordar de tudo que eu falei. Sem problemas. Principalmente porque em matéria de JSF entendo pouco e estou baseando minha opinião no que escuto por aí e nos diversos exemplos que já vi. Claro que JSF3 vai ser melhor que JSF2 que vai ser melhor que JSF1. Muitas vezes jogam a coisa inteira fora e recomecam do zero. Struts1 não existe mais, foi descontinuado e abandonado para usarem o Struts2 (WebWork). EJB1 foi para o museu como um caso magnifiíco de uma expecificacao das melhores cabecas da industria que simplesmente fracassou com todas as forcas. Quando muita gente se junta para dar pitaco, geralmente sai caca, mas essa é a minha opinião pessoal. As melhores coisas são geralmente feitas por UMA cabeca seguindo UM principio correspondente a SUA conviccao, que obviamente não pode ser a de todos. Olhando a história parece que isso acontece mais vezes que o oposto.

Quando eu falo que meu carro é rápido, essa afirmacao é totalmente vazia. Como sabemos, tudo depende de um referencial.

Então vc pode achar JSF maravilhoso assim como eu posso achar o meu carro super rápido, cometendo o erro de ignorar o referencial.

Dizer que JSF é menos burocrático e enrolado do que Mentawai, Play, Ruby on Rails, Stripes, etc. me parece loucura porque esses frameworks abracaram desde o início (DESDE DA versão 0.1.1) o conceito KISS.

Posso estar errado e se for esse o caso por favor clareia minhas idéias para que eu possa aprender mais.

component-based é mais indicado quando vc tem vários formulários e muito AJAX/JavaScript no client side para ligar e reaproveitar tudo. Ao invés de codificar um caminhão de JavaScript no client-side (penoso) faća a coisa no server-side usando componentes.

action-based é mais próximo do mundo web / HTTP. Do MVC clássico. Do request-response paradigm, etc.

Um site de reservas online é um SISTEMA complexo. Ele é muito diferente por exemplo do que um site de relacionamentos, um JForum, etc. Quantos CRUDS vc tem no JForum? E num site de reservas? Já pensou na administracao disso? Na quantidade de telas e formulários? Por que o Robert que é um baita desenvolvedor (um dos mais pragmáticos que já vi) decidiu se aventurar migrando tudo para JSF?

Eu realmente sou suspeito para falar, pois tenho bastante experiencia com action-based e muito pouca com component-based.

Alguém que trabalhou nos dois mundos poderia opiniar. O Robert é um deles. O que eu posso falar é que fazer o simples com JSF é tortura. E isso filosoficamente é algo que não tolero. Outros toleram e até gostam. E viva a diversidade. Eu sou burro e preguicoso para complexidade por isso gosto das coisas simples. Em algo que suporta abstracao (OOP) complexidade é quase sempre um ERRO. Já conheci os dois mundos: sistemas super complexos feitos de forma simples e sistemas muito complexos feitos de forma complexa. Para o cara que nunca viu o simples, o complexo é simples, esse é o problema. :expressionless:

#66

Struts 2? Spring? VRaptor? Xml (a lot) acabou há tempos…

Nunca se aventurou a nenhunzinho “Hello World”? Não tem injeção? (aqui não entendi muito o que quis dizer)
Sobre o javascript, qual seria a desvantagem em usá-lo para controlar as coisas no client?

Não trabalho full-time com JSF, mas já utilizei em algumas aplicações, já li bastante sobre e procurei entender o mecanismo e as ideias para poder tirar conclusões, enfim. Cheguei a conclusão (não só eu mas uma gama de comunidade) que ele foi concebido numa época em que recursos http eram escassos e imaturos. Vai ver por isso que a galera demora tanto pra soltar release de JSF…

Sério, não gosto de criticar algo sem conhecer nem testar. Mas já tentei colocar JSF em diversas soluções e nunca consegui ver vantagem, nem em app com uma penca de forms como o saoj comentou…por outro lado, talvez nunca tive capacidade de enxergar tais vantagens

#67

Prezado saoj, novamente respeitando muito sua opinião, interessante o que comentou sobre os paradigmas component/action base. O meu pensamento segue a linha que você citou. Apenas para constar, não pretendo defender apaixonadamente o JSF (minha experiencia maior é com a versão 1.2 com a qual já arranquei alguns cabelos), porém eu o vejo como uma excelente alternativa, embora respeite quem não goste.

Sobre o que disse, acrescento um raciocinio que pode soar absurdo mas ao menos é o que penso hoje com meu parco conhecimento. Tenho a opinião de que pode-se dizer que boa parte das interfaces web hoje “são” component-based, dado o seu nível de complexidade. Explicando: em uma página “rica”, usando livremente o termo, elementos específicos dessa página serão manipulados, carregados, descarregados, vão sumir, reaparecer com outra cor, etc. Vejo os elementos como componentes. A partir daí vem o meu pensamento que não há nada que não se faça no Mentawai ( :wink: ), no VRaptor, no SpringMVC, no Grails, que não se possa fazer com o JSF. Verdade, no JSF os elementos serão componentes também no lado do servidor, criando uma “web STATEFULL”, que foge do funcionamento do HTTP como você mencionou. Isso não me agrada no JSF. Mas gosto da abstração que isso proporciona, de enxergar os componentes do HTML como componentes de fato da aplicação. Como disse, dado o nível de complexidade das interfaces web existentes hoje, eu creio que essa abordagem se justifica. Suponho que isso foi mais ou menos o que voce disse, ao dizer que o JSF se justifica quando usado em interfaces muito complexas, estou correto?

Mas nem sempre (ou nunca?) isso é o que se quer. Daí vem os action-based, com uma abordagem diferente do JSF, e talvez mais adequada para outros cenários. Mas voltando ao meu pensamento, do qual se a aplicação/site for voltado para os “componentes” e sua interação, eu continuo achando o JSF uma excelente opção.

Obrigado.

#68

[quote=alias]Prezado saoj, novamente respeitando muito sua opinião, interessante o que comentou sobre os paradigmas component/action base. O meu pensamento segue a linha que você citou. Apenas para constar, não pretendo defender apaixonadamente o JSF (minha experiencia maior é com a versão 1.2 com a qual já arranquei alguns cabelos), porém eu o vejo como uma excelente alternativa, embora respeite quem não goste.

Sobre o que disse, acrescento um raciocinio que pode soar absurdo mas ao menos é o que penso hoje com meu parco conhecimento. Tenho a opinião de que pode-se dizer que boa parte das interfaces web hoje “são” component-based, dado o seu nível de complexidade. Explicando: em uma página “rica”, usando livremente o termo, elementos específicos dessa página serão manipulados, carregados, descarregados, vão sumir, reaparecer com outra cor, etc. Vejo os elementos como componentes. A partir daí vem o meu pensamento que não há nada que não se faça no Mentawai ( :wink: ), no VRaptor, no SpringMVC, no Grails, que não se possa fazer com o JSF. Verdade, no JSF os elementos serão componentes também no lado do servidor, criando uma “web STATEFULL”, que foge do funcionamento do HTTP como você mencionou. Isso não me agrada no JSF. Mas gosto da abstração que isso proporciona, de enxergar os componentes do HTML como componentes de fato da aplicação. Como disse, dado o nível de complexidade das interfaces web existentes hoje, eu creio que essa abordagem se justifica. Suponho que isso foi mais ou menos o que voce disse, ao dizer que o JSF se justifica quando usado em interfaces muito complexas, estou correto?

Mas nem sempre (ou nunca?) isso é o que se quer. Daí vem os action-based, com uma abordagem diferente do JSF, e talvez mais adequada para outros cenários. Mas voltando ao meu pensamento, do qual se a aplicação/site for voltado para os “componentes” e sua interação, eu continuo achando o JSF uma excelente opção.

Obrigado.[/quote]
muito interessante sua colocação!
percebi que você pesa mais o fato da orientação a componente.
mas por outro lado, não seria menos trabalhoso usar javascript/jquery/ajax de forma decente e correta, podendo ser beneficiado por tais manipulações dos elementos? (eu disse elemento, pois vejo elemento como elemento). É ruim usar JQuery?

não to querendo fazer você pensar como eu, apenas pretendo discutir alguns impedimentos/beneficios de uma ferramenta ou outra.

#69

Um coisa que percebi na prática é o seguinte: Hoje um site descente sem Ajax e sem uma interface minimamente rica fica complicado. Então vc sempre vai ter um quantidade excessiva e desorganizada de JQuery / JS / JQueryUI no client-side. JQuery é muito bom mas dá para comparar a organização de um código OO com a bagunca do JS no client-side? É mais ou menos comparar quando as pessoas programavam CGI com PERL estrutural no server-side. Então fica a minha dúvida: Como organizar a bagunca do JS no client-side sem abandonar o action-based em prol do component-based? Há soluções no meio do caminho para isso?

EDIT: Um exemplo prático: Olhem a quantidade de JS/JQuery/JQueryUI nessa página do Kawai Wiki: http://websvn.mentaframework.org/filedetails.php?repname=Kawai+Wiki&path=%2Ftrunk%2Fsrc%2Fmain%2Fwebapp%2Fshow_page.jsp

Como eu poderia ter organizado essa zona sem partir para o component-based?

#70

[quote=leandronsp]
muito interessante sua colocação!
percebi que você pesa mais o fato da orientação a componente.
mas por outro lado, não seria menos trabalhoso usar javascript/jquery/ajax de forma decente e correta, podendo ser beneficiado por tais manipulações dos elementos? (eu disse elemento, pois vejo elemento como elemento). É ruim usar JQuery?

não to querendo fazer você pensar como eu, apenas pretendo discutir alguns impedimentos/beneficios de uma ferramenta ou outra.[/quote]

Você tem razão, acho que eu tendo a por em alta conta a orientação a componente (embora muito me agrade a natureza stateless do HTTP). Mas como expliquei, da maneira como vejo os sites e apps web hoje, as páginas ricas são orientadas a componente, pois os elementos são tratados dessa forma. Na minha opinião, é claro :lol:

Interessante o ponto que voce levantou, e não vou discordar. Os próprios componentes que fazem a fama do JSF (PrimeFaces, RichFaces, SeiLáOQueFaces, etc), fazem uso pesado de MUITO Javascript. Portanto os componentes bonitos do Prime poderiam ter sido feitos (e o são por aí com certeza) em um cenario “não-JSF”, como você disse, apenas usando Javascript da maneira correta e adequada. Mas aí volto ao que disse, que a “componentização” da coisa traz uma abstração que eu acho interessante, no sentido de tratar aquele elemento como algo unico e especial na página, e que receberá um tratamento e um comportamento específico. Eu vejo que tratando os elementos dessa forma cada um deles ganha um significado no sentido de agregar alguma funcionalidade ou participar da interação na página. Eu penso que tratar um elemento da página com essa perspectiva é benéfico.

E eu tambem muito gosto do JQuery, hehe. Não aprecio muito trabalhar diretamente no Javascript, mas mesmo que nem fosse o caso, meu pensamento pende mais para o que escrevi acima, embora eu NÃO discorde do que escreveu. Nem eu tenho a esperança de convencer alguem que o que estou dizendo é o correto (se nem eu estou convencido que dirá convence-los :lol: ), eventualmente estarei completamente equivocado e certamente terei aprendido mais com os colegas do fórum.

Obrigado.

#71

[quote=saoj]EDIT: Um exemplo prático: Olhem a quantidade de JS/JQuery/JQueryUI nessa página do Kawai Wiki: http://websvn.mentaframework.org/filedetails.php?repname=Kawai+Wiki&path=%2Ftrunk%2Fsrc%2Fmain%2Fwebapp%2Fshow_page.jsp

Como eu poderia ter organizado essa zona sem partir para o component-based?[/quote]
Numa rapida olhada, poderia ter evitado algumas criações de elementos com strings puras usando o próprio jquery para isso, possibilitando refatorar para outras funções em outros arquivos específicos e modularizando também o script: $("<td /> ) .addClass(“myClass”)…e por aí vai
Poderia também ter abusado dos selectors do jquery, que numa aplicação com o script gigante, possibilita também a modularização. Assim evitaria códigos duplicados, appends multiplos e aquele monte de hash ( # ) espalhada pelo código.

Enfim, claro que não tem comparação OO com script. Mas utilizando bem os recursos que o jquery oferece, dá sim pra montar uma galeria de scripts bem modularizada e reusável.

#72

Pra 99% dos problemas que relatam do JSF, o que acontece é pura falta de informação. Todos os desenvolvedores de componente indicam nos manuais como modificar o css, layout, embutir javascript e etc. JSF 1 realmente era horrível porque era imaturo e não tinha passado pelo crivo dos usuários, mas hoje em dia o cenário é diferente.

#73

Muito curioso essas discussões na comunidade Java, como ontem postei aqui http://www.guj.com.br/java/222158-jsf-struts-2-ou-vraptor-3/2 não entendo pq no caso de vocês do Java existe essa valorização tão grande por framework baseado em componentes, onde no caso da comunidade .NET ocorre o inverso. Como o ASP.NET nasceu baseado em componentes, passei boa parte da vida fechado a esse mundo, depois que finalmente a Microsoft copiou o Struts 2 não voltei mais ao mundo dos componentes, onde deixo de ser refém de controles pro framework do lado servidor e tenho toda liberdade de usar de forma limpa um jquery ui, css, frameworks visuais de diagramação de formularios como o formee, e diversos plugins jquery, e meus jquerys controlando o que quiser, tudo de forma mais natural, sem precisar ficar se preocupando com muitos “segredos” ou intervenções do framework server ou componente pra fazer algo diferenciado no resultado pro lado client, além de termos melhor colaboração do designer. Como muitos falam “web não é desktop”, isso é verdade.

#74

Com todo o respeito, apesar de ambos serem component-based, não vejo mais nenhuma semelhança entre ASP.NET e o JSF. Ao que me lembro, o modelo do ASP.NET é de fato transformar a página em um “win-form”, onde os componentes são diretamente manipulados na classe que fica atras da pagina. Apesar de também ser possível, ninguém faz isso no JSF (não é nada legal e nunca vi uma dúvida aqui no fórum sobre como utilizar uma instancia de HtmlInputText ou coisas do genêro. Já no ASP.NET, bom, é só isso que você tem). E TUDO isso ai que voce comentou (jquery, css, e tal) podem perfeitamente ser utilizados com JSF.

As palavras acima dizem muita coisa. Nessa thread que o colega javaflex citou, há diversos outros colegas do fórum dizendo ser “impossível” usar javascript e css no JSF, e, com todo o respeito, creio ser pura falta de conhecimento. Uma coisa é não gostar, outra coisa é não conhecer.

#75

Com todo o respeito, apesar de ambos serem component-based, não vejo mais nenhuma semelhança entre ASP.NET e o JSF. Ao que me lembro, o modelo do ASP.NET é de fato transformar a página em um “win-form”, onde os componentes são diretamente manipulados na classe que fica atras da pagina. Apesar de também ser possível, ninguém faz isso no JSF (não é nada legal e nunca vi uma dúvida aqui no fórum sobre como utilizar uma instancia de HtmlInputText ou coisas do genêro. Já no ASP.NET, bom, é só isso que você tem). E TUDO isso ai que voce comentou (jquery, css, e tal) podem perfeitamente ser utilizados com JSF.

As palavras acima dizem muita coisa. Nessa thread que o colega javaflex citou, há diversos outros colegas do fórum dizendo ser “impossível” usar javascript e css no JSF, e, com todo o respeito, creio ser pura falta de conhecimento. Uma coisa é não gostar, outra coisa é não conhecer.[/quote]

Sim ele deixa fazer isso, mas dependendo do padrão de arquitetura utilizado isso não rola, MVP por exemplo. Não sou defensor de ASP.NET WebForm, sei que JSF é muito melhor, só foquei na questão component-based.

Não disse ser impossível, disse não ser natural. Sim, gosto conta muito também, era um saco ficar decorando várias propriedades de vários componentes que na verdade só são coisas intermediárias, onde a realidade acaba sendo os elementos HTML mesmo, melhor então concentrar num lugar só, onde for mais perto do resultado. Fora que é um lado que já está no sangue, independente da linguagem server, tendo apoio infinitamente maior de todas as comunidades de desenvolvimento web, não só Java.

Concordo que JSF atende bem sim, sistemas “estilo desktop” com telas iguais e sem o cliente pedindo ui diferenciadas ou complexas, complexidade que pode deixar as vantagens do JSF de lado.

#76

[quote=javaflex]
Concordo que JSF atende bem sim, sistemas “estilo desktop” com telas iguais e sem o cliente pedindo ui diferenciadas ou complexas, complexidade que pode deixar as vantagens do JSF de lado.[/quote]

Com todo o respeito, mas se com todos os diversos frameworks de componentes não der pra fazer uma “ui diferenciada e complexa” com JSF, bom…conforme discutido no tópico um cenario adequado para o paradigma component-based é justamente esse: páginas diferenciadas e complexas.

Os trocentos SeiLaOQueFaces da vida facilitam muito esse trabalho, mas se voce preferir fazer o seu javascript, com JSF é perfeitamente possível. É possível fazer qualquer tipo de página ou projeto com ele; basta avaliar se ele é adequado ao cenário ou não.

#77

[quote=alias][quote=javaflex]
Concordo que JSF atende bem sim, sistemas “estilo desktop” com telas iguais e sem o cliente pedindo ui diferenciadas ou complexas, complexidade que pode deixar as vantagens do JSF de lado.[/quote]

Com todo o respeito, mas se com todos os diversos frameworks de componentes não der pra fazer uma “ui diferenciada e complexa” com JSF, bom…conforme discutido no tópico um cenario adequado para o paradigma component-based é justamente esse: páginas diferenciadas e complexas.

Os trocentos SeiLaOQueFaces da vida facilitam muito esse trabalho, mas se voce preferir fazer o seu javascript, com JSF é perfeitamente possível. É possível fazer qualquer tipo de página ou projeto com ele; basta avaliar se ele é adequado ao cenário ou não.[/quote]
Não conheço os trocentos Faces, mas os poucos que conheço mantem a usabilidade desktop, ai sim JSF ganha. Entendi que é perfeitamente possível fazer algo personalizado, mas me tira uma dúvida, supondo que junto a um designer temos que fazer uma página de consulta tipo essa http://globoesporte.globo.com/futebol/libertadores/, que nem é muito complexa, mas tem uma interface gráfica personalizada, qual seria a vantagem de usar solução component-based? Teríamos que parar pra criar um componente server pra abstrair a solução jquery personalizada ou deixar de lado o componente que é o motivador do JSF?

#78

[quote=javaflex]
Não conheço os trocentos Faces, mas os poucos que conheço mantem a usabilidade desktop, ai sim JSF ganha. Entendi que é perfeitamente possível fazer algo personalizado, mas me tira uma dúvida, supondo que junto a um designer temos que fazer uma página de consulta tipo essa http://globoesporte.globo.com/futebol/libertadores/, que nem é muito complexa, mas tem uma interface gráfica personalizada, qual seria a vantagem de usar solução component-based? Teríamos que parar pra criar um componente server pra abstrair a solução jquery personalizada ou deixar de lado o componente que é o motivador do JSF?[/quote]

Suponho que o que voce chama de “usabilidade desktop” sejam os componentes dos frameworks (Rich, Prime, etc) que se assemelham a componentes de desktop? Se for o que quis dizer, entendo mas respeitosamente discordo, os componentes desses frameworks são apenas CSS e Javascript (na view), eles se parecem com componentes “desktop” como poderiam se parecer com qualquer outra coisa.

Eu particularmente, como disse antes, vejo valor em tratar os elementos da página como “componentes” individuais, cada qual com o seu comportamento. De qualquer forma, esses componentes são apenas taglibs…apenas passo os parametros e elas fazem o que fazem, seja lá o que for.

Algo que gosto no JSF é como os dados manipulados nesses componentes são atrelados ao servidor, atribuindo assim ao componente uma responsabilidade no funcionamento da página; o componente, em si, é apenas Javascript. Qualquer um desses componentes dos SeiLaOQueFaces poderiam ser feitos sem JSF. Mas uma coisa “boa” que vejo na especificação é que a partir dela foram gerados muitos desses frameworks; poderia fazer cada um desses componentes apenas com Javascript/Jquery/Prototype/Scriptaculous, mas eles estão aí, prontos.

A interação com o usuário pertence ao client-side, e isso não muda, sendo JSF ou sei lá o que. Com JSF podemos a partir do servidor parametrizar o comportamento do componente, mas penso que não deve sair disso; uma vez que o componente foi renderizado, ele faz com Javascript o que o mandamos fazer com os dados que mandamos pra ele. E só. No exemplo da página que voce citou, voce quer/precisa parametrizar esse componente de interação com o usuário e o estado desse componente a partir do servidor? Ou quer só enviar dados pra ele ler no client-side e deixar o Javascript se virar pro que ele tem que fazer lá, e caso necessite, ele volta ao servidor? Acho ambas as abordagens válidas. Entao o uso ou nao de JSF ou qualquer outra coisa vai do que voce quer fazer.

No fim das contas, como disse outro colega nesse tópico, “O melhor na grande maioria das vezes é o que você conhece bem.” :wink:

Obrigado.

#79

[quote=alias][quote=javaflex]
Não conheço os trocentos Faces, mas os poucos que conheço mantem a usabilidade desktop, ai sim JSF ganha. Entendi que é perfeitamente possível fazer algo personalizado, mas me tira uma dúvida, supondo que junto a um designer temos que fazer uma página de consulta tipo essa http://globoesporte.globo.com/futebol/libertadores/, que nem é muito complexa, mas tem uma interface gráfica personalizada, qual seria a vantagem de usar solução component-based? Teríamos que parar pra criar um componente server pra abstrair a solução jquery personalizada ou deixar de lado o componente que é o motivador do JSF?[/quote]

Suponho que o que voce chama de “usabilidade desktop” sejam os componentes dos frameworks (Rich, Prime, etc) que se assemelham a componentes de desktop? Se for o que quis dizer, entendo mas respeitosamente discordo, os componentes desses frameworks são apenas CSS e Javascript (na view), eles se parecem com componentes “desktop” como poderiam se parecer com qualquer outra coisa.

Eu particularmente, como disse antes, vejo valor em tratar os elementos da página como “componentes” individuais, cada qual com o seu comportamento. De qualquer forma, esses componentes são apenas taglibs…apenas passo os parametros e elas fazem o que fazem, seja lá o que for.

Algo que gosto no JSF é como os dados manipulados nesses componentes são atrelados ao servidor, atribuindo assim ao componente uma responsabilidade no funcionamento da página; o componente, em si, é apenas Javascript. Qualquer um desses componentes dos SeiLaOQueFaces poderiam ser feitos sem JSF. Mas uma coisa “boa” que vejo na especificação é que a partir dela foram gerados muitos desses frameworks; poderia fazer cada um desses componentes apenas com Javascript/Jquery/Prototype/Scriptaculous, mas eles estão aí, prontos.

A interação com o usuário pertence ao client-side, e isso não muda, sendo JSF ou sei lá o que. Com JSF podemos a partir do servidor parametrizar o comportamento do componente, mas penso que não deve sair disso; uma vez que o componente foi renderizado, ele faz com Javascript o que o mandamos fazer com os dados que mandamos pra ele. E só. No exemplo da página que voce citou, voce quer/precisa parametrizar esse componente de interação com o usuário e o estado desse componente a partir do servidor? Ou quer só enviar dados pra ele ler no client-side e deixar o Javascript se virar pro que ele tem que fazer lá, e caso necessite, ele volta ao servidor? Acho ambas as abordagens válidas. Entao o uso ou nao de JSF ou qualquer outra coisa vai do que voce quer fazer.

No fim das contas, como disse outro colega nesse tópico, “O melhor na grande maioria das vezes é o que você conhece bem.” :wink:

Obrigado.
[/quote]
Valeu, boa explicação. No caso do globoesporte seria HTML, jquery e css puros, com ajax calls conforme o usuário for clicando em mais detalhes.

#80

Desculpe, me expressei mal, dei a entender que voce quer desenvolver a tal pag ai do Globo Esporte quando na verdade você a citou como exemplo, correto? A não ser que de fato trabalhe na Globo :-o

Pois é, JS com ajax calls por demanda é uma abordagem minimalista que eu gosto. Hoje alguns componentes do PrimeFaces funcionam assim, mas enquanto ai eu imagino que o ajax seja direcionado para um serviço que retorne um JSON da vida para o Javascript e tal, no Prime (no JSF na verdade) a requisição iria para o managed bean. É esse tipo de detalhe que eu acho importante conhecer; component-based e action-based são paradigmas diferentes, é interessante conhecermos o que a plataforma nos oferece para termos como decidir o que é adequado. Ou no mínimo, termos os melhores argumentos pra xingarmos os frameworks que não gostamos :lol:

Obrigado.