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

[leandronsp]

Já trabalhei com Struts 1.x. Eu não gostava dos formulários e do monte de xml. Não sei como está a versão 2, mas não vejo ela sendo muito solicitada no mercado.

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

Já li sobre VRaptor e sempre pergunto sobre ele a um amigo que gosta desse framework. Até então, gostei do que vi. O que eu não gostei muito é da parte de que não tem injeção e você tem que controlar o javascript por fora (isso pode ser vantagem ou desvantagem).

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

[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 ( ), 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.

[leandronsp]

[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 ( ), 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.

[saoj]

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?

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?

[alias]

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

[leandronsp]

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

[fabiocsilva]

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.

[javaflex]

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.

[alias]

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.

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.

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.

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.

[javaflex]

[quote=javaflex]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.

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.

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.

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]

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

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.

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.

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.

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

[javaflex]

[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?

[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.”

Obrigado.

[javaflex]

[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.”

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.

[alias]

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.

[javaflex]

[quote=alias]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.[/quote]
Foi exemplo sim, pra saber ql a vantagem de usar solucao component-based num caso desse, com uma grid bastante dinamica e personalizada sem ter pego nada pronto, ou seja sistemas com interface grafica diferenciada para melhor usabilidade.

[ReinaldoVale]

Muito bom esse tópico. Inicialmente achei que seria mais um daqueles inflamados por argumentos vazios e fanáticos, porém o que estou vendo é uma discussão de alto nível.
Agora voltando ao tópico…

Normalmente, em uma aplicação de “verdade” temos a integração de várias tecnologias e modelos de desenvolvimento. O JSF, componet-based, além das vantagens já citadas,
eu reforço o fato dele fazer parte do JEE6, nesse sentido, penso que JEE6 ficou devendo uma alternativa action-based, nada que SpringMVC, VReptor etc não resolva.
Por outro lado, não vejo nada que inviabilize a cooperação dos dois modelos, por exemplo: JSF para necessidade componet-based e JAX-RS + (JS-extensions ou componentes JSF especializados) para o action-based.

–
Rei

[raf4ever]

[quote=alias]
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]

Ora pois,mas se é pra deixar as facilidades do framework de lado e fazer tudo na mão é melhor nem usar,né não?

[alias]

[quote=ReinaldoVale]Muito bom esse tópico. Inicialmente achei que seria mais um daqueles inflamados por argumentos vazios e fanáticos, porém o que estou vendo é uma discussão de alto nível.
Agora voltando ao tópico…

Normalmente, em uma aplicação de “verdade” temos a integração de várias tecnologias e modelos de desenvolvimento. O JSF, componet-based, além das vantagens já citadas,
eu reforço o fato dele fazer parte do JEE6, nesse sentido, penso que JEE6 ficou devendo uma alternativa action-based, nada que SpringMVC, VReptor etc não resolva.
Por outro lado, não vejo nada que inviabilize a cooperação dos dois modelos, por exemplo: JSF para necessidade componet-based e JAX-RS + (JS-extensions ou componentes JSF especializados) para o action-based.

–
Rei

[/quote]

Eu concordo. Parece que a especificação, ao valorizar a evolução do JSF (pro bem ou pro mal hehe), meio que “largou” o JSP e a abordagem action-based, o que é uma pena. Claro que há excelentes alternativas como as que você citou, mas acho chato ver o JSP um tanto quanto “estacionado”.

[quote=raf4ever][quote=alias]
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]

Ora pois,mas se é pra deixar as facilidades do framework de lado e fazer tudo na mão é melhor nem usar,né não? [/quote]

Bom, na verdade eu concordo contigo, prezado colega , talvez eu tenha me expressado mal. O que quis argumentar é que é possível injetar algum comportamento via Javascript no JSF, ao contrário do que alguns colegas do fórum argumentaram aqui, que “não é possível” fazer customizações no client-side com JSF. É claro que, dada a vastidão de componentes existentes, provavelmente haverá algum que faz o que voce quer; mas se não, basta ajustar, ou criar um comportamento seu a partir de um elemento qualquer. Com JSF isso é tão possível quanto seria com qualquer outro framework.