JSF é o futuro nas empresas?

Front-end
#141

Galera nao usem JSF, porque é uma bosta!!!

Deixem que eu uso, e dai eu ganho toda a grana dos projetos por vcs, e enquanto vcs tao fazendo um crud-tabular eu ja to nas validacoes com Seam !!! :roll:

#142

outra ponto importante é que usando uma IDE com suporte voce pode ser muito produtivo usando JSF.
mas não se esqueçam que produtividade NÃO É SO TEMPO DE DESENVOLVIMENTO.
O maior custo de um software é manutenção(não seio nde coloquei o link sobre isso).

[]´s

#143

[quote=bebad]Galera nao usem JSF, porque é uma bosta!!!

Deixem que eu uso, e dai eu ganho toda a grana dos projetos por vcs, e enquanto vcs tao fazendo um crud-tabular eu ja to nas validacoes com Seam !!! :roll: [/quote]
Não vi ninguem aqui dizendo que é uma bosta.
Eu so não quero me tornar IDE developer, com codigo porco sendo gerado p/ mim… ja migrei p/ o java por causa disso.
Se vc leu o titulo e TODA a thread vc percebeu que foram dados argumentos suficientes que JSF não é uma maravilha.
Se vc gosta, otimo, use e seja feliz. Mas antes de o JSF se tornar maduro o suficiente para atender requisitos complexos, ja vai surgir alguma coisa melhor. JSF é a resposta da SUN ao MS VS, isso que eu acho. Agilizando desenvolvimento e criando os mesmos velhos problemas.

[]´s

#144

Ta bom vc´s sabem td de jsf entao alguem me explique como gerar wml apartir do jsf tipo hora que o cliente acessar a pg se for celular mostra wml se for browse normal mostra html como se faz isso?

#145

Isso não tem nada haver com JSF. Simplesmente essa informação virá num header, daí vc saberá se tem que jogar o cara para o site em html ou para o site em wml. E nem pensa em usar XSTL para ficar transformando XML em HTML em WML em XXX. Isso foi outra coisa tipo EJB e JSF que passou longe de dar certo… Alguém chegou a usar cocoon?

#146

entao isso significa que os meus componentes jsf precisam ser diferentes para wml e html vou ter q criar isso na unha alguem tem um exemplo ???

#147

[quote=rato*loco][quote]

Isso não tem nada haver com JSF. Simplesmente essa informação virá num header, daí vc saberá se tem que jogar o cara para o site em html ou para o site em wml.

[/quote]

entao isso significa que os meus componentes jsf precisam ser diferentes para wml e html vou ter q criar isso na unha alguem tem um exemplo ???[/quote]

Alguma coisa que roda WML e não HTML muito provavelmente não vai ter suporte a JavaScript, então os seus componentes serão praticamente NULOS ou Não-existentes.

WML (o tal do WAP) nunca existiu na minha opinião… é uma coisa tosca que serve para muito pouco… se vc quer um site em WML, vc terá uma versão para web e outra para WML totalmente independente e diferente, ambas acessando a mesma base de dados…

WAP/WML não conseguiu nem engatinhar… eu cheguei a mexer com isso… era uma coisa muito triste… não existe mundo celular/web antes do IPhone… a coisa começou/nasceu agora com o Iphone…

e isso não absolutamente nada haver com JSF

#148

hum dexa eu ver se entendi entao vai ter que ser separado mesmo uma pg html e outra pra wml, mas da para usar os componentes do jsf pra isso né os input e output ai eu mudo o renderkit é isso?
ha e o mobilefaces qdo usar isso?pra que serve especificamente?quais recursos oferece?

#149

[quote=bebad]Galera nao usem JSF, porque é uma bosta!!!

Deixem que eu uso, e dai eu ganho toda a grana dos projetos por vcs, e enquanto vcs tao fazendo um crud-tabular eu ja to nas validacoes com Seam !!! :roll: [/quote]

Validacoes? Mas eu fiz em Rails e ja terminei… :wink:

#150

[quote=rato*loco][quote]

Validacoes? Mas eu fiz em Rails e ja terminei…

[/quote]

parabnes entao vaza, cai fora e deixa o jsf pra nos o homem rails :twisted: [/quote]

:shock: :shock: :shock:

#151

[quote=rato*loco]
parabnes entao vaza, cai fora e deixa o jsf pra nos o homem rails :twisted: [/quote]

Este tópico já teve dias melhores. :shock:

#152

[quote] rato*loco wrote…:entao isso significa que os meus componentes jsf precisam ser diferentes para wml e html vou ter q criar isso na unha alguem tem um exemplo ???[/quote]Acho que vc. deve estudar o tipo de navegador embutido no celular, como vai ser “renderizado” o seu componente, vc. pode baixar alguns emuladores e fazer uns testes da sua aplicação direto por ele.Procure por “RenderKit for WML” .:
http://www.javapassion.com/j2ee/JSFAJAX.pdf = slide 67/69.
http://www.ericsson.com/mobilityworld/sub/open/technologies/open_development_tips/tools/chtml_kit
Agora compre um bom livro estude e depois diga pra gente como foi .

#153

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:

    &lt;h:messages globalOnly="true" styleClass="message"/&gt;

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

    &lt;ui:repeat value="#{usuarioFacade.users}" var="usr"&gt;
    	&lt;h:outputText value="#{usr.name}"/&gt;
    &lt;/ui:repeat&gt;

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é!!!

#154

Primeiramente gostaria de lhe dar os meus parabéns por ter colocado uma crítica extremamente construtiva e bem feita. Isso é bastante raro. É prazeroso e proveitoso quando alguém faz uma crítica assim.

Abstração é importantíssimo, mas abastração demais também terá vários efeitos colaterais. Por exemplo, como vc testa se a requisição foi um POST ou um GET no SEAM? Dependendo da situação (POST ou GET) teremos resultados diferentes, mas no código do SEAM isso foi omitido. Não tenho idéia onde essa lógica seria escrita no SEAM, só espero que não seja dentro de um arquivo XML. Também o código do SEAM não fez nenhuma validação. A action do Mentawai faz a validação ali por pura comodidade, mas o certo é termos um filtro de validação desacoplado da action ou fazer com que a action implemente Validatable.

A action do Mentawai poderia ser ainda mais abstraída assim:

[code]
package org.helloworld.action;

// imports here…

public class UserAction extends BaseAction implements ModelDriven {

private UserService userService = new UserService();

private User user;

public Object getModel() {

  return userService;

}

public String add() {

  if (isPost()) { // POST
     
     userService.add(user);
     
     return SUCCESS;
     
  } else { // GET
     
     return JSP;
  }

}

public String list() {

 output.setValue("users", userService.getUsers());
  
  return SUCCESS;

}

}[/code]

O que está acontecendo aqui? Temos um filtro (VOFilter) que vai popular um User object com os valores do formulário e injetar na action. Se assim for desejado podemos abrir mão do input e injetar tudo na action. Como a minha action NÃO É o meu modelo de negócios ou o meu facade/service, então não vejo problema em utilizar o input ali, mas tem gente que prefere abrir mão dele, talvez para deixar a action bem desacoplada do framework, como se um TOTAL desacoplamento fosse possível ou desejável. Ele só deve ser possível e desejável para o seu modelo de negócios e fachadas (services).

Nó código do SEAM, não entendi como a lista de usuários vai chegar na camada view. Faltou um return ou um outject ali. Ou um getter… Não sei…

O código HTML me parece bem parecido, mas o inputText com o value não é legal, poderia ser como o Mentawai que calcula o valor internamente (no caso de checkbox por exemplo, o value não vai te ajudar em nada). Também não entendi da onde ele pega o parametro name. Talvez tenha faltado um name=“name” ali…

Minha única crítica ao seu comentário é que vc não mencionou como as coisas efetivamente acontecem e são codificadas no SEAM. A classe que vc listou não é equivalente a classe UserAction do Mentawai. Ela é equivalente a classe UserService (poderia ser UserFacade) que eu listo abaixo e que está incluída no exemplo do Mentawai:

package org.helloworld.service;

import java.util.Collection;

import org.helloworld.entity.User;
import org.helloworld.repository.UserRepository;

public class UserService {
   
   // Injeção vai acontecer aqui (IoC)
   private UserRepository userRepo;
   
   public UserService() { }
   
   public void add(User user) {
      
      userRepo.add(user);
   }
   
   public Collection&lt;User&gt; getUsers() {
      
      return userRepo.getUsers();
   }
}

O facade do Mentawai é IGUAL ao facade do SEAM. A questão é que entre o FACADE e a requisição web há uma action que vai organizar o meio de campo. Muitas vezes ela funciona simplesmente como um ponte. Outras vezes checa se temos um POST, se temos cookies, se temos algo na session, qual o IP da requisição, qual o browser, etc e tal. Quem faz esse meio de campo no SEAM? Um arquivo XML? Como vc pode querer abstrair ou ignorar isso? Alguém tem que ser responsável por isso e, ao meu ver, esse é o papel da action: fazer o meio de campo entre o facade e a requisição web.

Também faltou explicar como o SEAM faz o pool de conexões, a inversão de controle para injetarmos o repositório correto, o auto-wiring da conexão pra dentro do repositório, configuração das páginas JSP que vão tratar dessa requisição, persistencia do objeto User no banco de dados, etc. Essas coisas com certeza não vão acontecer por mágica e se vc pensar bem são 90% do trabalho pesado de uma aplicação web. É isso que o Mentawai procura abstrair do usuário.

A abstração que vc falou é realmente importante. O Mentawai separa claramente UserAction do UserFacade. No seu caso o UserFacade ficou atrelado ao framework em questão. No caso do Mentawai o acoplamento do Facade é zero.

A questão de indicar no botão qual a action que será executada não me parece muito diferente de indicar na action do formulário qual a action que será executado pelo framework. É a velha questão de transformar programação web em programação desktop orientada a eventos. Eu não acho isso legal, mas há muitas pessoas que, talvez por terem tido muita experiência com desenvolvimento desktop (Visual Basic, Delphi, etc), prefiram encarar a coisa dessa maneira.

O objetivo do Mentawai desde os primórdios foi abstrair toda a complexidade e trabalho pesado de uma aplicação web e também eliminar o XML. Acredito que hoje em dia, o primeiro objetivo é o que diferencia o framework dos outros, mesmo sabendo que a grande maioria ainda insiste no XML e/ou Annotatinos, o que além de contra-produtivo é desprazeroso.

#155

saoj,

desculpe, mas quando você fala de uma coisa que você não sabe, fica complicado! Tá, eu conheço Seam, mas não conheço Mentawai, então também não estou muito diferente de você. Por isso, só vou comentar sobre o Seam.

Você meio que tenta procurar onde está a maldita Action que liga a página web do façade, pois no Seam a única coisa que ligou os dois foi “@Name(“usuarioFacade”)” em cima da classe UsuarioFacade e nada mais, nem mesmo um arquivo xml!

Isso é uma coisa boa que o Garvin King tem, que é de querer reduzir as infinitas camadas da arquitetura J2EE; ao mesmo tempo em que tem “nojinho” de Domain-Driven Design. O resultado, paradoxalmente, é que frameworks como Seam e Hibernate caem bem tanto pro 4-tier, quanto pro DDD.

E a validação é feita através do Hibernate Validator (que apesar do nome, dá pra usar em aplicações que não utiliza base de dados) no model, como é feito em RoR. Tipo, são umas anotações @NotNull ou @Length que definem os limites permitidos para a entrada de dados.

Com relação a JSF, tudo bem que “não desce redondo”, mas, se limitarmos ao Java, está entre os melhores, pau-a-pau com Struts 2. Mas acredito que na versão 2.0, os caras do JCP vão tomar vergonha na cara e dar uma uma boa lustrada no framework.

#156

Me desculpe, estou tentando colaborar e aprender também. Acho que a minha pergunta foi válida.

Mas se eu tiver que tratar um cookie, como eu faço? Se quiser pegar o IP da requisição para passar para o meu model, como eu faço? Se eu quiser pegar um header da requisição para saber em que browser o cara está, como eu faço? Onde eu configuro o IoC e o DI? Onde configuro o pool de conexões? Só estou tentando entender onde isso vai estar se não estiver na action… Annotations-programming ou XML-programming…

Validação em XML ou Annotations é péssimo. Se duvida então dá uma olhada no Struts2, que vc citou como exemplo: http://struts.apache.org/2.x/docs/validation-annotation.html

Validação feito em código Java é bem melhor, na minha opinião. Para uma comparação você pode dar uma olhada aqui: http://forum.mentaframework.org/posts/list/1112.page

Sua opinião, que eu respeito. A minha é bem diferente…

#157

Bom ponto, Rodrigo. Eu Não tenho nada contra um ou outro paradgima. Me parece que Acton-Based é melhor para aplicações web e Component-Based para aplicações que têm interface web. Qual a diferença?

Alicações web estão vinculadas ao protocolo HTTP de fato, recisam aproveitar características da arquitetura da internet.

Aplicações que êm interface web poderiam ter interface de qualquer tipo, só são HTTP+XHTML porque hoje em dia é o modo mais simples e barato de fazer uma interface web.

Mas saindo do modelo arquitetural e falando em ferramentas (JSF x [Rails|Struts 2]) não é viavel continuarmos dependendo tanto de uma IDE seu ferramental.

#158

[quote=saoj]Primeiramente gostaria de lhe dar os meus parabéns por ter colocado uma crítica extremamente construtiva e bem feita. Isso é bastante raro. É prazeroso e proveitoso quando alguém faz uma crítica assim.
[/quote]

Bem, como falei, não é bem crítica, não desenvolví nenhum projeto com o Mentawai, o ponto que defendí foi apenas que sinto que no JBoss SEAM as abstrações são melhores, e com isso, me sinto mais produtivo. Outros pontos pode ser que Action Frameworks sejam melhores.

Se é post ou se é get o Seam consegue injetar na Façade. Porém, creio que são poucos os casos que a chamada se diferencia por POST ou GET. O Seam possui uma maneira de deixar as coisas RESTFull, não pesquisei isso pois até o momento a injeção do Seam resolveu a minha vida. Quanto a arquivos XML, o Seam não usa, só se você quiser (minha aplicação atual não tem 1 linha de XML para configurações funcionais). O XML de configuração do Seam é bem limpinho, é convention over configuration até o último fio de cabelo.

A validação ocorre, só que não precisamos nos preocupar com ela. Dá pra fazer via Hibernate Validator ou na Action… mas o Validator é bom, resolve 99% dos casos, quando não resolve, colocamos na Action ou no próprio Entity usando código Java no @PrePersist/Update.

Sim, mas você vê que eu preciso ficar lidando com esse filtro? A abstração que a implementação JSF do SEAM me traz é que o que estou mexendo na view é o meu Entity, e não algo que será enfiado dentro de uma HttpServletRequest que é uma tripa de Strings que vai cair dentro do meu Entity. Eu poderia até referenciar #{user.adress.streetName} na minha view de forma transparente, tanto para obter o dado como para settar o dado (e o framework validaria). Independente do Action Framework, enfiar coisas no request sempre me obrigam a lidar com tripas de String.

Faltou um return… já corrigi a listagem.

ué, porque não é legal? Quando vejo um <h:inputText value="#{user.name}"/> a abstração que me vem a cabeça é que quero um campo de entrada de texto para a entidade user, propriedade name. Não está faltando nada no código.

Bom, como falei não é uma crítica. O código SEAM está completo para essa aplicação. E é aí que a mágica acontece, como não preciso me preocupar com a infraestrutura Web, o Seam não precisa de algo que se chama Action. O pessoal do Seam até chamam o que chamei de Facade como Action, mas não tem a mínima razão para essa nomenclatura. Esse backing bean não é uma Action, poderia até ser um EJB Stateful. Esse backing bean é um Application Facade a lá Fowler. Não preciso da Action. Pra falar a verdade, algumas situações nem preciso da Façade. Um CRUD como exemplo daria para ser implementado inteirinho na VIEW sem abrir mão de OO e com um código XHTML muito limpo. (veja link)

http://docs.jboss.org/seam/1.2.1.GA/reference/en/html/framework.html

Como falei, é esse nível de abstração que gostei de trabalhar: LIGAR A VIEW DIRETAMENTE À CAMADA DE APLICAÇÃO, sem me preocupar com infraestrutura Web. E melhor, o troço funciona e é MUITO produtivo. É produtivo mesmo fazendo os XHTML na mão como eu faço. JSF não é dependente de ferramenta. Fazer JSF na mão com o Seam é mais produtivo que fazer JSP na mão com Action Frameworks (isso é extremamente IHMO). Como é IMHO, meu sentimento é que com o Seam a abstração é melhor, o código é mais claro e raramente você entra em Débito Técnico.

É esse meio de campo que traz abstrações pobres para Action Frameworks. Pare para ver e você verá que para a maioria das aplicações web e com banco de dados o que mais ocorre são POSTs. Se precisamos lidar com Cookies e outros é só acessar @FacesContext. Realmente isso não é tão natural para o Seam, mas também não é algo que você precisa ficar lidando toda hora.

Não sei porque você fala tanto em XML… Não tem nada oculto em XML no SEAM… particularmente, eu tenho NOJO de XML e a culpa disso foi um projeto Spring relativamente grande. Gosto do Spring, mas só volto a usar ele quando der para fazer tudo em Annotation ou outra convenção…

Faz tudo isso em cima de tecnologia Jboss ou Ejb3. IOC/DI uso EJB3. Configuração das páginas JSP não precisa. Você pode controlar o fluxo da própria Facade, ou se quiser em arquivo XML. Eu faço na propria Facade (é só colocar um return “/usuario.xhtml” e fazer o method binding retornar String).

Discordo muito de você nesses 90%. A parte servidora da aplicação é feita em minutos com EJB3, JPA, Hibernate Validator e DDD. O que realmente enche o saco e toma tempo é integrar isso com camada de apresentação, principalmente quando o Binding não é transparente. As vezes até acho que tenho algum bloqueio mental ou algo do tipo, mas fazer entidades, repositórios, regras de negócio é muito fácil na minha opinião com essas ferramentas que citei.

Bem, minha Facade é POJO. Só tem anotações do SEAM. Se por alguma razão eu precisar ligar ela com o Mentawai seria possível e fácil (seria só implementar a Action, mas como falei, no Seam eu não preciso dela). Como você mesmo falou, ela é bem parecida com o seu service. :lol:

Sim, a abstração do Visual Basic e do Delphi é melhor nesse sentido, assim como as aplicaçõezinhas Swing que desenvolví. Se eu precisar que o mesmo formulário execute duas funções no SEAM/JSF é assim:

&lt;h:form&gt;  
     Please enter your name:  
     &lt;h:inputText value="#{user.name}"/&gt;  
       
     &lt;h:commandButton value="Criar" action="#{usuarioFacade.add}"/&gt;  
     &lt;h:commandButton value="Remover" action="#{usuarioFacade.remove}"/&gt;  
&lt;/h:form&gt;

Como isso seria feito num Action Framework? (no Struts eu recorria a JavaScript ou tratamentos na Action). Seja sincero, que abstração é melhor? Limpe a sua cabeça de toda experiência que teve com Action Frameworks e do HTML puro e responda: Um formulário é uma acão?

saoj… sei que você foi o cara que concebeu o Mentawai… quero que você tenha em mente que não é crítica e nem comparação Mentawai x Seam. Mas sim, como falei, é Action Framework vs Component Based Framework, levando em consideração “abstrações melhores”. Mas por conta, nesses exemplos, prefiro escrever @Name(“usuarioFacade”) do que implementar umas 10-15 linhas de Action.

#159

[quote=pcalcado]Bom ponto, Rodrigo. Eu Não tenho nada contra um ou outro paradgima. Me parece que Acton-Based é melhor para aplicações web e Component-Based para aplicações que têm interface web.
[/quote]

Beleza, mas se quero um Component-Based ainda em html, que outras opções eu tenho que não sejam implementações JSF?

Sendo sincero, nunca desenvolví aplicações web de grande escala baseados em banco de dados. Já desenvolví homebankings grandes, mas eram backeados por mainframe. O que você quis dizer com “vinculadas ao protocolo HTTP de fato, recisam aproveitar características da arquitetura da internet”?

O fato é que não estou vendo fundamento nas críticas de vocês sobre JSF. Se estou usando a implementação RI, usando componentes RichFaces só para me ajudar deixando a aplicação “ajaxian” e fazendo um XHTML na mão e limpinho, qual o problema? A crítica maior é dependência de ferramenta e preconceito com arrastar e soltar?

(a única crítica que tenho é que é mais difícil escrever componentes JSF, mas Facelets ajudam bastante)

#160

Um paralelo: Eu acredto que DSLs são melhores que GPLs para desenvolver alicações. Ate’hoje não vi nenhuma ferramenta ara DSL realente usável então ão uso DSL como gostaria.

Da mesma forma se a melhor ferramenta ara desenvolver uma coisa não está dentro do que e considero aceitável e não a usaria. Eu uso JSF ara coisas simples mas não colocaria esta ferramenta coo fturo de nada, é apenas a coisa menos pior seguindo este paradigma que eu conheço. Para fazer algo mais comlexo e abro mão alegremente do conceito que doeria ser melhor em favor de uma ferramenta melhor.

Crie uma aplicação Restful com interfaces em HTML e HTTP para as mesmas coisas. Este é o tipo de aplicação que faz uso de HTTP.

[quote=rodrigoy]
O fato é que não estou vendo fundamento nas críticas de vocês sobre JSF. Se estou usando a implementação RI, usando componentes RichFaces só para me ajudar deixando a aplicação “ajaxian” e fazendo um XHTML na mão e limpinho, qual o problema? A crítica maior é dependência de ferramenta e preconceito com arrastar e soltar?

(a única crítica que tenho é que é mais difícil escrever componentes JSF, mas Facelets ajudam bastante)[/quote]

Minha crítica com JSF é exatamente esta. JSF foi criado cm a mesma filosofia horrível dos EJBs: você não precisa se reocupar, as ferramentas farão isso para você. Num mundo onde os fantásticos IntelliJ e Eclipse perdem mercado para Emacs e textmate isso não e aceitável como futuro.