Novo projeto, acho que o JSF não atende, tentei FLEX mas desisti, e agora?

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.

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

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.

2012/1/4/d2d20feefd8cfa90ea5b1f327e6cde5b_38276.png_1366×768 244 KB

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”

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…

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:

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+(Google+Geo+Developers+Blog)
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.

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

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

Melhor frase que já ouvi sobre o assunto:

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

Segue minha opinião…

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…

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.

FernandoFranzini:

Segue minha opinião…

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…

FernandoFranzini:

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.

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.

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.

FernandoFranzini:

Segue minha opinião…

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

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.

Vai algumas considerações…

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.

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.

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.

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.

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

Que isso… muito bom ouvir seus argumentos sobre o JSF. Como trabalhei pouquissimo com ele, é bom saber esses prós e contras.

Não conheço a arquitetura dos componentes do JSF, mas se ele permite customizações fica facinho deixá-lo com a cara de aplicativos Flex, como disse antes, atualmente, tenho vistos aplicações mais “bonitas” em HTML do que em Flex. Usar Flex só porque é mais bonito, hoje em dia não é mais um argumento válido.

Esses dias estava vendo a biblioteca Primefaces, contem muito mais componentes ( até acho que melhores ) do que o padrão do Flex.

Enfim, decidir qual tecnologia usar é a parte mais complicada de um projeto. (na minha opinião). Como o Fernando disse, crie um projeto usando JSF configure o JMeter e faça um teste de carga na aplicação veja se ela aguenta. Faça o mesmo com outras tecnologias que você está avaliando. No final, decida qual a tecnologia adotar.

Eu não uso flex por 1 motivo - portabilidade.

• Minhas solução precisam ser acessados por dispositivos moveis com navegadores sem capacidade de ter o plugin do flex. Eu prefiro perder um pouco de tempo customizando componentes CSS tendo um visual razoável e ter portabilidade do que ter uma aplicação linda maravilhosa sem portabilidade. Como sempre a decisão arquitetural da solução é baseada em requisitos…
  JSF renderiza HTML puro padrão W3C 100% portável para qualquer navegador W3C compatível.
  Para aplicações internas corporativas, flex pode ser uma boa no qual vc tem controle das plataformas e navegadores de uso. Mas para aplicações publicadas na internet que é meu caso vc restringe muito…realmente impraticável.

Outra coisa…cuidado com esse papo de “interfaces lindas” ! Isso não é considerado requisito…isso é frescura e papo de usuário final. Requisitos de interfaces são:

• Ergonômica
• Fácil
• Intuitiva
• Evitar propensão a erros
• Agradável
• Funcional…
  O resto é frescura .

Fernando obrigado por seus argumentos, mas deixa eu comentar algumas coisas, veja que eu também não estou tacando pedras no JSF afinal eu tenho pelo menos uns 8 projetos que estão em desenvolvimento em JSF 2 + Prime. Mas eu ainda acho que esse projeto não se encaixa no JSF.

FernandoFranzini:

Vai algumas considerações…
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.

Nesse caso a conta é mais ou menos essa, veja bem o sistema não é um controle de alunos. É um ERP-Escola que vai ser usado em sala de aula para ensinar Administração de Empresa que é um novo curso que a rede de escolas vai oferecer, então cada sala tem uns 30 alunos e todos estão utilizando ao mesmo tempo pois estão seguindo as aulas com o professor logo acredito que no mínimo 10 dessas requisições chegarão ao mesmo tempo no servidor. Mas tudo bem como eu disse acho a escalabilidade o menor dos problemas que eu vou enfrentar com o JSF.

Quando eu digo trafegar a arvore de componentes quero dizer Armazenar a arvore na pagina, afinal ela vai ter que ser trafegada até o cliente (ou seja definir o parametro javax.faces.STATE_SAVING_METHOD para client), sinceramente eu não gosto nada dessa opção já tive problemas com ela, além de aumentar o consumo da Banda ainda prejudica a segurança da aplicação.
Agora se eu armazenar a arvore no SERVER com certeza vou ter o ViewExpirateException. Eu sei que é possível tratar e mandar o usuário pra alguma pagina mas isso não é o que eu quero.

Por exemplo: Como eu expliquei antes são quatro paginas com requisição GET para fazer um unico processo imagina que o usuário selecionou os dados em duas delas e está sendo exibida a terceira pagina ai ele pára e vai almoçar. Quando ele voltar do almoço vai clicar no link que está no data-table da terceira pagina, se a arvore estiver no SERVER vai dar ViewExpirateException a não ser que eu jogue o timeout da sessao para -1, mas isso acho muito pior que colocar a arvore na pagina.
Então perceba que minha única solução é colocar a arvore de componentes na página e trafegá-la até o cliente em todas as requisições e isso eu não estou querendo fazer, veja que em um Framework Action-Based esse já é o comportamento padrão e eu não preciso fazer nada pra funcionar.

Como eu disse, eu sei que JSF 2 contempla, mas você precisa no mínimo de umas gambiarrinhas vai.
Por exemplo caso use navegação direto pelo retorno do método do ManagedBean vc precisa colocar no final da String ‘?faces-redirect=true’ ou as vezes ‘faces-redirect=true&includeViewParams=true’
Até da, mas de novo comparando com um ActionBased o JSF perde nesse sentido

Que isso, você está ajudando bastante, é discutindo que agente aprende.
Quero colocar aqui o meu ponto de vista, dizendo de novo que eu uso bastante o JSF.

Na minha opnião, quando você vai desenvolver um aplicativo WEB onde por exemplo a primeira coisa que acontece é o login do usuário (como um HomeBanking) o JSF se mostra uma opção muito boa mesmo eu sempre a uso JSF nesses casos.

Ja quando seu aplicativo é pra funcionar mais com requisições GET e o login vem por exemplo no final do processo (como por exemplo uma Loja Virtual) ai já não acho o JSF tão bom e prefiro algo mais ActionBased.

Quais serão meus passos daqui pra frente:
Do FLEX eu já desisti mesmo pra falar a verdade nem fui eu mas a diretoria do cliente depois de saber sobre a atitude da Adobe.

Estou aprofundando meus estudos no conjunto (Vraptor + Spring + Hibernate), para o front-end estou estudando ExtJS vou decidir entre ele e o JQuery +JqueryUI ou então JQuery + ExtJS.
Gostei bastante do que vi sobre o ExtJS, mas ainda não coloquei a mão pra saber.

Estou descartando o GWT + GWTJs. Dei uma rápida olhada mas não gostei muito do que vi.

Agora uma pergunta, e o JavaFX o que vocês acham? andei dando uma olhada no roadmap dele http://javafx.com/roadmap/ e vi que uma versão mas completa dele sai só la pra final de 2013. Mas tem alguem aqui que ta apostando nele? alguem já viu algum software mais empresarial (leia-se CRUD) com ele?

Eu vou reforçar meus estudos aqui, e vou postando minhas impressões, e vamos continuar a discussão pois acho que está bastante produtiva.

Navegação do JSF apartir da versão 2 o metodo de navegação que retorna uma String, só é preciso retornar o nome da pagina

ex: return “nomeDaPagina”;

que eu saiba não é preciso usar o ?faces-redirect=true

erickfm8:

Navegação do JSF apartir da versão 2 o metodo de navegação que retorna uma String, só é preciso retornar o nome da pagina

ex: return “nomeDaPagina”;

que eu saiba não é preciso usar o ?faces-redirect=true

É isso mesmo você só precisa retornar o endereço, MAS se você quiser que a URL no Browser seja alterada para o endereço da pagina destino (isso é obrigatório mo meu caso porque eu quero que a pagina possa ser adicionada ao favoritos do browser) ai você precisa fazer um REDIRECT e pra fazer isso no JSF vc precisa adicionar o ?faces-redirect=true, ou então usar os componentes <h:button> ou <h:link> direto com o outcome mas ai não da pra chamar uma action do ManagedBean.

E se você quiser que além de alterar o endereço ele ainda coloque os parametros da requisição na URL (faça uma consulta qualquer no google e olhe a url da pagina com os resultados) ai você precisa utilizar
'faces-redirect=true&includeViewParams=true

Fora que para ler os parametros passados na URL na pagina destino vc ainda vai precisar colocar no XHTML da pagina destino:

<f:metadata>
	<f:viewParam name="p1" value="#{diversosMB.p1}"/>
	<f:viewParam name="nome" value="#{diversosMB.nome}"/>
	<f:viewParam name="xpto" value="#{diversosMB.xpto}"/>

</f:metadata>

Com eu disse da pra fazer mas que é chato é.

Sinceramente, me parece que seu cliente esta viajando na batatinha. Se você quiser entrar na onda dele tente programar o maximo possivel da camada da UI usando javascript. Sua UI deve apenas se limitar em consumir os servicos disponibilizados pelo seu ERP (que pode ser qualquer coisa… VRaptor, Play, WebService, REST).

Nao sei como seu cliente (ou os analistas, sei lá) chegaram nestes brilhantes requisitos web. Mas fato é que se for para lutar contra o padrao, ou vocês devem cobrar muito caro pelo servico ou convenca eles de que o especilista em TI sao vocÊs, e nao eles. Se nao, eles mesmo fariam o sistema. Enfim… sinceramente nao entendo pq fazem tanta questao de navegar contra a maré.

UPDATED: Ou tente convencer seu cliente que o que ele precisa é de um sistema Desktop.

Thiago Senna:

Sinceramente, me parece que seu cliente esta viajando na batatinha. Se você quiser entrar na onda dele tente programar o maximo possivel da camada da UI usando javascript. Sua UI deve apenas se limitar em consumir os servicos disponibilizados pelo seu ERP (que pode ser qualquer coisa… VRaptor, Play, WebService, REST).

Nao sei como seu cliente (ou os analistas, sei lá) chegaram nestes brilhantes requisitos web. Mas fato é que se for para lutar contra o padrao, ou vocês devem cobrar muito caro pelo servico ou convenca eles de que o especilista em TI sao vocÊs, e nao eles. Se nao, eles mesmo fariam o sistema. Enfim… sinceramente nao entendo pq fazem tanta questao de navegar contra a maré.

UPDATED: Ou tente convencer seu cliente que o que ele precisa é de um sistema Desktop.

Bom pra falar a verdade eu também acho isso eles viajam mesmo. Porém tem um grande problema que eu não falei. Agente é uma fábrica de software subordinada a central da escola, ou seja, é tudo independente mas quem manda é a escola… então não da pra brigar muito, eles são clientes e patrões ao mesmo tempo entendeu…

Quanto ao fato de fazer a tela em Javascript é justamente isso que eu quero fazer, por isso estou começando a estudar ExtJS e integrá-lo com Json com o Vraptor. Eu ainda não entendo bem o ExtJS mas pelo pouco que eu vi ExtJS + JQuery vai fazer exatamente isso certo? Telas em Javascrip fazendo requisições e recebendo os dados em JSon não é?

Pois é… complicado essas coisas.

Flex para mim é algo fora de cogitacao. Até poderia ser uma boa opçao, mas parece que flash esta em queda junto com o flex. Entao é melhor evitá-lo. Outra alternativa talvez seja swing… pois sei q um bom tempo atras ele tinha um recurso onde vc poderia fazer o download e update do aplicativo online. Talvez seja uma opcao.

Mas pra mim, a melhor opcao pra mim ainda é JavaScript dado o seu cenário. Acho que você poderia dar uma olhada no ExtJS e talvez GWT (pois ele gera o cliente em javascript) também possa ajudar.

UPDATED: Sim… quando pensei em JS pensei em ExtJS + JSON também.

Thiago Senna:

Pois é… complicado essas coisas.

Flex para mim é algo fora de cogitacao. Até poderia ser uma boa opçao, mas parece que flash esta em queda junto com o flex. Entao é melhor evitá-lo. Outra alternativa talvez seja swing… pois sei q um bom tempo atras ele tinha um recurso onde vc poderia fazer o download e update do aplicativo online. Talvez seja uma opcao.

Mas pra mim, a melhor opcao pra mim ainda é JavaScript dado o seu cenário. Acho que você poderia dar uma olhada no ExtJS e talvez GWT (pois ele gera o cliente em javascript) também possa ajudar.

UPDATED: Sim… quando pensei em JS pensei em ExtJS + JSON também.

Eu pensei em Swing também utilizando o JAva Web Start, mas nesse caso não da. Eu já fiz sistemas com ele e pra falar a verdade o JWS é bom mas da uns probleminhas chatos.

Quanto ao GWT alguém já usou em algum projeto grande? Eu achei interessante o esquema de programação dele em classes Java, mas sei lá me parece que foge muito do padrão. O Ext pelo menos você programa direto os JS e os coloca nos arquivos HTML.

Cara se o problema é que eles querem uma app desktop em um mundo web… meta o Flexão sem dó e nem piedade, que para isto ele e sem duvidas brilhante!

Só sugeri o GWT pq talvez algumas pessoas prefiram programar em java e fechar uma arquitetura em cima do GWT… Se vocês se sentem confortáveis apenas com JS vai fundo usando apenas JS. Sobre usar GWT em projetos grandes eu nunca usei, mas ele daria conta do recado tranquilamente.

Na minha opinião, para fazer DESKTOP, na web eu figiria do FLEX !!!
Uma boa opção para fazer RIA com java é VAADIN - https://vaadin.com/home

• Robusto
• Tem suporte
• não precisa de plugin nenhum pq gera HTML/JAVASCRIPT
• Muitas pessoas usando (Java Black Belt - http://knowledgeblackbelt.com/)

Se fosse para fazer DESKTOP na web eu figiria do FLEX !!!
Uma boa opção para fazer RIA com java é VAADIN - https://vaadin.com/home

• Robusto
• Tem suporte
• não precisa de plugin nenhum pq gera HTML/JAVASCRIPT
• Muitas pessoas usando (Java Black Belt - http://knowledgeblackbelt.com/)
  

Dei uma olhada por cima nos demos e achei interesante esse vaadin. Vou testar em casa para ver se é produtivo como o flex. Pode ser uma solução até termos ferramentas HTML 5!

Se fosse para fazer DESKTOP na web eu figiria do FLEX !!!
Uma boa opção para fazer RIA com java é VAADIN - https://vaadin.com/home

• Robusto
• Tem suporte
• não precisa de plugin nenhum pq gera HTML/JAVASCRIPT
• Muitas pessoas usando (Java Black Belt - http://knowledgeblackbelt.com/)
  

Dei uma olhada por cima nos demos e achei interesante esse vaadin. Vou testar em casa para ver se é produtivo como o flex. Pode ser uma solução até termos ferramentas HTML 5!

Dei uma olhada nesse Vadin e nem fodendo que ele é mais produtivo que Flex. Alias se assemelha muito com Swing…

Se fosse para fazer DESKTOP na web eu figiria do FLEX !!!
Uma boa opção para fazer RIA com java é VAADIN - https://vaadin.com/home

• Robusto
• Tem suporte
• não precisa de plugin nenhum pq gera HTML/JAVASCRIPT
• Muitas pessoas usando (Java Black Belt - http://knowledgeblackbelt.com/)
  

Dei uma olhada por cima nos demos e achei interesante esse vaadin. Vou testar em casa para ver se é produtivo como o flex. Pode ser uma solução até termos ferramentas HTML 5!

Dei uma olhada nesse Vadin e nem fodendo que ele é mais produtivo que Flex. Alias se assemelha muito com Swing…

Bom, mas se é parecido com swing, já é uma alternativa! Não é extremamente produtivo, mas é uma plataforma interessante de se adotar. Com certeza, em termos de UI, deve ser muito mais flexivel que JSF.

Se fosse para fazer DESKTOP na web eu figiria do FLEX !!!
Uma boa opção para fazer RIA com java é VAADIN - https://vaadin.com/home

• Robusto
• Tem suporte
• não precisa de plugin nenhum pq gera HTML/JAVASCRIPT
• Muitas pessoas usando (Java Black Belt - http://knowledgeblackbelt.com/)
  

Dei uma olhada por cima nos demos e achei interesante esse vaadin. Vou testar em casa para ver se é produtivo como o flex. Pode ser uma solução até termos ferramentas HTML 5!

Dei uma olhada nesse Vadin e nem fodendo que ele é mais produtivo que Flex. Alias se assemelha muito com Swing…

Tem um plugin para eclipse mas não sei como funciona. Na verdade tem que ser avaliado.
Fica a critério do nosso amigo julgar o requisito funcional mais importante para ele - PORTABILIDADE OU PRODUTIVIDADE?

FernandoFranzini:

Tem um plugin para eclipse mas não sei como funciona. Na verdade tem que ser avaliado.
Fica a critério do nosso amigo julgar o requisito funcional mais importante para ele - PORTABILIDADE OU PRODUTIVIDADE?

O que você esta considerando quando diz PORTABILIDADE ?

x@ndy:

FernandoFranzini:

Tem um plugin para eclipse mas não sei como funciona. Na verdade tem que ser avaliado.
Fica a critério do nosso amigo julgar o requisito funcional mais importante para ele - PORTABILIDADE OU PRODUTIVIDADE?

O que você esta considerando quando diz PORTABILIDADE ?

Acho que ele esta se referindo a dispositivos moveis… Porem rodar a app em dispositivos moveis tbm é um requisito?
Se for dai sim eu concordo… porem a outras coisas que terão que ser pensadas e avaliadas caso isto seja um requisito…

FLEX precisa de instalação de plugin no navegador e não esta disponível para qualquer dispositivo móvel dotado de um navegador W3C.
O objetivo do flex é aumentar a capacidade de se desenvolver interfaces ricas, mas todos nos ja sabemos que isso ja é possível com HTML 5.
Então começar 2012 u m projeto usando FLEX, tem que ser bem avaliado e o escopo bem alinhado.

FLEX precisa de instalação de plugin no navegador e não esta disponível para qualquer dispositivo móvel dotado de um navegador W3C.
O objetivo do flex é aumentar a capacidade de se desenvolver interfaces ricas, mas todos nos ja sabemos que isso ja é possível com HTML 5.
Então começar 2012 u m projeto usando FLEX, tem que ser bem avaliado e o escopo bem alinhado.

Pode ser que seja possivel com HTML 5 mas a questão é existe alguma ferramenta que te de produtividade assim como se tem no Flex usando HTML 5? Da pra fazer as coisas na unha, porem isto já cai no conceito de produtividade… Alias algo bom pra se fazer, uma IDE ou um plugin do Eclipse que de uma produtividade próxima a que o Flex costuma dar… A ideia é boa, e provavelmente renda com a decadencia do Flex… o problema é ter tempo para se fazer isto.

Correto…ainda não tem. Dilema complicado! kkkk
Mas podemos esperar provedores de componentes JSF gerando HTML 5 logo logo…

Esse Vaadin parece bom também ein. Eu tinha dado uma olhada nele quando saiu uma matéria sobre ele na JavaMagazine e tinha até me esquecido dele.
Vou estudar também.

O único porém dele é essa questão de programar em Java semelhante ao GWT. Mas é uma opção. Meu medo nisso ai é a curva de aprendizado para novos funcionários na equipe

Bom, no caso dele acreito que isso não se aplica. Pois a maior limitação ao flex é que ele “roda em cima do flash”, por assim dizer, e temos um problema com o flash para disposítivos móveis!
Como o que ele quer fazer é um ERP que vai ser usado pelo setor administrativo e em sala de aula pelos alunos, não creio isso seja um impeditivo, mesmo que isso exija a instação de do plugin do flash.

Uma coisa que tem que ser destacada nesse tipo de portabilidade é que se eu vou desenvolver para dispositivos móveis, não posso considerar que por que eu adotei a arquiteura X que usa HTML/CSS/JavaScript ou HTML 5 que vou ter um sistema portável. Uma UI para desktop é totalmente diferente de uma UI para um dispositivo móvel. Nos dispositivos móveis temos limitação de espaço de tela, de teclado e do mouse. Então uma UI pensada para Desktop não se aplica para um dispositivo móvel, mesmo que a arquitetura utilizada permita isso.
Neste casos provalmente teremos duas Telas, uma pensada para o desktop e outra pensada para o dispositivo móvel (por isso que é tão importante separar a logica do dominio da visulização).

Se temos duas formas de visualição e nosso sistema esta separado em camadas, nada impede que eu utilize duas formas de criar as UI

FernandoFranzini:

O objetivo do flex é aumentar a capacidade de se desenvolver interfaces ricas, mas todos nos ja sabemos que isso ja é possível com HTML 5.
Então começar 2012 u m projeto usando FLEX, tem que ser bem avaliado e o escopo bem alinhado.

Bom, isso todo mundo sabe, o problema, como eu já disse antes, é que o HTML 5 esta matando o flex mas ainda não existe nenhuma ferramenta madura o suficiente que o substitua.

Na verdade acretido que o suporte a Flex/Flash vai perdurar um bom tempo (acredito que pelo menos uns 5 a 8 anos) de modo que isso não impede que um sistema seja feito com essa tecnologia, deste que se tenha uma boa separação das camadas de modo que se possa facilmente refatorar a UI para outra tecnogia!

Uma coisa que tem que ser destacada nesse tipo de portabilidade é que se eu vou desenvolver para dispositivos móveis, não posso considerar que por que eu adotei a arquiteura X que usa HTML/CSS/JavaScript ou HTML 5 que vou ter um sistema portável. Uma UI para desktop é totalmente diferente de uma UI para um dispositivo móvel. Nos dispositivos móveis temos limitação de espaço de tela, de teclado e do mouse. Então uma UI pensada para Desktop não se aplica para um dispositivo móvel, mesmo que a arquitetura utilizada permita isso.
Neste casos provalmente teremos duas Telas, uma pensada para o desktop e outra pensada para o dispositivo móvel (por isso que é tão importante separar a logica do dominio da visulização).

Nestes casos, o arquiteto deve colocar uma camada facade entre a camada de visão e a camada de dominio, para centralizar e reutilizar responsabilidades de uma possivel variação intercambial de camada de apresentação.

Na minha solução temos múltiplas camadas de visão - JSF, JSF Mobile e SOAP conversando com a mesma camada facade que intermedia a camada de negocio…se que é vc me entenderam kkkkk

Sobre essa confusão…

Eu tenho usado o Flex com Java e tenho gostado muito, me preocupei um pouco qdo cogitaram o “fim” do Flex… apesar de não acreditar num FIM, resolvi tentar usar o JSF (Primefaces), gostei dos exemplos q vi e consegui fazer umas besteiras usando o NetBeans, mas agora por ex, tentando fazer algo no Eclipse (por conta do JBOSS 7.1), n vai… ontem fiz um projeto teste, funcionou, daí iniciei outro projeto, pronto… os obetos simplesmente não aparecem! Daí resolvi testar a mesma coisa no NetBeans (GlassFish 3.1) e funciona… isso que eu acho meio f… parece q a coisa tem vida própria rs, isso causa uma perda de tempo do caramba.