Alguem sugere um framework melhor q o JSF? Ou uma maneira d trabalhar apenas c/ Request

Front-end
#1

Olha, o JSF até que é bom, se vc for trabalhar com SessionScope e afins.

Mas hj em dia as grandes aplicações, que precisam atender muitas
requisições e serem escaláveis precisam ser baseadas em requisições, e
não utilizar sessão. Sabemos muito bem que o JSF não foi feito para
atender apenas requisições, ele foi feito pensando em usar sessão, é
muito difícil trabalhar sem sessão no JSF e cai muito a produtividade.

Vou criar uma nova grande aplicação que usará muito javascript (jQuery, Node.js, Ajax)
e sei muito bem como fingir uma sessão apenas usando cookies, hidden fields e outros

alguem sugere um outro framework que pode ser utilizado sem sessão?

obrigado pelas sugestões :slight_smile:

#2

struts 2 ou vraptor.

os 2 são bons, caso queria algo usa servlet puro.

#3

ouvi falar que o struts esta meio ultrapassado, então resolvi dar uma olhada depois…

já o VRaptor dizem que é bom, dei uma olhada na documentação do site, consigo
usar apenas request, sem sessão, com ele?

#4

brother, struts 2 está bem legal, qualquer framework de controle vc consegue usar só request, só basta vc querer.

indicaria usar só Servlet sem framework.

#5

[quote=gilbueno]já o VRaptor dizem que é bom, dei uma olhada na documentação do site, consigo
usar apenas request, sem sessão, com ele?[/quote]

Consegue sim. O padrão nesses frameworks Action Based (VRaptor, Struts, Spring MVC etc) é que as coisas tenham escopo de request. Se você quiser Session você precisa indicar explicitamente, mas mesmo assim não é a mesma coisa do JSF te levar a por tudo na sessão.

Eu uso VRaptor em um projeto aqui, pra você ter ideia, que tem as Sessions desabilitadas no servidor. Nesse projeto, nem que eu queira, não posso usar sessão. E funciona que é uma maravilha

#6

Engraçado, sempre utilizei JSF com meus backbeans sempre no escopo de request e não tive problemas. Qual a dificuldade que o pessoal costuma ter? Onde é a perda de produtividade dele?

Não estou duvidando, é curiosidade mesmo.

#7

Já que é para trabalhar apenas com request,
utilize de vez apenas Servlets e crie o seu Front Controller
do jeito que deseja.

#8

[quote=marcosalex]Engraçado, sempre utilizei JSF com meus backbeans sempre no escopo de request e não tive problemas. Qual a dificuldade que o pessoal costuma ter? Onde é a perda de produtividade dele?

Não estou duvidando, é curiosidade mesmo.[/quote]

Ok, seus backing beans ficam em request. Mas onde você tá guardando o ViewState?

#9

pensei em usar apenas servlets, mas com o JSF por exemplo eu tenho uma comodidade na segurança,
alguem recomenda algum modo de usar servlets e se preocupar menos com injections e segurança em geral?

tenta popular um <h:selectOneMenu/> populado por uma lista de objetos em tempo de execução,
qnd vc seleciona este objeto vai dar erro de validação, dae vc tem q implementar o equals, implementar hashcode, implementar um converter, implementar um phaselistener, e no fim vai perceber que não serviu pra nada e vai ter q fazer uma gambiarra em javascript hauHAUhauHAUH

existem diversos outros exemplos

#10

struts 2

#11

[quote=Sergio Lopes]
Ok, seus backing beans ficam em request. Mas onde você tá guardando o ViewState?[/quote]

Desculpa a ignorância, mas nunca usei o ViewState. Vejo ele sendo passado como um parâmetro hidden, mas em que situação eu precisaria dele fora de uma chamada de request?

Deixa ver se eu entendi, eu teria um componente que conforme clicasse, ele popularia meu selectOneMenu dinamicamente.

Eu faço isso com richfaces utilizando o reRender. Tem alguma situação que pode dar problemas?

#12

eu não uso richfaces, não sei responder esta, mas aí está uma questão:

“será q trabalhando com richfaces, primefaces, etc pode aumentar minha produtividade usando apenas RequestScope?”

#13

Uma maneira de trabalhar apenas c/ Request é utilizando o KeepAlive e respondendo a outra duvida voce pode sim aumentar sua produtividade.

#14

[quote=marcosalex][quote=Sergio Lopes]
Ok, seus backing beans ficam em request. Mas onde você tá guardando o ViewState?[/quote]

Desculpa a ignorância, mas nunca usei o ViewState. Vejo ele sendo passado como um parâmetro hidden, mas em que situação eu precisaria dele fora de uma chamada de request?
[/quote]

Se você nunca mexeu nele, chances são de que você está nas configurações padrões do javax.faces.STATE_SAVING_METHOD, o que significa que toda sua árvore de componentes (o tal ViewState) está sendo guardado na sessão no seu servidor.

Provavelmente o campo hidden chamado ViewState que você vê no seu HTML é apenas um id, certo? Esse id aponta para algo na Session no servidor. E aí, mesmo você tendo todos os seus beans em request, você usa Session e temos os problemas de escalabilidade, performance e gerenciamento de estado que o amigo falava antes.

Um teste pra você ter dimensão do problema é criar um novo <context-param> no seu web.xml com o nome de javax.faces.STATE_SAVING_METHOD e colocar o valor “client” (o padrão é “server”). Aí dá uma olhada no campo ViewState hidden novamente.

#15

Eu até tinha esquecido deste “detalhe”!
corri pra um projeto meu que só pode ser Request para checar, ainda bem que mudei:

<context-param>
        <description>
            State saving method: "client" or "server" (= default) See
            JSF Specification 2.5.2
        </description>
        <param-name>javax.faces.STATE_SAVING_METHOD</param-name>
        <param-value>client</param-value>
    </context-param>

…

vou pesquisar sobre este keepAlive, é do richFaces? não usa sessão mesmo? =)

#16

Um bom exemplo de funcionamento do keepAlive

http://mkblog.exadel.com/2009/07/view-scope-in-richfaces/

Quanto ao fato da escalabilidade ao utiliza-lo eu não sei dizer.

#17

[quote=Sergio Lopes]
Se você nunca mexeu nele, chances são de que você está nas configurações padrões do javax.faces.STATE_SAVING_METHOD, o que significa que toda sua árvore de componentes (o tal ViewState) está sendo guardado na sessão no seu servidor.

Provavelmente o campo hidden chamado ViewState que você vê no seu HTML é apenas um id, certo? Esse id aponta para algo na Session no servidor. E aí, mesmo você tendo todos os seus beans em request, você usa Session e temos os problemas de escalabilidade, performance e gerenciamento de estado que o amigo falava antes.

Um teste pra você ter dimensão do problema é criar um novo <context-param> no seu web.xml com o nome de javax.faces.STATE_SAVING_METHOD e colocar o valor “client” (o padrão é “server”). Aí dá uma olhada no campo ViewState hidden novamente.[/quote]

Nunca mexi, meu campo hidden da ViewState é uma string gigante.

Procurei nos meus arquivos de configuração e essa propriedade estava como client. Ou alguém da equipe setou ou foi o próprio netbeans.

Beleza, deu pra esclarecer as dúvidas, vou pesquisar mais sobre isso e as implicações. Talvez os componentes do richfaces que tiveram de implementar o “trabalho sujo” ou que eu nao tenha me deparado com uma situação que atrapalhe. Ou ainda que eu tenha deixado de programar de uma maneira mais simples alguma situação, sei la!

Valeu a todos pelas explicações.

#18

[quote=marcosalex]Nunca mexi, meu campo hidden da ViewState é uma string gigante.

Procurei nos meus arquivos de configuração e essa propriedade estava como client. Ou alguém da equipe setou ou foi o próprio netbeans.

Beleza, deu pra esclarecer as dúvidas, vou pesquisar mais sobre isso e as implicações. Talvez os componentes do richfaces que tiveram de implementar o “trabalho sujo” ou que eu nao tenha me deparado com uma situação que atrapalhe. Ou ainda que eu tenha deixado de programar de uma maneira mais simples alguma situação, sei la!

Valeu a todos pelas explicações.[/quote]

Essa String gigante é o estado da tela serializado no cliente, gastando banda a torto e a direita, sobrecarregando a página no cliente, e metralhando o servidor com processamento ao serializar/desserializar essa String a cada request.

A outra opção seria jogar no server, onde guardaria a mesma informação na HttpSession, explodindo a memória do Server e trazendo problemas de escalabilidade e disponibilidade.

Não que o JSF seja ruim, mas é preciso saber os tradeoffs. O JSF é um framework Stateful, não há opção. Para guardar esse estado, alguém vai sofrer (client ou server). Mas muitas vezes Stateful não é tão importante para você ou você tem problemas maiores de performance ou escalabilidade, e precisa de uma solução mais Web, mais natural ao HTTP, Stateless. É aí que entram os frameworks Action Based.

#19

hummm

acho q vcs me convenceram a não utilizar mais o JSF hehe, se bem que eu já estava com essa idéia na cabeça
dei uma olhada breve na documentação do VRaptor e percebi que ainda assim vcs utilizam uma página xml com
tags do JSP como por exemplo o <c:forEach/> e classes chamadas Controllers como se fossem os BackingBean do
JSF, então acho que não vai ser muito dificil de me acostumar

este framework é da Caelum certo? é brasileiro então? acho legal dar importancia para o que temos por aqui =)

vou ver tmb como rola com javascript, talvez eu use apenas servlets mesmo
não existe um framework baseado em javascript?

#20

Bom, não foi meu objetivo convencer ninguém :slight_smile:
Apenas mostrar as características de cada abordagem e jogar a bola pra cada programador, cada projeto, escolher a que for melhor.

Toda tecnologia tem seus pontos positivos e negativos. Não é o foco do tópico, mas eu podia ficar aqui “falando mal” de Spring, EJB, Struts, VRaptor, Servlets etc. Sempre há os pontos negativos, e o bom desenvolvedor é aquele que sabe pesar vantagens e desvantagens de cada coisa na hora de escolher as tecnologias pro projeto.

VRaptor é brazuca! Nasceu dentro da Caelum mas é um projeto opensource que conta com a ajuda de vários desenvolvedores (aqui do GUJ, inclusive).