[quote=FernandoFranzini][quote=mhjmhj2002]"ao mandar o estado para o client ganha-se em memória do servidor mas perde-se em volume de dados trafegados. "
desculpa mas não entendi essa parte, vc poderia explicar melhor?[/quote]
Leia - http://www.rponte.com.br/2007/10/14/state_saving_method-server-ou-client/[/quote]
Você sabe se existe na web algum comparativo mais detalhado ao respeito, tipo:
consumo de banda da rede / cliente(dados) x servidor(dados), e por ae vai…
[quote=mhjmhj2002][quote=FernandoFranzini][quote=mhjmhj2002]"ao mandar o estado para o client ganha-se em memória do servidor mas perde-se em volume de dados trafegados. "
desculpa mas não entendi essa parte, vc poderia explicar melhor?[/quote]
Leia - http://www.rponte.com.br/2007/10/14/state_saving_method-server-ou-client/[/quote]
Você sabe se existe na web algum comparativo mais detalhado ao respeito, tipo:
consumo de banda da rede / cliente(dados) x servidor(dados), e por ae vai…[/quote]
Não sei…mas sei 2 coisas
1-A solução tem que suportar a demanda atual de usuários simultâneos e estar preparado para atender qualquer pico extra.
2-Tempo de resposta máximo universal aceitável de uma requisição HTTP é até 6 segundos.
Com base nisso vc ja consegue decidir…
citei errado desculpem…
[quote=raf4ever][quote=lucasmurata]
E se se tornar necessário? Ou será que desenvolvimento de software é tão previsível que posso apontar e falar: “Vou usar esses X componentes visuais dessa biblioteca e me basta”?. Se teus requisitos, em questão de front-end, se adequa aos N componentes de uma biblioteca, tudo bem. É só torcer pro cliente nao pedir alteração ou customização em algum componente.
[/quote]
Nesse ponto eu me baseei mais na minha experiência msm,nunca tive(e não conheço quem teve) necessidade de criação de algum widget que a biblioteca que eu uso (no caso o RichFaces) não forneça.
Quanto a estilizar componentes e mexer em CSS ,esse é o único tradeoff que me incomoda,vc fica refém demais do que a ferramenta gera pra vc.[/quote]
bom vc acaba de conhecer um, trabalho numa empresa que usa zkoss, agora estão querendo um supervisório que tenha gráficos, áreas de texto e tals dentro do mapa do gmaps. o componente do zkoss para gmaps só atende até para desenhar poligonos e parou por ae. Agora tenho que achar um jeito de correr atrás do prejuizo…
[quote]Que ninguém se engane: só se consegue a simplicidade através de muito trabalho.Valeu JSF…
[/quote]
Eu não gosto do JSF porque ele é muito amarrado. Cara, uma das coisas mais básicas no desenvolvimento de software é a questão do ACOPLAMENTO. A visão é totalmente acoplada com o controlador. Cara, se você desenvolve um sistema utilizando VRaptor para implementar a camada de controle e jQuery na visão, e depois você se depara com um ExtJS e fica maravilhado com seus componentes (coisa que aconteceu comigo recentemente), você tem TODO O CONTROLE para substituir sua visão. Agora tenta fazer isso com JSF!!!
O principal motivo de não gostar do JSF é esse simples princípio de desenvolvimento (acoplamento), mas também porque ele deixa vazar muito da abstração que ele se propõe a fazer. Ter que escrever a navegação entre beans e visão no faces-config.xml (vi que foi corrigido na versão 2, mas era tão ruim na versão 1.2 que não tive saco pra conhecer a 2). Não gosto de frames component-based porque a WEB NÃO É DESKTOP. HTTP é requisição-resposta e, acima de tudo, STATELESS, uma de suas grandes vantagens.
Portanto, vale a pena você conhecer pra tirar suas prórpias conclusões, mas sugiro estudar melhor as tecnologias envolvidas numa aplicação web (http - tem gente que não sabe a diferença entre um forward e um redirect-, css, html, javascript, jsp, servlets) e aconselho fortemente a preferir frames action-based. Um que gosto muito é o VRaptor, não precisa configurar nada e é fácil integrar com qualquer outro framework…
eh por ae mesmo bob_sponja, eu trabalhei numa empresa que usava flex no front-end e web services no back-end, agora que o flex ta meio que indo pra ponte que caiu o pessoal lá está procurando uma alternativa no cliente, vc sabe quantas linhas de código vão precisar mexer no back-end? nem uma vírgula!
Pois é, o pessoal fica discutindo as funcionalidades, os componentes, o fato de ser uma especificação, mas se esquece dos princípios básicos de desenvolvimento. Como um frame tão acoplado pode ser bom?! E o engraçado é que esses que defendem falam que nós que criticamos somos os fanáticos!!! Será mesmo?! =)
mhjmhj2002, é bom ver histórias de quem se safou do uso do JSF pra mostrar pra esses “standard defenders” que nem sempre o fato de ser uma especificação é sinônimo de qualidade…
Não gosto de usar JSF (não estou dizendo que é lixo, ok?) pois prefiro algo “action-based” ao invés de “component-based”.
To programando web, sistemas complexos, requisitos que mudam, preciso sempre alterar regras no client, regras de SEO, flexibilidade para estilo da aplicação, comunicação assíncrona com o server, adaptações, mudar menus…na boa, já tentei solucionar uma pêra dessas com JSF e não vi vantagem alguma. Aí veio alguém e disse: mas você pode desligar isso, desligar aquilo, deixar pro container, e tudo mais. No final me vi programando desktop, com todo controle tirado do jsf, e pensei: WTH então estou usando JSF?
Crud pro mercado do Zé? “rails new mercadinho_do_ze”, obrigado.
Pensa assim:
Aplicacao web = poucos formularios
Sistema Web = muitos formularios
O problema bizarro é quando o cara pega JSF para fazer 1).
JSF é um lixo e só se justifica quando vc está fazendo o 2).
[quote=saoj]Pensa assim:
Aplicacao web = poucos formularios
Sistema Web = muitos formularios
O problema bizarro é quando o cara pega JSF para fazer 1).
JSF é um lixo e só se justifica quando vc está fazendo o 2).
[/quote]
Com todo o respeito, eu discordo. Não vejo nenhum problema em utilizar JSF para fazer uma aplicação web, como você citou, sejam com muitos ou poucos formulários, ou seja lá o que for.
O mais engraçado é ver pessoas falando mau do JSF se baseando apenas no JSF 1.2.
Enquanto nem para para ver como funcionam o 2.0.
Triste isso viu. =/
Todo mundo vê apenas os defeitos do JSF e colocam VRAPTOR como a bala de prata, a salvação, mas ninguém para para pensar que o próprio VRAPTOR tem seus defeitos e suas limitações. As vezes as pessoas vêem apenas aqui que elas querem ver.
Visão seletiva.
Não acho o JSF 2.0 a salvação do mundo, mas nunca seria louco de afirmar que é lixo. As pessoas devem perceber que para cada situação, existe uma ferramenta que é melhor aplicada.
Fala quem JSF é lento? o xhtml chega a ser 60% melhor em performance que o JSP. Mas para utilizar o xhtml as pessoas precisariam entender como funciona o JSF 2.0 e para isso, ninguém está disposto… Triste isso! =/
[quote=saoj]Pensa assim:
Aplicacao web = poucos formularios
Sistema Web = muitos formularios
O problema bizarro é quando o cara pega JSF para fazer 1).
JSF é um lixo e só se justifica quando vc está fazendo o 2).
[/quote]
Bom,essa eu queria entender,pois uso o JSF no caso ‘1’ e sempre rolou muito bem,obrigado.
[quote=jakefrog]O mais engraçado é ver pessoas falando mau do JSF se baseando apenas no JSF 1.2.
Enquanto nem para para ver como funcionam o 2.0.
Triste isso viu. =/
Todo mundo vê apenas os defeitos do JSF e colocam VRAPTOR como a bala de prata, a salvação, mas ninguém para para pensar que o próprio VRAPTOR tem seus defeitos e suas limitações. As vezes as pessoas vêem apenas aqui que elas querem ver.
Visão seletiva.
Não acho o JSF 2.0 a salvação do mundo, mas nunca seria louco de afirmar que é lixo. As pessoas devem perceber que para cada situação, existe uma ferramenta que é melhor aplicada.
Fala quem JSF é lento? o xhtml chega a ser 60% melhor em performance que o JSP. Mas para utilizar o xhtml as pessoas precisariam entender como funciona o JSF 2.0 e para isso, ninguém está disposto… Triste isso! =/[/quote]
Velho, se vc quiser se referir a mim, por favor me cite ao invés de jogar ao vento que ALGUMAS PESSOA falam isso ou aquilo…
Em nenhum momento falei que o VRaptor é bala de prata, só frisei o quanto ele te proporciona de controle sobre seu projeto, coisa que o JSF não faz. Então não coloque palavras na minha boca… Outra coisa, o VRaptor têm suas limitações, claro, mas ele é BEM MAIS FÁCIL de ser estendido que o JSF, fora que já vem com um mecanismo nativo com suporte a injeção de dependência, e é MUITO, mas MUITO MESMO, fácil de se integrar com qualquer outra biblioteca ou framework… Além disso ele não exige que você tenha que aprender nova tags, compreender um ciclo de vida nada intuitivo para uma simples requisição e não incha o seu controlador com gets e sets (para pegar as propriedades dos ManagedBeans)… Ou seja, ele é muito mais simples de se usar e muito menos intrusivo do que o JSF.
Outra coisa, não tive saco pra conhecer a versão 2.0 pelo simples fato das coisas acontecerem muito devagar quando se trata do JSF… Quanto tempo eles demoraram pra sair da 1.2 pra 2.0?! Mesmo sabendo das inúmeros pontos negativos e das reclamações que existiam por parte da versão 1.2 demoraram uma eternidade… Então eu simplesmente não cultivo o pensamento “na próxima especificação eles vão corrigir isso”…
Já que você tá falando aí, me mostra como vc usa ExtJS com o JSF? Ou qualquer outra biblioteca javascript sem ter que contornar o JSF a todo tempo?! JSF surgiu quando essas tecnologias WEB (que fizeram surgir o termo WEB 2.0) não estavam tão desenvolvidas, maduras e possibilitando tanta interatividade na parte cliente… Hoje em dia não é necessário que a parte do servidor se ocupe em como renderizar as coisas no cliente, você tem trocentas opções para isso… Por isso não gosto do JSF, mas se você gosta, blza é opinião sua… Mas vc pelo menos se questionou o quanto de acoplamento ele te impõe? E vc acha isso bom? Como afirmei antes, depois nós que criticamos que somos os fanáticos e temos visão seletiva…
[quote=bob_sponja]
Velho, se vc quiser se referir a mim, por favor me cite ao invés de jogar ao vento que ALGUMAS PESSOA falam isso ou aquilo…
Em nenhum momento falei que o VRaptor é bala de prata, só frisei o quanto ele te proporciona de controle sobre seu projeto, coisa que o JSF não faz. Então não coloque palavras na minha boca… Outra coisa, o VRaptor têm suas limitações, claro, mas ele é BEM MAIS FÁCIL de ser estendido que o JSF, fora que já vem com um mecanismo nativo com suporte a injeção de dependência, e é MUITO, mas MUITO MESMO, fácil de se integrar com qualquer outra biblioteca ou framework…
Outra coisa, não tive saco pra conhecer a versão 2.0 pelo simples fato das coisas acontecerem muito devagar quando se trata do JSF… Quanto tempo eles demoraram pra sair da 1.2 pra 2.0?! Mesmo sabendo das inúmeros pontos negativos e das reclamações que existiam por parte da versão 1.2 demoraram uma eternidade… Então eu simplesmente não cultivo o pensamento “na próxima especificação eles vão corrigir isso”…
Já que você tá falando aí, me mostra como vc usa ExtJS com o JSF? Ou qualquer outra biblioteca javascript sem ter que contornar o JSF a todo tempo?! JSF surgiu quando essas tecnologias WEB (que fizeram surgir o termo WEB 2.0) não estavam tão desenvolvidas, maduras e possibilitando tanta interatividade na parte cliente… Hoje em dia não é necessário que a parte do servidor se ocupe em como renderizar as coisas no cliente, você tem trocentas opções para isso… Por isso não gosto do JSF, mas se você gosta, blza é opinião sua… Mas vc pelo menos se questionou o quanto de acoplamento ele te impõe? E vc acha isso bom? Como afirmei antes, depois nós que criticamos que somos os fanáticos e temos visão seletiva…[/quote]
Desculpe se te ofendi.
Não sei pq eu ainda abro a boca pra falar nesse tipo de tópico… É a mesma coisa que falar pra um religioso fanático que ele tem que abrir a cabeça…
Prezado bob_sponja, com todo o respeito à sua opinião, eu tambem discordo de alguns pontos que voce colocou. Embora concorde com outras, hehe. Tenho mais experiência com a versão 1.2 do JSF, e muitas vezes também me frustei. No entanto acho o JSF uma excelente opção para desenvolvimento web com Java, e na minha opinião, JSF+SEAM é a melhor conjunto para trabalhar com web Java hoje. Mesmo na versão 1.2 do JSF o Seam já fazia maravilhas. Enfim, falemos do JSF.
Sobre os pontos que colocou achei interessante o que colocou sobre o acoplamento da view->controller que existe no JSF, concordo com o que disse. Não obstante, se você usar o VRaptor, ou o SpringMVC, por exemplo, você não fará o controller pensando especificamente em uma página? Os seus métodos não serão feitos pensando na funcionalidade da view? Imagino que sim. Esse acoplamento página->classe quase sempre existirá. Não vejo isso como um problema, com todo o respeito à sua opinião.
A proposito, o JSF também tem “suporte nativo” à injeção de dependência, via managed-properties. E não vejo dificuldade alguma em integrar um managed-bean
com qualquer outro framework que seja usado na aplicação. E se puder, sugiro o estudo da versão 2 do JSF que está excelente.
Um outro ponto que voce levantou que outros colegas do fórum tambem questionaram aqui, sobre integrar o JSF com frameworks Javascript. Nesse tópico há muitas críticas nesse sentido. Particularmente não vejo problema algum em fazer isso. Com o Facelets (view-handler padrão do JSF), é possível criar uma pagina HTML comum, com seu framework Javascript preferido e com o CSS que quiser. Não entendo a dificuldade nesse sentido, é perfeitamente viável e tão factível quanto seria criar uma página com qualquer outro framework. O PrimeFaces e o RichFaces tem componentes que usam o JQuery e Prototype (como exemplo), e são feitos para aplicações JSF…não é “impossível” como colocaram aqui. Mas ainda no ponto “componentes”, o EXT JS tem componentes visuais muito bonitos, fato. Mas duvido que utilizá-los seja mais fácil do que usar o PrimeFaces ou o RichFaces, como exemplo. Acho esse detalhe importante no JSF, pois a especificação permitiu que fossem criados uma gama de frameworks de componentes que encapsulam muito do trabalho que seria feito na view (Javascript, manipulação do DOM, Ajax, etc). E olha que até que não sou ruim no Javascript, hehe, mas se eu posso jogar uma taglib que já faz o trabalho, por que não?
Obrigado.
Só esclarecendo a questão que citei do acoplamento, o que quis dizer é que você muitas vezes não tem liberdade em fazer o que quiser na visão com JSF, sendo que com outras tecnologias é possível. A questão do acoplamento em nomes de parâmetros, atributos de EL, isso é inevitável…
As pessoas lancam um framework.
Versão 1.0 => LIXO TOTAL
Aí jogam fora e fazem outro:
Versão 2.0 => Apenas lixo
Aí jogam foram e fazem outro:
Versão 3.0 => Ok
Se vc trabalha em cima de um lixo durante muito tempo, ele fica aceitável. Isso é fato. EJB3 está aí para provar isso.
O problema é a filosofia de trabalho que assassina o KISS (Keep It Simple Stupid).
JSF é muito amarrado e burocrático. Usá-lo para um sistema web cheio de formulários e cheio de Ajax até pode se justificar.
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.
Agora é claro que para o cara que só trabalhou com JSF e já se acostumou com aquela bagunca isso não faz o menor sentido. Ele vai achar o JSF ótimo.
De novo: só há como comparar dois frameworks pegando um cara que NUNCA programou em nenhum dos dois e falar para ele gastar uma semana brincando com um e uma semana brincando com outro. APENAS ASSIM.
"Qualquer um pode escrever código complexo que funciona… Poucos vão conseguir escrever código simples que funciona, é fácil de entender, usar e manter."
[quote=saoj]Agora é claro que para o cara que só trabalhou com JSF e já se acostumou com aquela bagunca isso não faz o menor sentido. Ele vai achar o JSF ótimo.
[/quote] 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.
Já trabalhei Servlet/JSP/Javascript. Era bom pacas pois você tem o comando todo na mão. O chato é ter que fazer get/set para tudo na unha.
Trabalhei e trabalho com JSF. Infelizmente no meu trabalho utiliza o 1.2. Não gosto mesmo. Tenho um sistema por fora em que uso o JSF 2.0. Muito bom, fácil e prático. E ainda espero o 2.2 que tem muita coisa boa. Uma delas é Converters, Validators, etcs aceitar injeção tipo @EJB.
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).
Se aparecer algo melhor no mercado, eu caio dentro sem pensar duas vezes. Mas eu não vejo por que não indicar JSF ou achar que é lixo.
Mas é como dizem… Opinião é igual orelha, cada um tem a sua. E alguns tem mais de uma! [=