Novo projeto, acho que o JSF não atende, tentei FLEX mas desisti, e agora?  XML
Índice dos Fóruns » Desenvolvimento Web
Autor Mensagem
rafaelbtz
Java Ninja
[Avatar]

Membro desde: 29/03/2005 10:53:56
Mensagens: 276
Offline

Boa tarde,

Aqui na empresa desenvolvemos vários projetos em JSF 1.2 e 2.0 com RichFaches e com PrimeFaces, e acho que ele tem várias vantagens e desvantagens também (que não vem a caso agora)

Porém surgiu um novo projeto de um cliente (uma rede grande de escolas de informatica/idiomas) (muito parecido com um ERP com muitas tabelas muitos cadastros e muitas listagens) onde os requisitos são: A interface tem que encantar o usuário e precisa suportar uma quantidade muito grande de acessos simultâneos.
Uma observação importante, na grande maioria do site o usuário não precisa estar logado para utilizar o sistema e não podem ocorrer erros de TimeOut de sessao logo vou ter que fazer tudo no escopo request, com muito inputHidem e precisaria configurar o JSF para gravar a arvore de componentes no Cliente e isso ja me desanima em fazer esse projeto em JSF.

Então estamos estudando novas tecnologias e fui dar uma estudada em FLEX, gostei muito fizemos uns mini projetos em Flex + BlazeDS + Spring + Hibernate e ficaram muito bons. Mas apesar de gostar muito da tecnologia desisti de utilizar depois de ler essa matéria da própria Adobe: http://blogs.adobe.com/flex/2011/11/your-questions-about-flex.html

E agora o que utilizar?

Pensei em Vraptor, dei uma breve olhada nele e gostei ai pensei em utilizá-lo com ExtJS. Sei que tem bastante gente usando e me pareceu interessante.

Ou então GWT com ExtGWT mas desse sei muito pouco.

Alguem poderia me aconselhar sobre mais alguma tecnologia? Ou qual das acima vocês utilizariam?

Muito Obrigado...

[Email]
guilhermehkr
JavaBaby
[Avatar]

Membro desde: 04/02/2011 14:26:43
Mensagens: 80
Localização: São Paulo
Offline

No meu ponto de vista, se deseja performance e escalabilidade usaria algum framework action based como springMVC ou afins.

me corrijam se estiver errado.
Obrigado.

Guilherme Gambeti
[Email]
erickfm8
GUJ Master

Membro desde: 06/10/2009 19:29:12
Mensagens: 1396
Offline

iria de EJB 3.1 e JSF 2 com PrimeFaces, participei de um ERP com essas Tecnologias , não tive problemas

Bacharel em Sistema de Informação
SCJP - Sun Certified Java Programmer
OCWCD - Oracle Certified Web Component Developer (Estudando..)
RafaelViana
GUJ Master

Membro desde: 23/03/2008 18:56:02
Mensagens: 1257
Localização: Venâncio Aires/RS
Offline

Estou fazendo um software para uma escola, usando Flex + BlazeDS + VRaptor + Hibernate.

P.S: Tempo de desenvolvimento 1 semana (+- 50h). Status do projeto: 75% pronto o/
Quando se aprende a trabalhar com Flex a produtividade é muito boa. E o VRaptor também tem uma produtividade boa.

Segue layout em anexo no post [eu pelo menos gostei do layout =) ]. Para mais informações, mande MP.
[Thumb - escola.png]
 Nome do arquivo escola.png [Disk] Download
 Descrição
 Tamanho 244 Kbytes
 Baixado:  64 vez(es)

This message was edited 1 time. Last update was at 04/01/2012 15:12:03


Rafael Rodrigues Viana
Estudando Java e Flex
Blog: http://www.cauirs.com.br/rafael/

"Any fool can write code that a computer can understand. Good programmers write code that humans can understand."
[Email] [MSN]
x@ndy
Virtual Machine Man
[Avatar]

Membro desde: 07/01/2011 12:39:32
Mensagens: 554
Localização: Porto Alegre
Offline

Cara, entendo seu problema e não vejo uma solução simples.
Você necessita de uma aplicação Cliente Rico em uma plataforma Web e isso sempre foi um problema. Das tecnologias que eu conheço, Flex ainda é a melhor mas por pouco tempo.

O problema é o HTML 5 que vai matar o Flex e não existe nada ainda em Html 5 que o substitua!!!!

Então o que fazer?

A meu ver, na sua situação, eu ia de Flex mesmo. E quando surgir uma nova ferramenta tão boa quanto, iniciaria uma refatoração. Se você programa separando as camadas corretamente, refatorar a camada de visualização seria muito rápido! A meu ver o ganho de produtividade ganho ao utilizar uma Flex compensa a refatoração futura, se é que isso vai ser necessário.

Mas claro que isso só vale se na visualização não conter nada de regra de negócio. O problema de Interfaces Cliente Rico é que toda a lógica de negócios acaba ficando nela o que inviabiliza qualquer refatoração. É o que o Eric Evans chama do "Anti Padrão Interface Com Usuario Inteligente"

This message was edited 1 time. Last update was at 04/01/2012 15:30:19


Software e Tecnologia:http://tekhton.blogspot.com
"Um software desprovido de contexto na base do seu design é, na melhor das hipóteses, um mecanismo que realiza coisas úteis sem explicar suas ações"
[MSN]
luistiagos
GUJ Expert
[Avatar]

Membro desde: 10/07/2006 10:37:23
Mensagens: 3161
Offline

se vc ja ta acostumado a usar jsf com rich e prime use-os...
se o teu problema é timeout de sessão coloque um -1 lá no web.xml no timeout da sessão... e pronto sua sessão é eterna nunca vai dar Timeout... porem a memoria não e eterna então vc vai ter que gerenciar isto de alguma forma, o mesmo seria se vc usasse flex ou qualquer outra coisa...




SCJP 1.5
SCJA 1.0
IBM DB2 Associate
[Email] [MSN]
rafaelbtz
Java Ninja
[Avatar]

Membro desde: 29/03/2005 10:53:56
Mensagens: 276
Offline

RafaelViana,

Eu também achei o Flex muito bom e produtivo, apesar de achar também que ele tem alguns probleminhas mas enfim toda tecnologia tem pros e contras e pesando os prós e os contras do Flex eu acho que agente acabaria escolhendo ele mesmo.

O problema está sendo o posicionamento da Adobe com o Flash Player. Veja no link que eu passei no primeiro post que até mesmo a adobe não está aconselhando a usar o Flex:

A Adobe recomenda o uso do Flex ou HTML5 para o desenvolvimento de aplicativos empresariais?

No longo prazo, acreditamos HTML5 será a melhor tecnologia para o desenvolvimento de aplicativos empresariais


Entre outras noticiais como por exemplo essa: http://googlegeodevelopers.blogspot.com/2011/09/maps-api-for-flash-deprecation.html?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+GoogleGeoDevelopersBlog+%28Google+Geo+Developers+Blog%29
Onde o Google diz que está descontinuando o Google Maps Api for Flash.

Também tem essa aqui no GUJ mesmo: http://www.guj.com.br/java/262056-flex-e-aceito-na-fundacao-apache#1369180


Assim fica difícil de escolher o FLEX para novos projetos comerciais hoje em dia.
[Email]
rafaelbtz
Java Ninja
[Avatar]

Membro desde: 29/03/2005 10:53:56
Mensagens: 276
Offline

x@ndy wrote:
O problema é o HTML 5 que vai matar o Flex e não existe nada ainda em Html 5 que o substitua!!!!


Falou tudo, esse é o problema mesmo...

E esse ExtJS, eu sei que não substitui nem é pra isso mas me pareceu bom. Alguém já usou, pode dizer o que achou? É muito pesado ou muito grande, roda bem em vários Browsers?
Vi inclusive uma interface gráfica para ele: http://www.sencha.com/products/designer/ que também me pareceu legal

This message was edited 1 time. Last update was at 04/01/2012 15:53:01

[Email]
RafaelViana
GUJ Master

Membro desde: 23/03/2008 18:56:02
Mensagens: 1257
Localização: Venâncio Aires/RS
Offline

ExtJS deve-se pagar licença para usar em aplicativos comerciais.

Melhor frase que já ouvi sobre o assunto:

Rafael Rodrigues Viana
Estudando Java e Flex
Blog: http://www.cauirs.com.br/rafael/

"Any fool can write code that a computer can understand. Good programmers write code that humans can understand."
[Email] [MSN]
FernandoFranzini
GUJ Master
[Avatar]

Membro desde: 24/04/2009 12:58:16
Mensagens: 1541
Offline

Segue minha opinião....

A interface tem que encantar o usuário

JSF deixa livre a estilização com CSS do template das GUI's. Ou seja, o web designer da solução é responsável por elaborar e fazer esse "encantamento" ai. Tomar de decisão de excluir JSF a partir dessa justificativa é incoerente para mim. Talvez vc não tenha encontrando componentes de terceiros de JSF que tenha esse visual mas isso não te impede de implementar os seus proprios..

e precisa suportar uma quantidade muito grande de acessos simultâneos.

Escalabilidade de uma solução não tem relação nenhuma com a tipo/filosofia das múltiplas possíveis camadas de apresentação que uma solução pode ter. Escalabilidade tem haver com outros tópicos....Mais uma vez, excluir JSF a partir dessa justificativa é incoerente para mim.

quantidade muito grande de acessos simultâneos..quantos?

Minha maior solução hoje usa JSF com 10 usuários habilitados , com media de 1000 usuários simultâneos 24 HS rodando lindo e maravilhosamente num LINUX com 3GB + tomcat + SQL Server.

This message was edited 1 time. Last update was at 04/01/2012 16:10:39


Fernando Franzini
[Email] [WWW]
rafaelbtz
Java Ninja
[Avatar]

Membro desde: 29/03/2005 10:53:56
Mensagens: 276
Offline

FernandoFranzini wrote:Segue minha opinião....

A interface tem que encantar o usuário

JSF deixa livre a estilização com CSS do template das GUI's. Ou seja, o web designer da solução é responsável por elaborar e fazer esse "encantamento" ai. Tomar de decisão de excluir JSF a partir dessa justificativa é incoerente para mim. Talvez vc não tenha encontrando componentes de terceiros de JSF que tenha esse visual mas isso não te impede de implementar os seus proprios..

Acho que eu me expressei mal, eu não descarto o JSF por esse motivo. Apesar de saber que vai dar um tantinho de trabalho a mais (ja apanhei demais tentando alterar o CSS dos componentes do PrimeFaces) mas pra ficar com a mesma cara do FLEX o trabalho vai ser grande.


FernandoFranzini wrote:
e precisa suportar uma quantidade muito grande de acessos simultâneos.

Escalabilidade de uma solução não tem relação nenhuma com a tipo/filosofia das múltiplas possíveis camadas de apresentação que uma solução pode ter. Escalabilidade tem haver com outros tópicos....Mais uma vez, excluir JSF a partir dessa justificativa é incoerente para mim.

quantidade muito grande de acessos simultâneos..quantos?

Minha maior solução hoje usa JSF com 10 usuários habilitados , com media de 1000 usuários simultâneos 24 HS rodando lindo e maravilhosamente num LINUX com 3GB + tomcat + SQL Server.

Já quanto a escalabilidade do JSF isso sim eu acho mais complicado, não que seja impeditivo, mas você deve convir que uma solução ActionBased como o VRaptor é mais leve nesse sentido. Eu ainda não tenho um número mas a empresa tem aproximadamente 800 unidades coloque ai no mínimo 10 alunos utilizando vc já tem 8.000 acessos.

Posso estar errado mas quando eu vejo que um site vai ser MUITO mais baseado em requisições GET me parece mais apropriado utilizar Action-Based certo? Sei que no JSF 2 as requisições GET ficaram bem mais fácil mas ainda assim me parece que utilizar JSF só com GET e trafegando a arvore de componentes até o cliente para evitar os ViewExpirateException é um pouco estranho.


Por exemplo tem processos que serão formados por quatro paginas.
1. Busca (formulário onde o usuário informa várias informações de busca)
2. Lista com Resultado da Busca
3. Lista com as Opções do produto selecionado na pagina 2.
4. Confirmação da seleção do usuário.

Todas as paginas devem poder ser adicionadas ao Favoritos, ou seja todas as requisições entre as paginas devem ser feitas em GET, colocando os parâmetros na URL. Sei que da pra fazer com JSF 2 mas você concorda que esse não é o uso normal do JSF.






This message was edited 3 times. Last update was at 04/01/2012 16:53:55

[Email]
rogeriopaguilar
JavaTeenager
[Avatar]

Membro desde: 31/05/2006 10:19:35
Mensagens: 171
Offline

Bom, eu me lembro que o portal do aluno (e-campus) da cultura inglesa quando eu utilizava (estudei lá até o final do ano passado) era todo feito em jsf e eu acredito que deva existir muitos acessos, apesar que muitos alunos não faziam as tarefas do e-campus

Outro que é feito em jsf e tem acesso pra caramba é o home-banking do bradesco.


https://github.com/rogeriopaguilar/Projetos
[Email] [WWW] [MSN]
x@ndy
Virtual Machine Man
[Avatar]

Membro desde: 07/01/2011 12:39:32
Mensagens: 554
Localização: Porto Alegre
Offline

FernandoFranzini wrote:Segue minha opinião....

A interface tem que encantar o usuário

JSF deixa livre a estilização com CSS do template das GUI's. Ou seja, o web designer da solução é responsável por elaborar e fazer esse "encantamento" ai. Tomar de decisão de excluir JSF a partir dessa justificativa é incoerente para mim. Talvez vc não tenha encontrando componentes de terceiros de JSF que tenha esse visual mas isso não te impede de implementar os seus proprios..


Na minha opnião, mesmo usando CSS e JSF é complicado desenvolver uma interface rica para web realmente. Estou acostumado a desenvolver sistemas desktop e até hoje, com exeção do flex, não encontrei nada que me permitise desenvolver aplicações web realmente ricas. JSF é muito bom, tem uma pá de componentes legais para ele, mas ainda não é a mesma coisa.

A meu ver o Html 5 vai acabar com isso, permitindo clientes ricos para interface web matando o desenvolvimento para desktop, o que vai sobrar são somente aplicações específicas. Mas até surgirem ferramentas para o HTML 5, o pessoal fica na mão.

PS:
Complementanto o que o HTML 5 é capaz, segue abaixo um video de um jogo feito nele:

http://www.youtube.com/watch?feature=player_embedded&v=dFdb3GvJin0

This message was edited 1 time. Last update was at 04/01/2012 16:48:42


Software e Tecnologia:http://tekhton.blogspot.com
"Um software desprovido de contexto na base do seu design é, na melhor das hipóteses, um mecanismo que realiza coisas úteis sem explicar suas ações"
[MSN]
RafaelViana
GUJ Master

Membro desde: 23/03/2008 18:56:02
Mensagens: 1257
Localização: Venâncio Aires/RS
Offline

Se o sistema é para o acesso dos alunos, esquece o Flex!

1) Você terá muitos problemas com o cache do navegador. Porque se você marcar para não usar cache, fica inviável toda vez o aluno baixar 600KB ~ 800 KB. Existe uma "técnica" para carregar somente quand houver uma nova versão, mas, se ocorrer uma falha de conexão durante o download da aplicação, só limpando o cache para a aplicação abrir novamente. Imagina o transtorno disso?

2) Para esse perfil de usuário, é interessante permitir o acesso via smartphone/tablet, por exemplo: estão indo para o curso e no caminho podem olhar o material da aula, ver se tem aviso do professor, ... Isso o Flex não irá te permitir.

Estou usando o Flex para a camada administrativa, porque é a linguagem que eu domino e o prazo era super apertado. Mas, a seção para o acesso dos alunos , utilizarei a mesma estrutura do VRaptor, mas trocarei o front-end por HTML + CSS + JS. (E se funcionar bem, trocarei também a parte administrativa para HTML).

Infelizmente, mesmo sendo entusiasta de Flex, sei das dificuldades dele.

Para quem acha que HTML não consegue layout semelhantes ao Flex sugiro que vejam o site: http://themeforest.net/category/site-templates/admin-templates

Os layouts são melhores do que qualquer aplicação Flex que já vi.

Rafael Rodrigues Viana
Estudando Java e Flex
Blog: http://www.cauirs.com.br/rafael/

"Any fool can write code that a computer can understand. Good programmers write code that humans can understand."
[Email] [MSN]
FernandoFranzini
GUJ Master
[Avatar]

Membro desde: 24/04/2009 12:58:16
Mensagens: 1541
Offline

Vai algumas considerações....
Acho que eu me expressei mal, eu não descarto o JSF por esse motivo. Apesar de saber que vai dar um tantinho de trabalho a mais (ja apanhei demais tentando alterar o CSS dos componentes do PrimeFaces) mas pra ficar com a mesma cara do FLEX o trabalho vai ser grande.

Bom, nesse caso vc precisa de mão de obra mais capacitada..eu trabalho em empresas que usam componentes JSF puro e customizam o CSS, outras que usam CSS padrão de terceiros e até que criaram seus próprios componentes.

800 unidades coloque ai no mínimo 10 alunos utilizando vc já tem 8.000 acessos.

Numero de unidades e alunos existentes não corresponde necessariamente aos acessos simultâneos a solução. Isso é sua margem, tenha certeza que vc nunca terá 8 mil sessões simultâneas nesta solução.

Já quanto a escalabilidade do JSF isso sim eu acho mais complicado, não que seja impeditivo, mas você deve convir que uma solução ActionBased como o VRaptor é mais leve nesse sentido.

A diferença não é tanta assim. O JSF controla o objetos singleton dos objetos em sessão. Muito pouca coisa....eu realmente não sei.
Outra coisa, para vc deixar o JSF mais stateless, armazenar a arvore de objetos dentro na pagina o invés da sessão. Isso é perfeitamente aceitável e possível, desde que vc trate adequadamente certas "issues" desta opção situações.

utilizar JSF só com GET e trafegando a arvore de componentes até o cliente para evitar os ViewExpirateException é um pouco estranho.

trafegar a arvore de componentes até o cliente para evitar os ViewExpirateException é errado mesmo. Armazenar a arvore na pagina ou no server é decisão que não se relaciona com a desvio da ViewExpirateException. Ou seja, quem faz isso ta fazendo uma coisa errada. ViewExpirateException deve ser tratado dentro da solução. Hoje é muito facil tratar isso em qualquer versão do JSF.

Sei que da pra fazer com JSF 2 mas você concorda que esse não é o uso normal do JSF.

No JSF 1.2 não é! Mas no JSF 2 é sim. A especificação 2.0 contempla isso sim. Pode usar.

Quero deixar claro Rafael que eu não estou defendo JSF ou outra coisa. Estou apenas te ajudando a ver o pros e contras para vc possa tomar a melhor decisão.
Algo que eu poderia te acrescentar é que vc tem que fazer o validação arquitetural usando algo que vc não tenha certeza. Por exemplo...se vc tem duvidas que é estranho usar uma aplicação JSF 2 com get + a arvore na pagina. Faça um teste arquitetural e levante os pros e contras. Esse é o trabalho de um arquiteto

Fernando Franzini
[Email] [WWW]
 
Índice dos Fóruns » Desenvolvimento Web
Ir para:   
Powered by JForum 2.1.8 © JForum Team