vRaptor x JSF

Em outras palavras, vc não está comparando. Pelo que notei, vc levantou os pontos fortes do Vraptor e os pontos fracos do JSF. Se quer comparar seja justo com ambos…

Peerless,

por isso mesmo estou querendo a opinião de outras pessoas. Gostaria de saber as vantagens que o JSF tem em relação ao vRaptor tb.

Comente aqui as vantagens do JSF, por favor! No final iremos compilar as opiniões de todos.

abraço,

Vamos dar um kick de inicio então…

A componentização não é proprietária, e apenas uma API, e pode ser criado componentes ricos com base nela e plugável a ela (richfaces, icefaces, facelets, tomahawk, etc.). -você escolhe o fabricante da sua implementação que mais lhe agradar-, -você pode estender seus componentes e criar os seus próprios a.k.a personalizados-

Possui orientação a eventos, tornando o ciclo de produtividade maior.

Possui bom suporte e documentação, além de uma comunidade ativa.

É um produto da Sun, ou seja, tem credibilidade

Tem total integração com outros frameworks famosos do mercado… hibernate, toplink (jpa) - spring, struts, etc.

Legal, Peerless!

É isso mesmo que espero que vc e outras pessoas postem aqui. Características e visões sobre os dois frameworks.

Só tem um “porém”:

• JSF não é um produto da Sun e sim uma especificação da Sun. A Sun tem sua própria implementação do JSF mas não podemos que o JSF é um produto. O que vc pode dizer nesse caso é que é incentivado pela Sun e por isso tem credibilidade.

O que podemos dizer sobre Injeção de Dependência no JSF?

Sobre curva de aprendizado? Vcs acham que é média ou grande? (meio subjetivo…)

O que mais podemos ressaltar entre diferenças?

E você pode me dizer onde que tá essa produtividade maior que eu não to vendo?

E o VRaptor não?

EJB 2.x também, vamos voltar a usá-lo.

E o VRaptor não? Aproveitando, pra que integrar com Struts?

Se você disse que nosso amigo está tendencioso, você está mais ainda.

[/quote]

andrepestana:

Legal, Peerless!

É isso mesmo que espero que vc e outras pessoas postem aqui. Características e visões sobre os dois frameworks.

Só tem um “porém”:

• JSF não é um produto da Sun e sim uma especificação da Sun. A Sun tem sua própria implementação do JSF mas não podemos que o JSF é um produto. O que vc pode dizer nesse caso é que é incentivado pela Sun e por isso tem credibilidade.

O que podemos dizer sobre Injeção de Dependência no JSF?

Sobre curva de aprendizado? Vcs acham que é média ou grande? (meio subjetivo…)

O que mais podemos ressaltar entre diferenças?

você não considera a especificacao de um projeto (sua api) um produto?

Eu acho a curva de aprendizado média, assim como a do Vraptor. -minha comparação-

E você pode me dizer onde que tá essa produtividade maior que eu não to vendo?

E o VRaptor não?

EJB 2.x também, vamos voltar a usá-lo.

E o VRaptor não? Aproveitando, pra que integrar com Struts?

Se você disse que nosso amigo está tendencioso, você está mais ainda.
[/quote]

Você foi radical

1 - Quando eu disse em produtividade, não me referi em jsf x vraptor necessariamente. Mas o bom senso cabe no sentido “ter eventos é melhor do que ter actions/commands”, não concorda?

2 - Estamos comparando com JSF, certo ?

3 - Você confia mais na Sun ou na empresa X, Y ou Z ? (não é nada contra a Caelum [empresa dos autores do Vraptor], que por exceção tem uma boa credibilidade.)

ok, ok…

Tá bom, peerless… vc venceu. A especificação do JSF é um produto da Sun… para não confundir com as implementações. Ter várias implementações diferentes poderia ser um ponto positivo (ou não).

mas e quanto à outras características como reutilização de código, testes funcionais, validação?

O que temos mais a dizer?

Pra não dizer mais que sou tendencioso, temos um ponto a favor do vRaptor pelo número de ferramentas que suportam JSF e que facilitam o desenvolvimento como o Red Hat Developer Studio ou JDeveloper. Alguém pode citar o nome de outras ferramentas?

Po peerless, não fui radical não, você que foi meio tendencioso …

Minhas opiniões sobre seus pontos:

Não concordo não. Isso depende bastante. Acredito que a abstração do framework que te dá a produtividade, seja ela Component-Based ou Action-Based. o Próprio VRaptor é prova disso. Ridiculamente simples. O JSF com o Seam pode ser bem simples também. Porém, em aplicações onde o método http faz diferença (e.g. aplicações REST), JSF pode ser um problema.

Essa pergunta contradiz a primeira pergunta. Sim estamos comparando com JSF.

Confio no produto que o mercado confia e usa. Exemplos: Hibernate, O próprio Struts 1 quando não existia nada, ANT, Log4J, Tomcat, JBoss, Jetty, Maven, XFire, Xtream, [coloque aqui seu framework/biblioteca que não foi criado pela sun, mas sem estourar o buffer, pois existem zilhões :)]
Isso prova que confiar na Sun não é garantia de sucesso, muito menos de usar um produto bom. Basta lembrar que a Sun tem grande culpa nas arquiteturas BOLOVO usada nas empresas a nível mundial, e não esqueçamos dos EJBs 2.x (Com aqueles EntityBeans desgraçados) hehehe

Eu acho que a melhor comparação a ser feita é a comparação do Rodrigo Yoshima no tópico “JSF é o futuro nas empresas???”. Recomendo dar uma passada por lá, especialmente a página 11.

Eis o post do Rodrigo:

rodrigoy:

Olá Amigos… discussãozinha acirrada. Bem, posso estar completamente maluco e falando a maior besteira da minha vida, mas vocês não acham que a discussão toda roda em cima de framework web component-based vs action-based?

Vamos lá… desenvolví várias aplicações em Struts 1, ainda não conhecí Struts 2, ví exemplos do WebWork e do Mentawai, ainda não ví do VRaptor… Basicamente Action Frameworks trabalham de maneira similiar e abstrações parecidas. Não vou citar Rails pois não conheço tanto para fazer comparações.

O que quero colocar aqui é que JSF, ou qualquer framework component based, trabalha com uma abstração melhor que frameworks action-based, e melhores abstrações são mais fáceis de serem construídas e mantidas. Deixa eu pegar um exemplo Mentawai vs SEAM:

package org.helloworld.action;
 
 import java.util.Collection;
 
 import org.helloworld.entity.User;
 import org.helloworld.service.UserService;
 import org.mentawai.core.BaseAction;
 import org.mentawai.filter.ModelDriven;
 
 public class UserAction extends BaseAction implements ModelDriven {
    
    private UserService userService = new UserService();
    
    public Object getModel() {
       
       return userService;
    }
    
    public String add() {
       
       if (isPost()) { // POST
          
          String name = input.getStringValue("name");
          
          if (name == null || name.trim().equals("")) {
             
             addError("Por favor digite um nome!");
             
             return ERROR;
          }
          
          User u = input.getObject(User.class);
          
          userService.add(u);
          
          return SUCCESS;
          
       } else { // GET
          
          return JSP;
       }
    }
    
    public String list() {
       
       Collection<User> users = userService.getUsers();
       
       output.setValue("users", users);
       
       return SUCCESS;
    }
 }

Usando o SEAM, essa Action poderia ser um Application Facade:

package application;

import java.util.List;

import domain.User;
import domain.UserRepository

import org.jboss.seam.annotations.In;
import org.jboss.seam.annotations.Name;

@Name("usuarioFacade")
public class UsuarioFacade {
	
	@In
	UserRepository repository;
	
	@In
	User user;
	
	public void add() {
		repository.add(user);
	}

	public List<User> getUsers() {
		return repository.getAll();
	}
}

Os dois exemplos acima fazem a mesma coisa. Antes de comentar vamos às páginas:

Primeiro no Mentawai (partes não interessantes foram cortadas):

<h3>Please enter you name:</h3>
 
 &lt;mtw:outError&gt;<font color="red">&lt;mtw:out /&gt;</font><br /><br />&lt;/mtw:outError&gt;
 
 &lt;form action="&lt;mtw:contextPath /&gt;/UserAction.add.mtw" method="post"&gt;
 &lt;mtw:input name="name" type="text" size="20" /&gt; <br /><br />
 &lt;input type="submit" value="Say Hello" /&gt;
 &lt;/form&gt;
 
 &lt;h2&gt;The following persons have said "hello" to Mentawai:&lt;/h2&gt;
 
 &lt;mtw:list value="users"&gt;
    &lt;mtw:isEmpty&gt;
       &lt;h4&gt;Nobody has said so yet!&lt;/h4&gt;
    &lt;/mtw:isEmpty&gt;
 
    &lt;mtw:loop var="user"&gt;
       &lt;mtw:out value="user.name" /&gt;<br />
    &lt;/mtw:loop&gt;
 &lt;/mtw:list&gt;

No SEAM:

<h:messages globalOnly="true" styleClass="message"/>

    <h:form>
     	Please enter your name:
    	<h:inputText value="#{user.name}"/>
    	
    	<h:commandButton action="#{usuarioFacade.add}"/>
    </h:form>
    
    <h2>The following persons have said "hello" to SEAM:</h2>
	
    <h4><h:outputText value="Nobody has said so yet!" rendered="#{usuarioFacade.users is null}"/></h4>

    <ui:repeat value="#{usuarioFacade.users}" var="usr">
    	<h:outputText value="#{usr.name}"/>
    </ui:repeat>

Queria destacar alguns pontos para demonstrar essa questão de “abstrações melhores”. Primeiramente, leia a action do Mentawai (pode ser qualquer outro action-framework) e leia a Facade do Seam. Qual lhes parece mais focada na solução do problema? A página inclui um usuário e lista usuários. Qual é mais concisa nesses dois pontos?

E as páginas? O fato de você poder usar a própria entidade na página não é relevante? Não fica mais claro a indicação da ação ficar diretamente no botão?

Minha defesa sobre JSF não é necessariamente para “JSF”, mas sim para abstrações melhores. Action Frameworks possuem abstrações fracas. Sempre preciso de alguma coisa que represente um HTML Form (coisas como input.getStringValue(“name”)). Isso é uma abstração fraca, é algo que não precisaria me preocupar. Pior ainda quando tenho que ter uma classe que represente uma ação como Actions do Struts.

Bem, quero que vocês entendam que não estou criticando Mentawai aqui. Poderia ser qualquer Action Framework e os exemplos seriam parecidos. Na sinceridade? Passei a gostar de fazer sistemas Web em Java quando o SEAM trouxe essa idéia de “Contextual Components”. Não é a bala de prata, pode dificultar a escalabilidade, mas simplesmente é uma abstração melhor. Como estou fazendo sistemas hoje que pretendo viver deles nos próximos 10 anos, quero boas abstrações.

Até!!!

andrepestana:

ok, ok…

Tá bom, peerless… vc venceu. A especificação do JSF é um produto da Sun… para não confundir com as implementações. Ter várias implementações diferentes poderia ser um ponto positivo (ou não).

mas e quanto à outras características como reutilização de código, testes funcionais, validação?

O que temos mais a dizer?

Pra não dizer mais que sou tendencioso, temos um ponto a favor do vRaptor pelo número de ferramentas que suportam JSF e que facilitam o desenvolvimento como o Red Hat Developer Studio ou JDeveloper. Alguém pode citar o nome de outras ferramentas?

Deixando claro que eu gosto do vRaptor tbm, mas acabei caindo de paraquedas aqui defendendo o JSF -que também tem seus defeitos-

Mas, chega de vir com o mesmo exemplo do EJB2 -esse exemplo ja está muito manjado para criticar a sun :D-

Bom, quanto as suas respostas Andre:

É bom sim ter várias implementações de uma mesma especificação, você pode ter inclusive a sua

Qual problema de reutilização do JSF? Ele lhe oferece uma view praticamente O.O., pois como eu disse, você pode estender seus componentes de UI tranquilamente, ou até mesmo criar os seus e decorar (facelets), etc. - Ele da um bom suporte a validação e conversão, oferecendo alguns padrões e uma fácil arquitetura para criação dos seus próprios -esses, facilmente plugáveis no arquivo de configuração do faces-config-

O Eclipse EE ou o Netbeans normal já oferece todo suporte para desenvolver em JSF

Emerson Macedo:

O JSF com o Seam pode ser bem simples também. Porém, em aplicações onde o método http faz diferença (e.g. aplicações REST), JSF pode ser um problema.

https://restfaces.dev.java.net/
https://javaserverfaces.dev.java.net/

Rafael Nunes:

Emerson Macedo:

O JSF com o Seam pode ser bem simples também. Porém, em aplicações onde o método http faz diferença (e.g. aplicações REST), JSF pode ser um problema.

https://restfaces.dev.java.net/
https://javaserverfaces.dev.java.net/

RestFaces 1.3 documentation:

Where is the JavaServer? Faces problem? JavaServer? Faces components usually submit a POST to the Faces Servlet. POST requests make the resulting page not bookmarkable in general. Our solution uses simple GET requests instead.

Na minha opinião, JSF pra fazer alguma coisa REST permanece fora de cogitação.

Peerless, sei que não existem frameworks perfeitos, apenas existem frameworks mais apropriados para determinadas tarefas ou que por algum motivo nos agradam mais para realizar uma tarefa. O que vc diria que é um ponto fraco ou defeito do JSF?

Os pontos fracos do vRaptor na minha opinião são:
-Baixa popularidade
-Ausência de taglibs (eu não acho isso um ponto fraco mas sempre será apontado como ponto fraco)
-Ser relativamente novo (hoje em dia já existem mais de 100 frameworks MVC se tivesse chegado antes teria mais popularidade e confiança)

Na verdade estou criando essa discussão pq estou preocupado com um padrão de desenvolvimento aqui na empresa para escolhermos um framework para desenvolver todos os sistemas daqui para frente. Já está quase certo que será JSF.

Achei uma apresentação do Ed Burns com ponto fortes/fracos:

https://javaserverfaces.dev.java.net/presentations/demystifyingjsf.pdf

Strengths and Weaknesses of JSF
Strengths

• Powerful
• Flexible
• Abstraction
• Tool support
• “Black Box” components for the web
• I18N,L10N,A11Y
• Industry Standard

Weaknesses

• Complex, overkill in some cases
• Different mind-set from Action based frameworks
• Conceptually divorced from HTTP
• JSP layer had problems prior to JSF 1.2
• All stateful by default - performance problem

Querer estabelecer um framework único para todos os projetos é procurar bala de prata, que foi provado não ser uma boa idéia. Acho até que um determinado framework possa ter uma utilização em larga escala dentro de uma empresa, mas se tornar “padrão” pode ser perigoso, seja JSF, VRaptor ou qualquer outro.

Concordo com vc, Emerson!

Espero arrumar bons argumentos para não fechar numa solução única para tudo.

Segue um cartoon para descontrair:
http://bp0.blogger.com/_79IsVE3vX_Y/R4NaHRNqyII/AAAAAAAAABU/OubIc7x1aes/s320/JSF_cartoon.jpg

Abraço,

Olá Ataxexe,

Seja lá quem for que fez esse código usando o Mentawai realmente não o utilizava em seus projetos. Pela sua flexibilidade e fácil aprendizado, é possível escrever uma action com mentawai de várias formas diferentes e essa foi a mais porca possível.
A pessoa que escreveu essa action o fez de qualquer jeito somente para empurrar suas crenças(lamentável) a quem fosse ler o post. Primeiro, pq foi feito com o Seam utilizando design patterns de IoC e DI? e com o Menta ele não utilizou nenhuma das boas práticas do GOF? e ainda analisou se a requisição era por POST ou por GET…
Sinceramente, muito tendencioso…

Caros colegas, parem de comparar e querer mostrar que a sua framework predileta é a melhor do mercado. Cada uma é feita para uma arquitetura específica, se não fosse assim, o que seria de nossos analistas e arquitetos de software? hehe…

Abs.

O Seam parece que sente prazer em se livrar da action e fazer a ponte requisição -> modelo direto. Fica menos código mas não fica necessariamente melhor. Há várias discussoes sobre isso e parece que a maioria concorda que é melhor manter a action. Mais sobre essa discussão aqui: http://www.theserverside.com/news/thread.tss?thread_id=48304

Me parece que os frameworks component-based como o JSF encaram uma aplicação web como uma aplicação desktop que por coincidência está usando uma interface web. Ele não se importa muito com os aspectos do protocolo HTTP, com cookies, com POST e GET e por aí vai… A abstração da parte “web” de uma aplicação web pode ser perigoso…