JSF é o futuro nas empresas???

This message was edited 1 time. Last update was at 06/12/2007 16:45:41

rato*loco wrote:
parabnes entao vaza, cai fora e deixa o jsf pra nos o homem rails

Este tópico já teve dias melhores.

This message was edited 1 time. Last update was at 06/12/2007 16:55:13

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

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 .

brigadao amigo vou dar uma estudada em breve voltarei t+

This message was edited 1 time. Last update was at 07/12/2007 23:12:54

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:

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

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

No SEAM:

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

This message was edited 10 times. Last update was at 07/12/2007 21:26:36

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:

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:

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.

This message was edited 2 times. Last update was at 07/12/2007 22:21:23

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.

This message was edited 4 times. Last update was at 07/12/2007 22:59:52

Leonardo3001 wrote:
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.

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

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!

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

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.

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

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.

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

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.

This message was edited 2 times. Last update was at 08/12/2007 01:05:50

saoj wrote: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.

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.

saoj wrote:
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.

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.

saoj wrote:
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 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.

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

(código)

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

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.

saoj wrote:
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...

Faltou um return... já corrigi a listagem.

saoj wrote:
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...

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.

saoj wrote:
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:

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

saoj wrote:
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.

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

saoj wrote:
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.

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.

saoj wrote:
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.

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.

saoj wrote:
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.

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:

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 wrote:
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.

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.

pcalcado wrote: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.

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)

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

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.

rodrigoy wrote:
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"?

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.

rodrigoy wrote:
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)

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.

This message was edited 1 time. Last update was at 08/12/2007 01:29:50

Porém, creio que são poucos os casos que a chamada se diferencia por POST ou GET.

Não sei. Eu uso bastante. Por exemplo: se for GET o cara está querendo ver a página, se for POST ele está submetendo. Isso nunca deixará de ser importante ou necessário. Por exemplo, se o cara submeter um formulário com senha via GET vc tem que travar isso. GET é cacheado. POST não. E por aí vai...

Independente do Action Framework, enfiar coisas no request sempre me obrigam a lidar com tripas de String.

De maneira nenhuma. Desde que o FormBean do Struts foi execrado que as pessoas intenderam que usando reflection e ioc é possível transformar qualquer tripa de String num objeto bonitinho. No Mentawai vc simplesmente faz um input.getObject(User.class) para pegar o seu POJO com os seus dados ou configura um filtro para aquela action que colocará esse objeto prontinho pra vc no input da action.

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ódi

Posso estar errado, mas pra mim parece que está errado. #{user.name} parece que é algo que é traduzido antes de a tag ser executada, ou seja, a tag não vai ter como saber qual o nome da propriedade. Vai receber apenas o seu valor. No mentawai faríamos isso um pouco diferente:

Faz tudo isso em cima de tecnologia Jboss ou Ejb3. IOC/DI uso EJB3. Discordo muito de você nesses 90%. A parte servidora da aplicação é feita em minutos com EJB3, JPA, Hibernate Validator e DDD.

É muito difícil acreditar nisso... Parece até piada, falando sério... As coisas não acontecem por mágica... Convention over Configuration é legal mas tem limites. Veja a documentação oficial do JBoss seam e o primeiro exemplo para perceber que essas coisas não são tão taken-for-granted assim... Pelo menos não parece: Veja quanta configuração eu tenho que fazer aqui: http://docs.jboss.com/seam/1.2.1.GA/reference/en/html/tutorial.html

Como isso seria feito num Action Framework? (Dois botões...)

Teríamos dois formulários ou melhor um único com um onClick javascript... Isso é algo que uma tag bem feita pode resolver. Realmente essa tag se faz necessária para esses casos, se não o cara bate cabeça...

Mas sim, como falei, é Action Framework vs Component Based Framework

Realmente, eu já entendi isso... É que eu, naturalmente, usei o Mentawai como action-based e vc usou o Seam como component-based (ou seria event-based?).

Realmente suas colocações foram muito interessantes. Me deixaram pensando bastante nessa coisa de action-based x event-based, quando um é mais desejável que o outro, as necessidades do protocolo web, etc e tal. Com certeza estarei matutando em cima disso durante um bom tempo, para aprender mais e se possível melhorar o Mentawai também.

Abraço e bom fds! (Eu to partindo pro meu agora, bastante atrasado por sinal!)

JavaGuru Membro desde: 27/07/2006 19:56:35 Mensagens: 287 Offline

jgbt wrote:

bebad wrote: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 !!!

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

codigo porco sendo gerado pra vc ?
lol
bom, dai depende de vc meu truta, codigo porco só se for o seu

o meu é limpinho, ordenadinho, comentadinho e eu que fiz, a ide me ajuda sim E MUITO, confesso que sem IDE boa, jsf fica HARD MODE, debugar jsf com o tail e lendo log do JBoss é algo realmente complicado.
mas dai, me diz uma coisa,
qual framework que tem mais exemplos prontos na web ??? ahn ?
entao trut,
jsf apavora...

ate hoje, nunca precisei criar nada...sempre achei tudo pronto.
as veses é um pouco dificil de implementar, porque precisa ter pacientia pra entender, e adaptar ao seu projeto.

ontem mesmo perdi 3 horas pra implementar um baratinho de datas do tomahawk no meu projeto...um tal de <t:calendar/>
mas ai mano, depois que vc instala, só sair usando tudo q o tomahawk tem de melhor, ta tudo pronto...o seu trampo é só desvendar como funciona e implementar.

melhor que isso, só a integracao de JSF com SEAM....que isso meu caro, nao tem comparacao mesmo..
quem usa sabe,

ate nosso amigo, que fez as validacoes com o rails, deve saber que o Seam na sua versao 2.0 apavora!!!!!!!!!!!

abrassos geral.

bebad wrote:

ate hoje, nunca precisei criar nada...sempre achei tudo pronto.
as veses é um pouco dificil de implementar, porque precisa ter pacientia pra entender, e adaptar ao seu projeto.

ontem mesmo perdi 3 horas pra implementar um baratinho de datas do tomahawk no meu projeto...um tal de <t:calendar/>
mas ai mano, depois que vc instala, só sair usando tudo q o tomahawk tem de melhor, ta tudo pronto...o seu trampo é só desvendar como funciona e implementar.

como falei antes(leu os posts?), JSF tem suas vantagens e aplicações.
Para fazer CRUD, ele é muito bom.
Me parece que é no que vc esta baseando seus exemplos.

[]´s

HelloWorld Membro desde: 16/08/2007 12:38:03 Mensagens: 17 Offline

Pelo que pude ler, nesse grande topico e o seguinte :
Um lado usa pq da maior produtividade, e o outro pq nao quer depender da IDE.
Acho que os dois sao bons, mas como o rodrigo falou o SEAM e muito bom mesmo e o Valitation do Hibernate, nao se se voces estao a par, mas devera ja estar incluso como aconteceu com o Top-link e o Hibernate dentro do JPA no Java 7. E eu tive a oportunidade de usar os dois em sistemas pequenos e maiores. Achei os dois bons, pode ser que o baseados no JSF tenham a vantagem, por causa da produtividade, e o codigo nao sai porco nao. Sem contar que para ensinar um time do 0, o JSF e fera. e ate agora nao entendi o porque do medo das IDEs serem poderosas e ajurdarem muito ???
Nao e para isso que elas existem ? Ou talvez prefeririam usar o velho NE do DOS, ai sim teria que ser tudo x tudo hard code!
Acho que temos que caminhar para frente, o struts foi bom, mas a fila anda, do mesmo jeito que um dia pode ser que o Java esteja na mesma posicao que o Cobol se encontra hoje.
Mas isso so o tempo dira, o que ao meu ver o que temos que ter em mente e : fazer codigo bem feito, de facil manutencao e rapido.
E se nao for feito ferramentas para codigo poderosas para actions-based, aposto como 2 e 2 sao 4 o JSF ira dominar.
Atualmente estou usando JSF com algum ajax, mas pouco, pq meus sistemas sao muito sensiveis e nao podemos correr nenhum risco de perda de dados ou invasao e etc. Claro que tem muita coisas que sao hard code, mas para que existe as IDES ?? Vamos usa-las.
Acho.. olha pessoal e minha opinao, o JSF vai ser o futuro sim ou algo bem parecido com ele, claro que ele nao e uma tecnologia tao madura qto as action-based (struts, mentwai e por ai vai), mas mesmo nao sendo ja e muito boa.
E quanto a medo de mercado, empregos essas coisas por causa de IDEs e bla bla bla.... isso hoje e com certeza ate para nossos netos, nao ira ser problema, pq o mundo todo ta se informatizando, e a carencia de profissionais de informatica so ta crescendo. E vai continuar a crescer por um bom tempo.
E por fim... realmente as anotacoes sao uma mao na roda, e claro e o futuro, gostem ou nao. So esperem essas tecnologias ficarem so um pouco mais maduras....