Arquivo Discussoes de Programacao e Tecnologia Pessoal, estou vendo diversas empresas seguirem a linha Java e algumas estão optando por Java Server Faces, em um evento da Oracle a alguns dias a Oracle mostrou que apostará fortemente em JSF, pergunta:
Vocês já trabalham com JSF
Eu utilizo webwork como controlador com JSF é melhor continuar com WebWork ou eu usaria outro controlador, ainda não entendi direito o conceito de JSF, mas utilizaríamos páginas JSP na view? Alguém que trabalha com JSF pode explanar um pouco sobre o assunto?
[size=24][color=red]Não!!![/color][/size]
Se Deus quiser, não…
Deixando deus de lado, acho que é o futuro nas empresas sim. Elas se sentem confortáveis usando padrões, e com o suporte que as IDEs fornecerão a transição struts > jsf será mais rápida.
Mas aqui continuaremos a usar WebWork \o/
IMHO, infelizmente acho que sim. JSF deve ficar com o mercado que hj é do struts, trabalhando com ele num primeiro momento e depois substiundo-o totalmente.
Tomara que a integração dele com spring/hibernate seja tranquila…
[]'s
Mas o JSF trabalha em que nível do MVC???
Se alguém se lembra do debate no CJ’05 vai lembrar que eu falei sobre como EJB foi projetado apra ser utilizado através de ferramentas, e como essa “complexidade escondida” não funciona.
Eu nãoa credito em JSF, mas acredito que como em EJB, vai demorar algum tempo pra quebrarem a cara.
Mas como já dizia João Sérgio
JSF está para o Java assim como o ASP.NET está para o .NET - você vai ter algo cujo “time-to-market” é menor, mas cuja mantenabilidade é pior.
Mas como o “time-to-market” é normalmente muito importante para as empresas (de qualquer maneira depois que o sistema está pronto, elas jogam o sistema fora mesmo 
), então acho que o JSF vai ter sim muita aceitação.
A Sun e a Oracle sabem muito bem disso - imagine-se na posição de um vendedor técnico da Sun ou da Oracle assistindo a uma demonstração de um produto .NET. Fica difícil vender uma solução Java depois de o cliente assistir a uma demonstração do ASP.NET, se você não tiver algo para mostrar que seja tão rápido para fazer quanto uma tela do ASP.NET.
IMHO, infelizmente acho que sim. JSF deve ficar com o mercado que hj é do struts, trabalhando com ele num primeiro momento e depois substiundo-o totalmente.
Tomara que a integração dele com spring/hibernate seja tranquila…[]'s
andei brincando estes dias com JSF e ao utilizar o projeto jsf-spring fica tudo show de bola a integração
RI
IDEs - JSF.
-Jdevelloper ;
-JBuilder;
-JCreator;
Eclipse - Plugins:
MyEclipse;
Exadel Studio
NitorX
-Projeto Amateras
Acho que ninguem iria fazer alarde sem necessidade…
JSF já é o PRESENTE em grandes corporações para construção de Front-end.
JSF substitui sim o Struts, por nascer mais madura, e sua especificação ser elaborada também pelos criadores do anterior (Struts).
O Struts não irá deixar de existir, mas sua evolução ocorre no JSF.
A grande discussão de hj na verdade é a respeito de Portals, porém uma opnião comum entre os debatentes é que se deve usar JSF para o desenvolvimento das Portlets.
- RI
- JSF;
- MyFaces;
- ADF;
IDEs - JSF. -Jdevelloper ; -JBuilder; -JCreator;Eclipse - Plugins:
MyEclipse;
Exadel Studio
NitorX
-Projeto AmaterasAcho que ninguem iria fazer alarde sem necessidade…
o WSAD também tem editor de JSF
e o ADF Faced que vai ser a implementação de JSF da oracle ainda não esta pronto.
PS.: JCreator 2 EA ta show de bola!!! ta ficando muito bom, to só esperando lançarem o EA2
[color=red][size=18]PS2.: JSF funciona tri bem, é uma ótima especificação, mas não tentem desenvolver usando JSF sem uma ferramenta feita para isto pq isto vai ser menos produtivo do que com qualquer outro framework MVC, JSF foi criada para a utilização em ferramentas, para possibilitar desenvolvimento RAD para web em java, e concorrer com WebForms[/size][/color]
Assim, JSF tem uma idéia massa, mas eu só boto fé na especificação nova que vai finalmente integrar ele com JSP (mesmo que eu não saiba bem como eles vão fazer isso…).
É interessante pra fazer formulários complexos e nada mais. Ninguém vai fazer páginas e mais páginas usando JSF.
[color=red][size=18]JSF foi criada para a utilização em ferramentas, para possibilitar desenvolvimento RAD para web em java, e concorrer com WebForms[/size][/color]
Uhm…onde é que eu já vi isso mesmo? Uhmmmm…ah é. EJB. 
Olá pessoal.
Estava fazendo uma busca sobre EJB + JSF e encontrei esse tópico. Posso estar enganado, mas hoje vejo que muitas pessoas estão buscando ainda mais (do que em 2005, época desse topico) por começar novos projetos utilizando JSF.
Já que muitas pessoas nesse tópico tinham uma opinião negativa quanto ao JSF e aproveitando que a grande maioria ainda está ativa no GUJ, acho que seria interessante reviver o tópico e ouvir a opinião atual dessas pessoas. E também do pessoal que apostou no JSF se realmente acha que acertou ou se foi uma furada.
Valeu.
Olá pessoal.Estava fazendo uma busca sobre EJB + JSF e encontrei esse tópico. Posso estar enganado, mas hoje vejo que muitas pessoas estão buscando ainda mais (do que em 2005, época desse topico) por começar novos projetos utilizando JSF.
Já que muitas pessoas nesse tópico tinham uma opinião negativa quanto ao JSF e aproveitando que a grande maioria ainda está ativa no GUJ, acho que seria interessante reviver o tópico e ouvir a opinião atual dessas pessoas. E também do pessoal que apostou no JSF se realmente acha que acertou ou se foi uma furada.
Valeu.
Ótima iniciativa. Também gostaria de ver a opinião atual do pessoal a respeito de JSF.Parabéns!
Eu gosto do JSF principalmente quando meu sistema precisa de componentes reutilizaveis e o sistema é component-based. Se os requisitos não exigirem isso, eu prefiro continuar com o Struts 2 + DWR.
Para algo menor, eu fico com o RoR.
Mas no geral, eu gosto do JSF sim 
bom,
eu ainda continuo não gostando muito de JSF mas admito que em algumas situações ele pode ser boa solução.
[]´s
JSF é interessante do ponto de vista do RIA (Rich Interface Applications). Algumas empresas e profissionais, por terem pouca experiencia prática, acreditam que JSF é a única solução para as interfaces ricas. Sim, com certeza uma arquitetura orientada a componentes se encaixa melhor no modelo RIA pois em teoria promove a reutilização de componentes Ajax. Na prática, se isso vai acontecer realmente, vai depender das abilidades do desenvolvedor, de quais componentes estão disponíveis antes do projeto começar e de quão realmente genéricos e reutilizáveis esses componentes são.
A questão é que JSF é uma especificação pentelha e boa parte dos frameworks que implementam JSF são pentelhos, enrolados e pouco produtivos(*), assim como EJB sempre foi e mesmo assim milhares de pessoas embarcaram na onda. Um dos desenvolvedores do Mentawai está fazendo um projeto RIA para uma empresa de Nova York e criou uma interface bem rica, cheia de Ajax. É plenamente possível fazer uma aplicação RIA com um framework action-based. A idéia do JSF desde os primórdios foi transformar programação web em programação para desktop, e isso, ao meu ver e ao ver de milhões de desenvolvedores que já estão acostumados com o modelo assíncrono request/response desde os tempos de PERL não é o melhor caminho.
É fundamental escolher um framework que tenha excelente suporta a Ajax, tanto no Client-Side como no Server-Side e é por isso que o Robert, que fez o MentaAjax e tem uma boa experiencia com JavaScript, está com o seu passe tão valorizado no mercado.
(*) Isso é subjetivo assim como algumas pessoas acham C++ super produtivo, provavelmente porque possuem vasta experiencia com a linguagem. Só dá para comparar produtividade entre A e B quando pegamos um profissional que nunca viu A nem B e pedimos para ele dizer qual foi o mais fácil e produtivo.
Agora que cairam na real que software não é prédio os desenvolvedores que começam de cima para baixo vão ter cada vez mais afinidade com estilo e usabilidade. Essa é uma chance de pessoas com pouca afinidade em questões de aparência possam criar interfaces mais bonitas e criativas a partir de componentes já existentes… e porque não a partir dessa experiência criar os seus próprios
Alguém falou que o JSF é como o EJB do passado. Não é, talvez o EJB 2.x tivesse alguma burocracia relacionada ao primeiro Struts, por exemplo. Mas o JSF estaria mais relacionado com as primeiras versões do Spring e do Hibernate, ou seja, classes POJO e arquivos grandes de XML.
Alguém falou que JSF foi feito tendo em mente as IDEs com interfaces visuais. Em termos. Na prática, o único jeito de se livrar da IDE é se você andar “nos trilhos”, pois é sempre necessário manter uma validação do seu XML em relação às classes Java, coisa que o javac sozinho não faz. Por isso, com o JSF, depende-se de IDE não porque é JSF, mas porque é Java. E, pessoalmente, não preciso de coisas de arrastar e soltar pra fazer páginas Faces.
Mas tem uma coisa que ninguém falou, o quanto JSF é componentizável. Não sei se existem frameworks MVC mais componentizáveis, mas deve significar muita coisa o fato de haver produtos que estendem o JSF para:
[list]ampliar os escopos “arroz-com-feijão” request, session e aplication para coisas como flash, dialog e conversation;[/list]
[list]criar componentes ajaxificados[/list]
[list]permitir execução de Managed Beans escritos em JavaScript[/list]
[list]referenciar managed beans via anotações[/list]
[list]transformar a estrutura pra ficar mais parecida com o MVP[/list]
[list]ampliar seu ciclo de vida para novas atividades[/list]
[list]gerar gráficos e PDFs com tags[/list]
[list]escolher entre páginas JSP ou XHTML[/list]
[list]mudar o render kit pra gerar WML sem mudar as páginas de apresentação[/list]
Aliás, significa não somente que o JavaServer Faces é popular, isso é apenas um lado da história, significa que o JSF é bastante componentizável podendo acrescentar, modificar e retirar componentes com uma facilidade não encontrada em outros frameworks Web.
Gosto do JSF, ele tem uma curva de aprendizado mais difícil mesmo, mas depois que peguei o jeito não acho nenhum outro melhor; quer dizer, nenhum outro melhor no Java!, porque é sempre interessante ficar sobre os trilhos.
Alguém falou que o JSF é como o EJB do passado. Não é, talvez o EJB 2.x tivesse alguma burocracia relacionada ao primeiro Struts, por exemplo. Mas o JSF estaria mais relacionado com as primeiras versões do Spring e do Hibernate, ou seja, classes POJO e arquivos grandes de XML.
Nao. Spring e Hibernate nao dependem de interface (ambos foram inclusive facilmente portados para .Net). A pessoa que falou (eu) se referia a depender de ferramenta.
PicoContainter eh Java. Spring eh Java. Hibernate eh Java. EJB 3 eh java. Nenhum deles esta preso a ferramenta de autoria.
Como ja falei hoje o sucesso da forma Rails de ver aplicacoes web soh mostra que JSF (bem como esses milhares de frameworks web que fazem a mesma coisa) eh um caminho antigo.
Alguém falou que o JSF é como o EJB do passado. Não é, talvez o EJB 2.x tivesse alguma burocracia relacionada ao primeiro Struts, por exemplo. Mas o JSF estaria mais relacionado com as primeiras versões do Spring e do Hibernate, ou seja, classes POJO e arquivos grandes de XML.
Nao. Spring e Hibernate nao dependem de interface (ambos foram inclusive facilmente portados para .Net). A pessoa que falou (eu) se referia a depender de ferramenta.
Pô, também não precisa esculachar! Eu sei que Spring e Hibernate não dependem de interface gráfica de usuário, eu queria apenas comparar com o fato de Faces ser POJO e XML, só isso. Com relação a depender de ferramenta, concordo que é muito chato, mas isso é regra pra boa parte dos frameworks Java.
Alguém falou que JSF foi feito tendo em mente as IDEs com interfaces visuais. Em termos. Na prática, o único jeito de se livrar da IDE é se você andar “nos trilhos”, pois é sempre necessário manter uma validação do seu XML em relação às classes Java, coisa que o javac sozinho não faz. Por isso, com o JSF, depende-se de IDE não porque é JSF, mas porque é Java. E, pessoalmente, não preciso de coisas de arrastar e soltar pra fazer páginas Faces.
PicoContainter eh Java. Spring eh Java. Hibernate eh Java. EJB 3 eh java. Nenhum deles esta preso a ferramenta de autoria.
Como ja falei hoje o sucesso da forma Rails de ver aplicacoes web soh mostra que JSF (bem como esses milhares de frameworks web que fazem a mesma coisa) eh um caminho antigo.
Preso a ferramenta de autoria, o Faces não está, mas é preciso ter muita habilidade do desenvolvedor pra se chegar a isso, claro. Mas não sei se para aplicações web, exista framewoks que possa prescindir de ferramentas, porque fazer várias páginas web no braço não é mole.
O Rails é tão bom que é hours-concours. E não tem muito a ver com o tópico.
Como ja falei hoje o sucesso da forma Rails de ver aplicacoes web soh mostra que JSF (bem como esses milhares de frameworks web que fazem a mesma coisa) eh um caminho antigo.
Claro que tem. Ele esta definindo o formato do futuro das aplicacoes web, seja qual for.
qual seria esse caminho diferente que está sendo percorrido agora pelo Rails? Seria algo do tipo: é muito simples então faça você mesmo?
Tenho notado que o JSF enfatiza bastante o reuso, mesmo porque é muito difícil ver alguém que consiga criar seu próprio componente. Já no caso do Rails, parece que tem mais gente criando do que reutilizando, pela própria facilidade do desenvolvimento.
Ahm? Quantos frameworks de persistencia, web ou para qualquer coisa exstem em Java? Quantas implementacoes diferentes de JSF? E Rails eh que tem NIH?
Voce pode embasar sua opiniao em algo para discutirmos? Um exemplo para ter uma ideia do que voce esta falando.
E essa eh a sua desculpa? “Os outros tambem te fazem passar por uma experiencia parecida com auto-castracao usando uma colher enferrujada do sopao da merenda, mas se os outros tambem fazem, alguem deve gostar, neh!”
Claro que tem. Ele esta definindo o formato do futuro das aplicacoes web, seja qual for.
Bom shoes, sinceramente não acho Rails ou frameworks ActionBased interessantes para cenários onde componentes ricos são usados intensamente.
Ter um componente pronto e otimizado, facilita muito a vida da equipe que vai apenas reutilizar o mesmo.
Minha aposta para componentes está no Flex ou Silverlight, por uma série de outras razões, começando pela possuibilidade de utilizar richmedia.
Acredito que JSF se não tiver seu ciclo de vida melhorado, aliás proposta do Garry para a versão 2.0 ; renderizadores para richmedia, vai acabar obsoleto.
[]´s
Bom, estamos quase em 2008.
Sendo bem gentil e educado, um framework ou uma linguagem hoje que precise de uma IDE/Ferramenta específica para permitir o seu uso de forma razoavel está no mínimo ultrapassado.
O pessoal deveria ficar mais antenado com as novidades tecnológicas e perceber que verbosidade na linguagem de programação, DSLs, Convention Over Configuration e outras mais, estão sendo utilizados em frameworks/linguagens e mostrando que existe uma forma mais prática de se fazer as coisas ao invés de utilizar uma solução que exige 1467 arquivos XMLs e/ou uma IDE do Rambo.
O RoR é muito bom, tem idéias bem legais, só que o ponto aqui é sobre JSF. Comparar JSF com Ruby on Rails ou .Net ou ColdFusion ou PHP não é legal… RoR pode ser a melhor coisa do mundo que a comunidade gigantesca do Java não vai simplesmente passar a usar RoR. Quem sabe um pouco de inglês pode ler esse excelente artigo que fala muito bem sobre isso: http://beust.com/weblog/archives/000382.html
Discordo de quem diz que JSF está desatualizado porque precisa de ferramentas. Sempre vão existir aqueles que preferem uma tecnologia mais complexa, apoiada em ferramentas, e outros que preferem uma tecnologia mais simples, do tipo que dá pra fazer na boa com um editor de texto e uma linha de comando.
Eu pessoalmente esperava que o JSF se difundisse mais depressa. Com uma boa ferramenta dá pra fazer tudo no drag-and-drop, nada de escrever HTML ou JavaScript. Pra quem estava com inveja do .Net, era praticamente maná do céu. Ou eu superestimei o número de desenvolvedores Java que preferem ferramentas, ou subestimei o conservadorismo deles.
Quem gosta de tecnologia complexa ? Masoquista ?
Sempre vai existir aquele cara que pensa assim: “Quanto mais complexo é o meu código, quanto mais complexa é a linguagem que eu programo, quanto mais complexo, enrolado e cheio de passos é o framework web que eu trabalho, então muito provavelmente eu sou um cara fera! Não é qualquer um que consegue entender isso, quanto mais botar pra funcionar! Caramba, eu sou realmente um cara bom!”
O nome disso é Rube Goldberg machine. Veja como várias pessoas adoram esse tipo de arquitetura: http://en.wikipedia.org/wiki/Rube_Goldberg_machine
Eu prefiro focar em resultados mantendo sempre o KISS, mas sempre vejo que muitas empresas e profissionais preferem o COMPLEXO e o PODEROSO ao invés do SIMPLES e EFICIENTE.
O que seria da noite sem o dia? Será que o JSF foge do KISS? Não sei, mas se compararmos com outras soluções que há por aí, acho que sim! Olha só esse tópico aqui: http://www.guj.com.br/posts/list/75751.java
Se JSF não consegue ser simples nem para fazer um conversão e nem para usar uma tag select com seleção automática, então imagina quando eu tiver que trabalhar com as coisas um pouco mais avançadas como IoC, Autowiring, Filtros, etc.
Se poder e complexidade são mais importantes do que KISS, então eu não sei o que estamos fazendo programando em Java ao invés de C++.
Pessoal,
RoR é legal, é sexy (tem gente que acha isso, meu conceito de sexy é outro, mas vamos lá), trouxe idéias legais e finalmente deu voz à simplicidade.
Mas eu tenho a impressão que alguns simplesmente estão falando: "Cara, Java é passado junto com Cobol, agora para ser legal e moderno tem que ser RoR. "
Não quero dizer que não devemos usar RoR, devemos sim, até mesmo para saber como funciona e usara suas boas idéias. Mas a plataforma Java, com todos seus defeitos, esta a anos luz à frente de RoR. Onde estão as aplicações Enterprise em RoR? Twitter ? (Olhe o preço que eles tiveram que pagar para escalar)
O que seria do RoR se não fosse a plataforma Java, o JRuby e o apoio da Sun ?
Achar que qualquer sistema pode ser escrito em RoR e ele vai aguentar na boa acho um pouco de exagero.
PS: É perfeitamente possível e fácil ser simples com Java.
Bom shoes, sinceramente não acho Rails ou frameworks ActionBased interessantes para cenários onde componentes ricos são usados intensamente.Ter um componente pronto e otimizado, facilita muito a vida da equipe que vai apenas reutilizar o mesmo.
Minha aposta para componentes está no Flex ou Silverlight, por uma série de outras razões, começando pela possuibilidade de utilizar richmedia.
Eu nao falei que as aplicacoes sero feitas com MVC action-based e sm que Rails ja mudou a forma dos frameworks web.
Agora enquanto Silverlight, Flex e JavaFX forem mutuamente exclusvos eu nao apostaria meu futuro neles. Alias em Silverlight (que eu ja conheci bastante de uma antiga parceria com a Microsoft) eu nao dependeria ate ele ser refeito.
RoR é legal, é sexy (tem gente que acha isso, meu conceito de sexy é outro, mas vamos lá), trouxe idéias legais e finalmente deu voz à simplicidade.Mas eu tenho a impressão que alguns simplesmente estão falando: "Cara, Java é passado junto com Cobol, agora para ser legal e moderno tem que ser RoR. "
Não quero dizer que não devemos usar RoR, devemos sim, até mesmo para saber como funciona e usara suas boas idéias. Mas a plataforma Java, com todos seus defeitos, esta a anos luz à frente de RoR. Onde estão as aplicações Enterprise em RoR? Twitter ? (Olhe o preço que eles tiveram que pagar para escalar)
Nao sei o qe vce chama de ‘enterprise’ mas talvez olhar a pagina de clientes da 37Signals e da ThoughtWorks pode te ajudar. Alias, entra em um site de empregos e faz uma busca or vagas.
Ahm? Sua pergunta nao faz muito sentido. a pouco tempo que a Sun adoto o projeto livre JRuby, antes dsso Rails ja era tao rlevante quanto hoje. Na verdade o ato da Sun foi uma reacao (e ate que rapida e bem sucedida considerando a sequencia de fracassos da empresa sem personalidade).
Achar que quaquer sistema pode ser feito em Java e que ele va aguentar na boa ehexagero. A coisa e: ferramenta certa para problema certo.
Como ja falei hoje o sucesso da forma Rails de ver aplicacoes web soh mostra que JSF (bem como esses milhares de frameworks web que fazem a mesma coisa) eh um caminho antigo.
estou aprofundando meu aprendizado em JAVA … e prentendo realizar a prova de certificação no ano que vem…
Acompanhando o “tumulto” que está acontecendo nesse tópico, me fez parar um pouco para refletir…
HOJE, o que seria o “mais interessante” de se aperfeiçoar: JAVA ou Ruby (usando o rails como frmw) ??
Se alguém mais experiente com RoR puder responder seria interessante para a reflexão:
Com a melhoria do JRuby, não seria possível portar grande parte das idéias do RoR para Java?
Quais as principais idéias e/ou funcionalidades do RoR (1 ou 2 são o suficiente) que faz com que ele seja muito melhor que qualquer outro framework web em Java?
Quais as funcionalidades que o RoR oferencem que é praticamente impossível tentar reproduzir num ambiente Java?
-Sergio
Depende do que voce quer. Se voce esta iniciando em programacao profissional (e lembre-se: programadores profissionais escrevem testes) ou se esta procurando empregabilidade facil e imediata no Brasil aprenda Java.
Se voce esta aprendendo a programar ou mais preocupado em aprender bons conceitos sobre programacao comece por Ruby.
Soh nunca se iluda oce vait er que saber varias linguagens de programacao, Java, Ruby, Python, JavaScript, bash… cada uma tem uma finalidade.
estou aprofundando meu aprendizado em JAVA … e prentendo realizar a prova de certificação no ano que vem…Acompanhando o “tumulto” que está acontecendo nesse tópico, me fez parar um pouco para refletir…
HOJE, o que seria o “mais interessante” de se aperfeiçoar: JAVA ou Ruby (usando o rails como frmw) ??
Depende do que voce quer. Se voce esta iniciando em programacao profissional (e lembre-se: programadores profissionais escrevem testes) ou se esta procurando empregabilidade facil e imediata no Brasil aprenda Java.
Se voce esta aprendendo a programar ou mais preocupado em aprender bons conceitos sobre programacao comece por Ruby.
Soh nunca se iluda oce vait er que saber varias linguagens de programacao, Java, Ruby, Python, JavaScript, bash… cada uma tem uma finalidade.
Shoes, sempre acompanho o seu blog…já tinha lido o link q postou =) …
trabalho com desenvolvimento web (PHP) há 5 anos aproximadamente…
somente estudei JAVA na minha graduação msm…agora, acho q chegou o momento, digo, somente agora estou com um tempo livre para me dedicar a aprender a fundo uma nova linguagem…
obrigado pelas dicas …
abraços, e sucesso ai na TW
Sim, mas voce continuaria usando Ruby. Entao, pq nao usar Ruby on Rails?
Quais as principais idéias e/ou funcionalidades do RoR (1 ou 2 são o suficiente) que faz com que ele seja muito melhor que qualquer outro framework web em Java?Quais as funcionalidades que o RoR oferencem que é praticamente impossível tentar reproduzir num ambiente Java?
ActiveRecord e named routes. Nao da pra implementar do mesmo jeito em uma linguagem estatica (ou que nao suporte method_missing e classes abertas).
Bom shoes, sinceramente não acho Rails ou frameworks ActionBased interessantes para cenários onde componentes ricos são usados intensamente.Ter um componente pronto e otimizado, facilita muito a vida da equipe que vai apenas reutilizar o mesmo.
Minha aposta para componentes está no Flex ou Silverlight, por uma série de outras razões, começando pela possuibilidade de utilizar richmedia.
Eu nao falei que as aplicacoes sero feitas com MVC action-based e sm que Rails ja mudou a forma dos frameworks web.
Agora enquanto Silverlight, Flex e JavaFX forem mutuamente exclusvos eu nao apostaria meu futuro neles. Alias em Silverlight (que eu ja conheci bastante de uma antiga parceria com a Microsoft) eu nao dependeria ate ele ser refeito.
O flash não é um padrão e detém mais de 90% do marketshare para richmedia.
Particularmente aposto muito no Flex ou Laszlo, plataformas que exportam para a engine.
Se olharmos para a contra-partida - HTML + JavaScript, isso nunca foi e nunca será uma solução … gambiarra das feias e está aí até hoje …rss
RoR é legal, é sexy (tem gente que acha isso, meu conceito de sexy é outro, mas vamos lá), trouxe idéias legais e finalmente deu voz à simplicidade.Mas eu tenho a impressão que alguns simplesmente estão falando: "Cara, Java é passado junto com Cobol, agora para ser legal e moderno tem que ser RoR. "
Não quero dizer que não devemos usar RoR, devemos sim, até mesmo para saber como funciona e usara suas boas idéias. Mas a plataforma Java, com todos seus defeitos, esta a anos luz à frente de RoR. Onde estão as aplicações Enterprise em RoR? Twitter ? (Olhe o preço que eles tiveram que pagar para escalar)
Nao sei o qe vce chama de ‘enterprise’ mas talvez olhar a pagina de clientes da 37Signals e da ThoughtWorks pode te ajudar. Alias, entra em um site de empregos e faz uma busca or vagas.
O termo enterprise não foi bom, mas o que eu quis dizer solução para grandes problemas, aplicações críticas, que envolvam transações financeiras, billing, ERPs. Um software tão completo, que por acaso é uma IDE, como é o eclipse, e mais outros exemplos que não vou me lembrar neste momento. Estes tipo de aplicações que não são tão “sexy”.
Não vamos pensar que o mundo de softwares limita-se a aplicações web. E mesmo em muitas aplicações que só parecem web exigem muitos processos “pesado” e complexos no back end.
Java pode não ser bom para tudo, mas ele é muito bom para muitas coisas.
Quanto à pesquisa de vagas não vou poder ver agora para poder falar alguma coisa, mas fico curioso e mais tarde vou pesquisar isso.
O que dizer é que se Ruby não rodasse na JVM ele nem drivers decente para bancos de dados iria ter (rodando na JVM ele pode usar o JDBC). Quantos SGBD tem drivers para o Ruby ? Como fica a comparação do Hibernate vs ActiveRecords ?
E quanto tempo iria levar para Ruby ter um Virtual Machine da qualidade de JVM?
Foi mais ou menos isso foi minha pergunta.
Eu não disse que qualquer sistema deve ser feito em Java, que Java aguenta quaquer sistema. Eu já trabalhei em sistema que Java abriria o bico em milisegundos =) Já trabalhei em sistema que Java foi usado como um canhão para matar um mosca.
Acho que neste ponto eu não discordo em nada com você.
De maneira alguma eu acho que RoR não deva ser usado, como eu falei, acho que ele trouxe boas idéias, faz coisas interessante, mas como Java, não é a solução simples para qualquer problema complexo.
A razão de eu me meter nesta conversa, com um grande risco de tomar porradas :-), foi a minha impressão de que as vezes o Java é posto como grande vilão e RoR é o nosso grande salvador.
Acho que RoR é mais ferramenta em nossa caixa de ferramentas.
O flash não é um padrão e detém mais de 90% do marketshare para richmedia.
Quantos concorrentes (de verdade) Flash teve nos ultimos 10 anos? Sera que isso nao eh consequencia?
Agora me responda dai do seu Mac este texto que eu estoue screvendo no meu Mac: quanto tempo o Windows ficou sem concorrentes reais? Voce apostaria tudo em desenvolvimento Windows-only hoje?
Concordo mas acho que as opcoes de rich media nao ficam atras. O problema eh intrinseco ao ambiente web, creio.
Ai que esta: estamos falando de solucoes web neste topico. A ferramenta certa para problema certo, lembre-se sempre
O que dizer é que se Ruby não rodasse na JVM ele nem drivers decente para bancos de dados iria ter (rodando na JVM ele pode usar o JDBC). Quantos SGBD tem drivers para o Ruby ? Como fica a comparação do Hibernate vs ActiveRecords ?
Acho que voce esta um pouco confuso pela plataforma Java. Driver especifico para uma plataforma soh eh necessario quando a plataforma possui limitacoes ou quando quer. Java tem limitacoes que te fazem JDBC a melhor opcao quase sempre mas outras plataformas como Ruby nao dependem disso. Ruby pode utilizar os drivers nativos disponiveis em qualquer banco de dados meia-boca.
http://ruby-dbi.rubyforge.org/
Isso nao eh vantagem de Ruby, existe algo parecido para qualquer plataforma.
Esse eh um bom ponto. Nao soh VM como toda a plataforma (bibliotecas e etc) por isso jRuby eh relevante.
Relaxa, isso acontece a cada X anos nesse mercado. Eh bom, acredite, eh evolucao.
O Java oferece Hibernate, iBatis, JPA, JDO etc. para soluções de ORM. E temos também o JDBC que está bem maduro com a maioria dos bancos suportando muito bem. Temos tb alguns bons pool de conexões como DBCP e C3P0.
Já ouvi falar que ActiveRecord é um dos pontos onde RoR é bastante criticado. Mas tudo bem. Hibernate tb não agrada a todos e para isso que tem iBatis, JDBC e outras alternativas. Segue alguns links:
http://kore-nordmann.de/blog/why_active_record_sucks.html
Quanto a named routes, não entendi muito bem. Parece que é uma maneira de criar convenções entre URLs e respectivas actions.
Quem quiser tentar entender:
http://wiki.rubyonrails.com/rails/pages/NamedRoutes
Essas são as principais funcionalidades que temos em Ruby e não podemos ter em Java?
Veja bem. Não estou falando que Ruby on Rails é ruim. Só estou querendo entender as reais necessidades que justificariam abandonar Java e partir para o Ruby em termos de framework web. Ficou claro que outras pessoas aqui possuem esse mesmo questionamento…
Acho que não custa fazer algumas experiencias com o RoR. Não nego que tem idéias muito boas ali. Só peço que, por favor, não comparem com JSF ou Struts, pois aí é covardia com o pobre Java…
Não vamos pensar que o mundo de softwares limita-se a aplicações web. E mesmo em muitas aplicações que só parecem web exigem muitos processos “pesado” e complexos no back end.
Ai que esta: estamos falando de solucoes web neste topico. A ferramenta certa para problema certo, lembre-se sempre
Bem lembrado, sai do tópico mesmo do assunto. Mas eu tinha que falar. hehehe
Só para não ficar muito off.
Acho a solução JSF complexa demais, nisso eu concordo plenamente que a solução RoR é muito melhor.
Acho que voce esta um pouco confuso pela plataforma Java. Driver especifico para uma plataforma soh eh necessario quando a plataforma possui limitacoes ou quando quer. Java tem limitacoes que te fazem JDBC a melhor opcao quase sempre mas outras plataformas como Ruby nao dependem disso. Ruby pode utilizar os drivers nativos disponiveis em qualquer banco de dados meia-boca.
http://ruby-dbi.rubyforge.org/
Isso nao eh vantagem de Ruby, existe algo parecido para qualquer plataforma.
Bem, só vou continuar este ponto, porque o resto acho que estamos de acordo.
Este talvez seja um ponto que eu não concordo. (e lá vou eu sair do tópico de web novamente)
Não enxergo a existencia do JDBC por uma falha da plataforma Java. Pode-se ter uma implementação propietaria puramente em Java ou um bind para a api em C do driver nativo. Existe isso? Não me lembro de ver algum, então acredito que o Jdbc dê bem a conta do recado.
Eu sei que pode-se atacar o Jdbc por ser uma padronização e padronização podem ser ruins porque deve-se padronizar pelo mínimo comum. Mas acho que a Sun e a JCP fizeram bem o seu trabalho e não tem-se dúvidas que o acesso a Base de dados em Java é fácil, rápido e confiável.
Quem programou em C sabe o porre que é cada base de dados ter sua api. Já programou usando a OCI do Oracle? Aquilo é quase como programar GUI em Win32.
Bem, já escrevi muito off neste tópico sobre interface Web.
Esse nao eh o problema. DBI (que eu linkei acima) oferece padronizacao, um driver JDBC nao eh apenas uma maneira padronizada é uma forma de lidar com o fato que Java é multiplataforma e não pode depender do SO.
Java nao pode contar com o driver instalado no servidor (a menos naquele JDBC-ODBC horrivel) entao o fornecedor tem que prover seu proprio driver para JDBC. Outras plataformas geralmente nao precisam de um driver proprio.
ActiveRecord e named routes. Nao da pra implementar do mesmo jeito em uma linguagem estatica (ou que nao suporte method_missing e classes abertas).
O Java oferece Hibernate, iBatis, JPA, JDO etc. para soluções de ORM. E temos também o JDBC que está bem maduro com a maioria dos bancos suportando muito bem. Temos tb alguns bons pool de conexões como DBCP e C3P0.
Já ouvi falar que ActiveRecord é um dos pontos onde RoR é bastante criticado. Mas tudo bem. Hibernate tb não agrada a todos e para isso que tem iBatis, JDBC e outras alternativas. Segue alguns links:
http://kore-nordmann.de/blog/why_active_record_sucks.html
Quanto a named routes, não entendi muito bem. Parece que é uma maneira de criar convenções entre URLs e respectivas actions.
Quem quiser tentar entender:
http://wiki.rubyonrails.com/rails/pages/NamedRoutes
Essas são as principais funcionalidades que temos em Ruby e não podemos ter em Java?
Veja bem. Não estou falando que Ruby on Rails é ruim. Só estou querendo entender as reais necessidades que justificariam abandonar Java e partir para o Ruby em termos de framework web. Ficou claro que outras pessoas aqui possuem esse mesmo questionamento…
Acho que não custa fazer algumas experiencias com o RoR. Não nego que tem idéias muito boas ali. Só peço que, por favor, não comparem com JSF ou Struts, pois aí é covardia com o pobre Java…
Acho que essa comparação JSF ou Struts com o Rails não faz muito sentido, pq ambos resolvem somente uma parte do problema.
Seria interessante uma comparação entre Rails e Seam, por exemplo, para medir desde arquitetura à possibilidades de extensibilidade, performance e tudo mais … aí sim iria ser uma comparação mais justa, e outra, vou comprar uma briga aqui com o pessoal de Rails.
Entnrado nesta briga, existe o Grails que é baseado em java e diversos projetos de respaldo e na minha opinião superior.
Citem três motivos técnicos para me fazerem trocar Grails por Rails… para não ser injusto, vou citar alguns :
Camada de negócios desacoplada e injetada (IOC-Spring), retirando aquele código de negócio engruvinhado das Actions, que já foi ponto de discussão durante anos por diversos que abordam Design Patterns.
Suporte à JPA e seus diversos providers, não limitando à uma única implementação, ActiveRecord. Diga-se de passagem gosto bastante do GORM.
Integração com o framework de segurança Acegi, que é um dos melhores do mercado.
AOP, para retirar interesses ortogonais do seu código, ou outras aplicabilidades.
Suporte ao Compass, framework de buscas que encaspula ferramentas ORM também , fazendo uso do Lucene, um excelente indexador.
Suporte à Laszlo , entre outros frameworks para Ajax, como DRW, Dojo e por aí vai …
Uma coisa interessante é que ele é baseado nos mesmos preceitos do David Heinemeier, tornando sua produtividade excelente.
Não tiro o mérito do Rails, principalmente do David e o Grails é uma cópia desses paradigmas. Entretanto, sua implementação é feita de maneira que me agrada muito, principalmente vindo do mundo java, já que de fato o JRuby está se tornando uma das melhores alternativas para o Rails.
Empresas como JetBrains entre outras estão começando a apostar no framework. A SAP com seu programa para Rails, estendeu ao Grails visando também esse público que está crescente -
https://www.sdn.sap.com/irj/sdn/wiki?path=/display/Community/Composition%20on%20Rails&
Só para findar, alguns dos citados fazem uso de frameworks concebidos no meio Java, com uma qualidade assegurada por alguns anos e excelente performance, oriunda de linguagens estáticas. Reutilizar esse conhecimento de maneira rápida é o que torna interessante e aderente aos paradigmas do David.
[]'s
Kenobi
AHM!? De que voce esta falando? Em Rails as regras de negoco ficam nos models, que podem muito bem ser m domain model bonitinho. Alias a maoria dos rojetos que eu ja vi em Java (basta navegar pelo forum) cloca regra de negocio em tudo quanto eh luar menos no objeto de negocio.
Existem alternativas ao ActiveRecord mas por que exatamente você precisaria de algo diferente? No mais, se você precisa dos frameworks mais poderosos que tal JRuby on Rails?
JRuby on Rails?
Uhm… se voê estudar um ouquinho sobre Ruby vai perceer que boa parte do que AOP faz nao é necessário numa linguagem dinâmica. O fato de "sentir falta de AOP em Rails"aliás me mostra que seus pontos são influenciados por você não entender como Ruby se comporta no desenvolvimento de aplicações e orque alguns dos seus pontos simplesmente não são aplicáveis.
Você pode usar Lucence como servico para Ruby. Alias, para qualquer coisa. Da ma olhada nos projetos paralelos do Lucene.
Qual o problema do AJAX do Rails?
Ants de contiuar respondendo por favor leia isso:
http://wiki.rubyonrails.com/rails/pages/Plugins
Para conhecer uma das extensões disponíveis.
Engraçado essa coisa do Java ser o pau pra toda obra. Me lembra quando comecei com Java e tinha que convencer toda uma empresa que nem tudo precisava ser feito em C++. Isso foi entre 90 e pouco e 2003. Agora a historia se repete.
O mundo da volta, da volta e para no mesmo lugar.
BTW:
Veja bem. Não estou falando que Ruby on Rails é ruim. Só estou querendo entender as reais necessidades que justificariam abandonar Java e partir para o Ruby em termos de framework web. Ficou claro que outras pessoas aqui possuem esse mesmo questionamento…Acho que não custa fazer algumas experiencias com o RoR. Não nego que tem idéias muito boas ali. Só peço que, por favor, não comparem com JSF ou Struts, pois aí é covardia com o pobre Java…
Covardia é ainda empurrarem esses frameworks goela abaixo da maioria dos programadores.
Ninguém precisa abandonar o Java. Aliás, Ruby é uma péssima linguagem do ponto de vista do típico arquiteto Java. Ruby dá poder ao programador. Só pra te dar uma idéia do tipo de coisa que um programador pode fazer em Ruby, no ActiveRecord você pode escrever algo como Agent.find_by_name(‘Jack Bauer’) e receber . Se você abrir a classe Agent, vai ver que não há nenhum método find_by_name. O que acontece é que a classe base dos modelos captura as chamadas find_by_ que não encontraram nenhum método correspondente (o que seria simplesmente uma Exception no Java) e cria a query na hora. Outro exemplo: os desenvolvedores do Rails resolveram adicionar uma série de métodos às classes principais do Ruby, como capitalize e pluralize em String.
Bom, particualrmente não acho saudável esse tipo de abordagem, mesmo porquê em muitos cenários de negócio você vai ter composição com diversos objetos de domínio. Poder descoplar e transformar esse negócio em um EJB3 por exemplo, é um ponto de extensibilidade para FailOver por exemplo.
E já vi diversos projetos Rails por aí, e isso não ocorre. Na maior parte deles, o negócio fica mesmo nas Actions.
Por que particularmente não acho o ActiveRecord tão poderoso quanto um Hibernate por exemplo, sistema de LazyLoad - reattachment.
Fanatismo, pois se existem outras soluções que contemplam tal problemática, pra que ter um custo adicional de desenvolvimento ? Vai contra os princípios do David, por exemplo.
Mais um ponto, já comentei sobre o JRuby anteriormente e ainda acho que não é uma plataforma madura suficiente para projetos sérios.
A Oracle contratou a TW para suprir um problema sério de performance, por exemplo e isso tem pouquíssimas semanas.
O mesmo se aplica ao Groovy, que sua MOP é bastante robusta, entretanto você poderá aproveitar esse ponto de extensibilidade, para instrumentação por exemplo.
Você pode usar Lucence como servico para Ruby. Alias, para qualquer coisa. Da ma olhada nos projetos paralelos do Lucene.
É integrado ao Rails ? Ao Grails vem prontinho pra uso …
Nenhum, só comentei que o Grails também possui tal suporte e a outros frameworks do mundo Java, como Laszlo.
Só um comentário, conheço a parte de plugins de Rails e também conheço o framework, já fiz alguns desenvolvimentos com Rails/Ruby.
A questão não é java pra toda obra, e sim Groovy e Grails , utilizando estrutura pré-existente. Você vai continuar com os preceitos do David, mas se baseando num legado sólido.
Ae galera, estava procurando algo sobre Seam vs Rails e achei um debate bem legal. Leiam principalmente os comentários , por favor :
Qual tipo de abordagem, Domain Model? Leia meu post novamente: você deve colocar regras de negócio no model em Rails
Não seja por isso: em quase dez anos eu já vi muitos projetos em Java e as regras de negócio quase nunca estavam onde deveria. Qual o ponto?
Se você precisa de algo mais poderoso use algo mais poderoso. Agora eu realmente duvido que muitas aplicações precisem. Usamos porque é assim que sempre foi. O bom arquiteto sabe avaliar estas coisas.
Você critica algo que nem cnhece para defender Java e o fanático sou eu? Pelo contrário: ferramenta certa para problema certo, seja Java Ruby C# ou o que for.
Eu apenas dei a opçõ de usar o que você citou em Rails. Obviamente se você dá mais importância a isso num dado projeto do que às vantagens que Rails te daria é besteira mas geralmente quem desenvolve com Rails o faz pelas vantagens do framework. Minha opção foi juntr as duas coisas boas num ponto único.
É sua opinião, eu a respeito mas isso não faz dela verdade.
Eu já trabahei em elo menos 3 projetos que rpecisaram contratar a Sun para consertar caca na JVM. Aliás, péssimo suporte, um amigo meu teve que consertar o erro na JVM ele mesmo e depois nem pudemos usar o fix por causa das malditas licencas. E daí?
Então por que você colocou AOP como um onto nessa discussão?
É integrado ao Rails ? Ao Grails vem prontinho pra uso …
Nenhum, só comentei que o Grails também possui tal suporte e a outros frameworks do mundo Java, como Laszlo.
…
Só um comentário, conheço a parte de plugins de Rails e também conheço o framework, já fiz alguns desenvolvimentos com Rails/Ruby.
Então é hora de reler a boa e velha documentação. Suas respostas estão lá.
“Legado sólido” é Java, né? Pois é, legado sólido era C++ também. E COBOL também. Pois é.
Realmente, agora que Groovy está amadurecendo e deixando de ser “Java com umas pitadas de Ruby”, está ficando bem legal. Aquelas closures de ExpandoMetaClass são o bicho pra criar DSLs sem poluir o namespace, o operador ?. é uma excelente sacada, e tipagem estática opcional é um diferencial que o Ruby poderia incorporar. Mas eu estou cansado de ver gente falando “a gente não precisa de Rails porque tem o Grails”, e aí virar para o lado e fazer projeto em JSF + JPA. (ou, infelizmente, Struts 1 + DAO)
O Java oferece Hibernate, iBatis, JPA, JDO etc. para soluções de ORM. E temos também o JDBC que está bem maduro com a maioria dos bancos suportando muito bem. Temos tb alguns bons pool de conexões como DBCP e C3P0.
Voce perguntou o que tinha no Ruby on Rails que nao dava pra fazer em Java. Nao o que tinha no Rails que nao dava pra fazer mais ou menos parecido em Java. Eu afirmei que uma implementacao pau-a-pau do ActiveRecord eh impossivel em uma linguagem como Java ou C# 2.0, e vc me vem com uma lista de possiveis mais-ou-menos-quem-sabe-tomando-mais-um-LSD-fica-parecido? :?
E no que vc se baseia pra afirmar isso, mesmo tendo o Mingle e o Oracle Mix como prova de que o JRuby on Rails pode ser usado para projetos serios?
A Oracle nao contratou a TW pra “suprir um problema serio de performance”, como vc alega. A Oracle contratou a TW para ajudar a desenvolver o Mix.
Eu sei pq eu ajudei a escrever a porra da proposta, entao cuidado nas especulacoes
As otimizacoes de performance estavam inclusas no trabalho, como em todo projeto que vai pra producao; testes de performance sao parte da suite de testes de aceitacao da grande maioria dos projetos da TW. E nao sei de onde vc tirou que o Mix tinha problemas “serios” de performance: o JRuby tem se comportado tao bem que eles nem se importaram em ligar o fragment caching ainda. O Mix em si mal foi otimizado, foi so resolver uns probleminhas no proprio JRuby e os resultados foram, IMNSHO, excelentes.
Por “legado solido” vc diz dezenas de milhares de sistemas usando Struts 1.x e EJB 2? Hmm… solido e marrom, ne?
Uma coisa que fiquei o dia inteiro quebrando a cabeça: lá atrás o Shoes disse que dá pra fazer um domain model bonitinho na camada model. Acredito, mas parece que teria que abandonar um pouco o ActiveRecord porque aquela classe Base comum a todas as classes impede a utilização de um relacionamento de herança. E se as tabelas das bases de dados forem bem “antinormalizadas”, o ActiveRecord pode ser uma péssima idéia. O jeito, óbvio, seria, ou partir pro Hibernate em Java, ou queries à mão em Ruby.
Tem também o problema de que nem o JRuby on Rails, nem os frameworks Java tem integração entre si. Por exemplo: será que o Spring vai injetar as classes “legadas” em Java nas novas classes escritas em JRuby? Pode até ser que devessemos utilizar “soluções de contorno” para que as duas linguagens conversem entre si, mas a classe Ruby não ficaria muito elegante. Pode até ser que se devesse escrever tudo em Ruby mesmo, mas o cliente não vai pagar a reescrita de código em outra linguagem.
Tudo bem que o Shoes falou que cada caso é um caso. Mas atualmente eu vejo que o Rails exige tantas precondições, que não me faz sentir tanta confiança nele.
Leonardo, acrdito que o problema é que você escreve Ruby mas pensa Java. Me dê um caso onde heranca seja a única ou mesmo a melhor oção d cuk typing ou mixins nao resolve.
Para o caso espec[ifico do Spring segundo os fornecedores o framework oferece suporte. Pro rest é só ver como acontece integração com outras linguagens.
Não se enganem, enquanto tem gente questionando se vale a pena ou não usar a Sun e as outras grandes já estão despejand dnheiro em linguagens de JVM há muito tempo.
Tudo bem que o Shoes falou que cada caso é um caso. Mas atualmente eu vejo que o Rails exige tantas precondições, que não me faz sentir tanta confiança nele.
Acho que vou escrever sobre iso amanha. Sao 23:35 em Oz e eu acabo de chegar do bar
Novamente não acredito como sendo uma prática bacana e pelo blog do Gavin King, ele também não acha , até mesmo porque o Seam tem esse fundamento, de separação de negócios.
Você há de concordar comigo que os profissionais java ao decorrer desses anos amadureceram no quesito design. Hoje em dia ver um sistema com regras de negócio em Actions feito em Java é bem mais raro, ou o profissional é muito iniciante.
Acho que o Rails introduz um retrocesso, pois muitos programadores vão começar a história tudo denovo.
Extamente por isso e pensando em extensibilidade,papel do arquiteto como mencionado, é que busco uma solução mais abrangente, afinal o business plan de algumas companhias pode supreender.
Já peguei casos como a GE , que sua aplicação de Auto-Finance estava projetada para um crescimento de 30% ao ano e na prática foi mais de 168%.
O que você chama de ferramenta certa, me limitando ao Rails e não linguagens ? Qual o target ? Pequenos projetos startups ?
O ponto que sou favorável ao Grails é o subsídio ao crescimento dessa Startup. E não estou falando em Java aqui e sim Groovy.
Foi o que levantei sobre os preceitos do David para aplicações Web, que são seguidas pelo framework Grails. Dê uma lida no meu post anterior com mais cuidado.
Concordo e espero que em pouco tempo eu reveja essa posição, dada à equipe do JRuby que é muito competente.
Daí que estava falando sobre alguns problemas que a plataforma ainda vai enfrentar, por ser muito nova e investir pesadamente nisso é um risco a ser considerado.
Ponto de extensibilidade novamente. Soluções criadas como Log proprietário, utilizadas em outras aplicações, poderão ser acrescidas de forma prática e rápida.
Unf ?!
Esse aqui é um ponto interessante de discussão.
Vou começar pela evolução da plataforma e linguagem. Java não está sentado parado esperando o trem passar. Muitas iniciativas vem sendo incorporadas à cada versão, o que nos torna um pouco mais aderentes à realidade atual , quando comparados aos que você citou. Entretanto, voltando aos legados, C++ possui uma consistência sólida em alguns universos, tanto que o pessoal que desenvolve Games, utiliza intensivamente até os dias atuais e não cogita trocar tão cedo de linguagem para as suas engines. Lua pode vir para alguns casos, scripts, mas o core na maior parte dos casos é C++.
Este exemplo, retrata o que penso sobre Java para ambientes de integração e Web. Há muita coisa de qualidade e substituir sem ter algo à altura é complicado.
Cobol é o retrato da linguagem que não acompanhou a evolução. Uma das features mais bacanas das linguagens dinâmicas Groovy e Ruby são Closures, e a comunidade Java está atenta, com propostas para incorporar tal funcionalidade à linguagem - http://www.javac.info/consensus-closures-jsr.html
Para findar, não sou xiita e gosto muito de Ruby e principalmente sua sintaxe. Acontece que o Java hoje me provê de uma infra-estrutura bastante abrangente, como MDB´s por exemplo, utilizados em larga escala para integração, frameworks para concorrência (http://www.infoq.com/news/2007/11/jppf-1.0) .
Esse tipo de infra, para se construir do zero numa nova linguagem/plataforma, onera bastante tempo e custos.
Talvez tenha me expressado mal, não sérios e sim grandes. Todos os exemplos da 37Signals aos que você citou, possuem poucos usuários e baixa complexidade técnica.
Aliás, não sei o que tem por trás, mas pelo frontend, não vi nada de mais no Oracle Mix.
Já o Mingle exige 1G de memória como pré-rec, pra rodar uma aplicação relativamente simples.
Me equivoquei, realmente, lendo depois a nota da Oracle vi isso, valew
As otimizacoes de performance estavam inclusas no trabalho, como em todo projeto que vai pra producao; testes de performance sao parte da suite de testes de aceitacao da grande maioria dos projetos da TW. E nao sei de onde vc tirou que o Mix tinha problemas "serios" de performance: o JRuby tem se comportado tao bem que eles nem se importaram em ligar o fragment caching ainda. O Mix em si mal foi otimizado, foi so resolver uns probleminhas no proprio JRuby e os resultados foram, IMNSHO, excelentes.
Concorda que anterior às modificações, a performance do JRuby tinha alguns problemas ? Foi a base da minha alegação, com o que havia lido algum tempo atrás.
[/quote]Por “legado solido” vc diz dezenas de milhares de sistemas usando Struts 1.x e EJB 2? Hmm… solido e marrom, ne?
Não, estou falando de soluções como Terracota, Gigaspaces, GridGain, EJB3, Spring, Hibernate, Lucene, Compass, Drools e por aí vai … poderia ficar aqui até amanhã citando exemplos bacanas
Só pra falar um poquinho de EJB2 que é sempre bem criticado, lembro que EJB não é somente EntityBeans, que foi o grande vilão da história.
Você tem os MDB´s, SLB´s , Controle de Transações que na época, não tinha alternativas como Spring e outras no mercado. Quem trabalhou aqui com Corba, sabe o quanto era complicado.
Voltado ao “Legado Java” , aliás essa plavra sempre tem conotação de coisa ruim, existe uma nova especificação EJB3 que está bem legal, aproveitando idéias bem sucedidas e conceitos de convenção ao invés de configuração.
CV, não me referi ao Legado dessa forma pejorativa. Cuidado com a conotação
Ok, então Domain Model não é algo “bacana”.
Você há de concordar comigo que os profissionais Java ao decorrer desses anos amadureceram no quesito design. Hoje em dia ver um sistema com regras de negócio em Actions feito em Java é bem mais raro, ou o profissional é muito iniciante.
Não hei de concordar coisa nenhuma, hei de discordar. Continua a mesma coisa exceto pelos habituais nichos. E lha que nos últimos anos o que eu mais fiz oi andar de estado e estado conversando com pessoas e vivenciando projetos.
Pela última vez: Rails possui um Domain Model. o que você está falando não faz sentido, não é uma limitação (ou mesmo indução) técnica.
Extamente por isso e pensando em extensibilidade,papel do arquiteto como mencionado, é que busco uma solução mais abrangente, afinal o business plan de algumas companhias pode supreender.Já peguei casos como a GE , que sua aplicação de Auto-Finance estava projetada para um crescimento de 30% ao ano e na prática foi mais de 168%.
Lá vem você mais uma vez com casos isolados (e nomes de clientes grandes para impressionar os incautos). Bons arquitetos sabem ser flexíeis e isso não tem a ver com escolher Rails ou Java. Já trabalhei em sistemas CGI PERL que desbancam a grande maioria dos sistemas em Java em escalabilidade. Isso depende da arquitetura.
Oracle Mix, Mingle são pequenos projetos? Startups?
Subsídio porque você quer. Escolher Grails ou Rails vai influenciar muito pouco nisso, YAGNI.
Aliás, um dos meus rojetos atuais é exatamente ma empresa muito grande que decidiu testar Rails num sisteminha desses e gostou tanto que agora quer migrar tudo que for mais web do que backend para ele. E se esta empresa for uma startup então as páginas amarelas no Brasil são fabricadas por uma empresa de garagem.
No sue último post você me chamou de fanático por sugerir JRuby ao invés do sagrado Java.
Daí que estava falando sobre alguns problemas que a plataforma ainda vai enfrentar, por ser muito nova e investir pesadamente nisso é um risco a ser considerado.
Nova? Estes projetos citados aconteceram em 2006, amigo. Pelo seu critério Java é muito novo, arriscado e etc.
Por favor, por favor, por favor aprenda Ruby antes de criticar. Criticas são ótimas, critique por exemplo a ausência de algo que chegue perto de um contrato como as interfaces em Java, critique o modelo fraco de threads, critique o fato de Rails engessar a maneira com que aplicações são criadas, critique o fato de Ruby não ter macros, de parecer com PERL… critique até mesmo o fato de não obedecer à AOP Alliance. Só não faça críticas que não fazem sentido como a acima. O uso do cachimbo faz a boca torta.
Vou começar pela evolução da plataforma e linguagem. Java não está sentado parado esperando o trem passar. Muitas iniciativas vem sendo incorporadas à cada versão, o que nos torna um pouco mais aderentes à realidade atual , quando comparados aos que você citou. Entretanto, voltando aos legados, C++ possui uma consistência sólida em alguns universos, tanto que o pessoal que desenvolve Games, utiliza intensivamente até os dias atuais e não cogita trocar tão cedo de linguagem para as suas engines. Lua pode vir para alguns casos, scripts, mas o core na maior parte dos casos é C++.
Games não são aplicações criadas por consultorias ou profissionais de tecnologia normais, sua comparação não faz sentido. C++ é muito bom em alguns casos, a maioria das coisas que era utilizado existem alternativas melhores como Java.
Eu sinceramente cansei de discutir com você sobre isso. A cada post você repete as mesmas coisas (“Rails tem regra de negocio nas actions”, “Ruby não tem AOP”, “o target de warmup da startup do peito do pé do pedro é preto”) que não só não fazem sentido bem como já foram refutadas nos posts anteriores. Buzzwords e suitspeak não ajudam a embasar um argumento. Eu tavez esteja ficando velho e rabujento mas esse tipo de discussão não tem mas graça.
Existem dois mecanismos de herança de tabela suportados por ActiveRecord, single-table inheritance e polymorphic association.
Mas o foco não devia ser na plataforma, porque plataforma é muito mais fácil de consertar que linguagem.
Vou rebater somente alguns pontos, pq tou sem saco de continuar isso. Você e eu temos posições completamente diferentes e não chegaremos a um consenso, não por fórum, talvez num evento, pessoalmente trocando experiências.
Também venho fazendo isso bastante e tenho outro ponto de vista, novamente são duas experiências, tanto a sua quanto a minha podem ser válidas, não são excludentes.
Lá vem você mais uma vez com casos isolados (e nomes de clientes grandes para impressionar os incautos). Bons arquitetos sabem ser flexíeis e isso não tem a ver com escolher Rails ou Java. Já trabalhei em sistemas CGI PERL que desmbancam a grande maioria dos sistemas em Java em escalabilidade. Isso depende da arquitetura.
Aqui Shoes, você chutou o pau. Não quis impressionar ninguém, somente dei nome aos bois para a citação não ficar subjetiva. Cuidado com suas alegações…
Sinceramente ? Minúsculos, compare a um ebay por exemplo, aí sim. Oracle Mix não é uma iniciativa nova ? Mingle também não ? Ambos sairam do forno há pouquíssimo tempo?
Tenho opinião contrária, até mesmo um ponto de extensibilidade para escalar, que com o Rails não é muito claro , essa é a opinião de diversos especialistas. Não vou começar a procurar os comentários dos blogs de caras que li, pq estou sem saco pra fazer isso agora …
Bom, tem milhares de casos consolidados que não precisaram recorrer à Sun. Diferente do desenvolvimento em JRuby, que ainda não há essa massa quantitativa e num dos primeiros projetos sérios, OracleMix, há reports de gargalos na engine.
Porr favor, por favor, por favor aprenda Ruby antes de criticar. Criticas são ótimas, critique por exemplo a ausência de algo que chegue perto de um contrato como as interfaces em Java, critique o modelo fraco de threads, critique o fato de Rails engessar a maneira com que aplicações são criadas, critique of ato de Ruby não ter macros, de parecer com PERL… Só não faça críticas que não fazem sentido como a acima.
Calma lá você, eu não critiquei o Ruby, estava falando de Rails nesse ponto. Tá doido ? Falei de AOP e dei um exemplo hipotético, poderia ser qualquer outra abstração, sobre o ponto de extensibilidade.
Não critiquei a Linguagem… Novamente você confunde as coisas, estou falando o tempo todo de Rails vs Grails e você vem falando de Java vs Ruby !!!
Dá uma lida com um pouco mais de atenção, tá faltando compreensão de texto.
Eu parei aqui, como disse anteriormente. Eu dei minhas considerações porque não gosto de Rails e você não respeitou, simples assim. Se eu gosto de AOP ? Se eu acho importante isolar a camada de negócios ? Esses são pontos de vista técnicos e vc Shoes não é o Sr. da razão.
Tentando mai uma vez (eu sou burro e não insistente):
1 - Rails separa Camadas. Pelo amor de Zahl, Rails tem um Domain Model! Não ter um DataMaper é uma coisa completamente diferente (e existem Data Mappers para Rals)
2 - Rails é em Ruby, você levantou o ponto da AOP. Se conhecesse minimamente o desenvolvimento em Ruby saberia que AOP como utilizado em Java simplesmente não é necessário (method_missing e toda a parafernalha de metaprogramação)
E se seu parâmetro de comparação é o eBay meu Zahl, me diz pra onde eu mando curriculum porque eu realmente gostaria de trabalhar num lugar onde este tipo de aplicação é comum. Aliás, falando em eBay eu estive em Chicago com os arquitetos deste e conversei bastante sobre o que eles usam lá. Se vocês acham que um site com este volume usa a arquitetura e os frameworks que estamos conversando aqui vocês estão muito enganados. Sites como o eBay precisam de uma arquitetura específica. Não precisa nem ser deste tamanho todo, quando trabalhava no maior portal de vídeos do país nós sabíamos muito bem que usar frameworks de mercado não ia servir. Para isso que serve um arquiteto.
Não adianta seu framework ser maduro (maduro é o que, quatro anos? dois?) porque se ele for ser utilizado neste tipo de aplicação não será sem modificações. E aí o target de warmup da startup do peito do pé do pedro é preto torce o rabo.
Eu não confundi em momento algum Domain Model com Mapper e sim fiz uma consideração sobre onde a regra de negócio está e como o pessoal usa normalmente.
Groovy mais uma vez, e podíamos comparar MOP vs AOP , outro tópico.
Qualquer profissional com um pouquinho mais de experiência e literatura, sabe que não são construídos com esses frameworks, que é de fato uma solução otimizada, até mesmo pelo fato do tempo que ele está no mercado.
Não adianta seu framework ser maduro (maduro é o que, quatro anos? dois?) porque se ele for ser utilizado neste tipo de aplicação não será sem modificações. E aí o target de warmup da startup do peito do pé do pedro é preto torce o rabo.
Uma coisa é otimizações para site como o referenciado , ebay, que é uma plataforma. Só para esclarecer, participo do programa de Developers do ebay , conheço bem a arquitetura, até porquê estou tocando um projeto nessa área.
Agora, completamente diferente é para um OracleMix , simples e sem nada demais. Se vc precisar de customização para esse tipo de aplicação, mostra que sua plataforma não está madura e sim em fase de desenvolvimento.
[]´s
Meus 2 centavos:
O fato de Groovy usar coisas consagradas do Java não significa muita coisa. Existe equivalente no mundo RoR para tudo que foi citado. Só para dar alguns exemplos: MDBs, Busca textual, …
Quanto a AOP, concordo com o Shoes. Não interessa se o Grails suporta isso ou não, AOP é irrelevante para linguagens dinâmicas. Minha opinião é até um pouco radical, mas eu sempre achei AOP puro buzz. Mesmo em linguagens estáticas, inversão de controle e injeção de dependências resolvem bem o problema. Para linguagens dinâmicas isso é brincadeira de criança.
Os tais pontos de escalabilidade citados pelo Kenobi são (hoje) altamente questionáveis. Assim como inúmeros sistemas web enormes (porte do citado eBay), eu também sou partidário de arquiteturas “share nothing”. Minha opinião é que a escalabilidade tem muito pouco a ver com as linguagens/frameworks que você escolhe. Sinceramente, gostaria muito de ver bons argumentos do por quê, em uma aplicação web qualquer, um sistema totalmente distribuído (pode acrescentar sua sigla preferida… EJBs?) escala mais do que um outro que simplesmente aproveita bem o protocolo (rest?) e usa o conceito de “share nothing” com proxies reversos, caches distribuídos, etc.
Colocar a regra de negócios no controller não é culpa do framework/plataforma. A culpa é dos programadores, e isso acontece em qualquer framework Java também, assim como pode acontecer com Grails. Existe até um movimento da comunidade contra esse tipo de coisa.
Aliás, só para provocar (denovo). :twisted:
Aliás, só para provocar (denovo). :twisted:
Comentários da própria página que você enviou :
Um Ebay? Adwords? Gmail? Amazon? All written in Java. In fact I went to a talk at Java One where the Ebay engineers talked about throwing out their C++ system and rewriting the whole thing in Java split up among several thousand Appservers because they needed to scale their development process.
ja q vc´s sao expert em jvs
alguem sabe onde eu posso conseguir algum tutorial que trabalhe com jsf gerando wml, ja procurei no google e nao consegui nada se alguem souber fico mto grato.
Kung, achei o link … sobre o que você apresentou 9 sites, tinha um outro tópico, onde fiz minha abordagem sobre Java para tais iniciativas:
ja q vc´s sao expert em jvs
alguem sabe onde eu posso conseguir algum tutorial que trabalhe com jsf gerando wml, ja procurei no google e nao consegui nada se alguem souber fico mto grato.
Isso é renderkit. Vá no seu faces-config e altere:
<application>
<default-render-kit-id>WML_BASIC</default-render-kit-id>
</application>
so isso? nao acredito ai e mto facil rsrsrsr, hei desculpe e que eu sou novatão mas e pra mudar conforme a requisicao tipo html manda a pg pro cara wml manda a pg correspondente?
Há to achando mto bacana este topico pena q tá alto nivel demais pra mim + eu xego lá um dia .
obrigado t+
Kenobi, cala a boca desse pessoal. Mostra o case study de Grails em que uma aplicação desenvolvida em menos de um mês bate em mais de 400-600 requests por segundo num único servidor.
Comentários da própria página que você enviou :Um Ebay? Adwords? Gmail? Amazon? All written in Java. In fact I went to a talk at Java One where the Ebay engineers talked about throwing out their C++ system and rewriting the whole thing in Java split up among several thousand Appservers because they needed to scale their development process.
Ok, mas eles não mudaram para Java para poder distribuir em várias camadas. Isso é o que eu estava questionando (o link foi só de provocação mesmo ).
De qq forma, eu ainda não vi bons argumentos para o que questionei.
Comentários da própria página que você enviou :Um Ebay? Adwords? Gmail? Amazon? All written in Java. In fact I went to a talk at Java One where the Ebay engineers talked about throwing out their C++ system and rewriting the whole thing in Java split up among several thousand Appservers because they needed to scale their development process.
Ok, mas eles não mudaram para Java para poder distribuir em várias camadas. Isso é o que eu estava questionando (o link foi só de provocação mesmo
De qq forma, eu ainda não vi bons argumentos para o que questionei.
Kung , deu uma olhada no meu post mencioando anteriormente, em outro tópico ?
Eu nao falei que voce confundiu. Voce falou que Rails nao separa Camadas. Voce falou que em Rails as regras ficam no Controller. É mentira, simples assim.
Ahm?
Entao qual o ponto em usar um portal desses na comparacao? Você falou em eBay como parâmetro, não eu.
O eBay não usar soluções de caixinha como falamos aqui (e ser irrelevante nesta discussao por consequencia) é fruto do vlume de acessos e não “ser uma platafomra”. Se fosse por sso Facebook e Flickr não seriam em PHP.
O cv não te respondeu isso? De qualquer modo como vou saber que Grails não va precisar de uma mudancinha para aguentar minha aplicação? Cadê os cases"
Mais de uma vez trabalhei em projetos (Java) em que tivemos que contatar o fornecedor da aplicação (o figura líder do projeto OpenSource) porque ele não atendia nossa demanda. É o tipo de coisa que acontece frequentemente quando você desenvolve mais que os sitezinhos de intranet que 99% das pessoas estão fazendo o tempo todo.
Kung, certíssimo. Rails e Grails são equivalentes, o que mata é o “vou usar Grails poque é Java”.
Essa briga entre Grails e Rails é ridícula, nem vou entrar nessa discussão.
Eu vim falar que dei uma olhada na integração de frameworks com Ruby, e parece que só o Spring tem, porque o Hibernate não tem; o Seam, apenas pro Grails (que é praticamente uma sintaxe Java) e nada que integre o EJB3 ou o Faces.
Acho que pro Rails ser perfeito, as comunidades Java e Ruby deveriam se unir e criar formas de integrar esses dois mundos; porque muitas empresas não podem se dar ao luxo de refazer rotinas escritas em Java para o Ruby, e nem de encarar as possíveis complexidades de uma integração manual.
Mudando de assunto, o rubinelli falou que o ActiveRecord implementa o Single Table Inheritance. Isso é uma ótima notícia, pois eu já vi tabelas de BD cujo tipo de dados é fixado por uma flag, mas que para o mundo OO seria melhor implementar como uma herança, pois as implementações dos métodos são diferentes. Exemplo clássico: a tabela Usuario que possui uma coluna tipo, que aceita somente dois valores: 1 pra PF e 2 pra PJ, mas que no Java seria uma classe abstrata (ou interface) Usuario, e seus filhos diretos UsuarioPF e UsuarioPJ. Apesar disso, ainda acho que seria legal ter um suporte do Hibernate para o Ruby, daria ao desenvolvedor liberdade de escolha.
Rails não é e não vai ser perfeito mas existem2 gandes benefícos na união Java x Ruby:
1 - Tirar proveito das funcionaldades do Rails na plataforma Java
2 - Aprender que com inguagens diferene (de Java) podemos ter benefícios dferentes e usar este conhecimento nos nosos próximos framewks. Um exemplo é a coisa do pring com DSLs.
Será que e difícil? (é uma perguna mesmo). Alguém já tentou brincar disso? O Hibernate é mais utilizado com DataMappers do que Acive Recors (o adráo AR, Não o framework) mas eu já utilizei desta forma.Aco que o problema é que deveria aver um objeto Java qe fosse a representação do objeto jRuby… hmm…
Por enquanto só dá para fazer se você modelar e mapear as Entidades do lado Java, tem gente que já fez. JRuby ainda não gera classes Java bonitinhas que pudessem ser registradas em uma SessionFactory, por enquanto cada script vira uma classe com dois métodos estáticos (ou algo parecido com isso).
Existe m buzz desde o nício de novmembro na litsa de jvm-languages sobre o JVM Dynamic Languages Metaobject Protocol, o Nutter chegou a fazer a primeira implementação em Ruby pode ser um bom passo mas acho que o Hibernate no seu estado atual não se adaptaria ao fato de java.lang.Object não ser o OTO (one true object) de uma linguagem dinâmica.
Legal, valeu! Vou dar uma olhada. Pior que eu tô na lista e tá com 23424 não lidos…
Aí é um pouco mais fácil. Acho que rolaria se você decorar a sua SessionFactory com uma que faz os objetos dinâmicos se comportarem como o Hibernate espera.
Já pensei bastante sobre isso também. Dá para fazer, mas primeiro precisa sair o tal do dynalang. Faz tempo que tô querendo dar uma mão pra eles com isso, mas tá faltando tempo. Agora no fim do ano quem sabe sai alguma coisa…
Qual a sua metrica pra complexidade tecnica, e como vc sabe que esses projetos tem complexidade tecnica baixa?
Ah, voce nao sabe. Hmm…
Relativo ao que?
Voce ja usou todas as features do Mingle e disse “porra, esse treco eh relativamente simples! Eu vou fazer um pra mim mesmo, e chamar de MentaTracker! So que o meu vai ocupar 5kb de memoria!” Se sim, favor demonstrar.
Realmente e pelo frontend, realmente não parece muito complexo. Já fiz parte de alguns bem complexos do ponto de vista regras de negócio, como Blue Martini. Não vi , mas você poderia fazer uma pequena explanação, já que fez a proposta.
Ta aí CV , o que o OracleMix tem de diferente de projetos como Twitter, Pownce e por aí vai ? Integração com CRM Oracle para marketing one-to-one, análise de content management e repositório para tal ? Sindicalização desses de acordo com perfil ?Estratégias de advertising para cross-seller nos banners ? Eu não sei o que tem por trás, mas aparentemente pareceu muito simples…exigindo pouco processamento , quase CRUDS e pesquisa indexada.
[/quote]Relativo ao que?
Voce já usou todas as features do Mingle e disse “porra, esse treco eh relativamente simples! Eu vou fazer um pra mim mesmo, e chamar de MentaTracker! So que o meu vai ocupar 5kb de memoria!” Se sim, favor demonstrar.
Não preciso, já existe no meio java um exemplo tangível para comparação - Xplanner. Em termos de negócio, pode se prefir o Mingle, pois contempla outras metodologias, como Scrum, mas do ponto de vista técnico são equivalentes e o Xplanner é infinitamente mais leve.
E você acompanha meus posts sobre ferramentas para controle de projetos, eu sempre recomendo o Mingle, até porque tenho um Mac que aguenta com o pé nas costas. Já usei várias features estou tester desde o começo do projeto.
PS: Logo mais verá meu projeto halls no ar , relaxa
Eu nao falei que voce confundiu. Voce falou que Rails nao separa Camadas. Voce falou que em Rails as regras ficam no Controller. É mentira, simples assim.
Pode ter sio até um equívoco ou um approach para contornar essa deficiência (minha ótica) e não mentira. Acho melhor começar a pensar melhor nos termos que usa, segunda vez que peço para tomar cuidado.
Sim, disse isso porque ele tem um número considerável de acessos e em muitos casos de negócio, precisa persistir sessão, failover de compras, exposição de serviços e manter esses nesse ambiente de cluster por exemplo.
Completamente diferente de um facebook que é stateless. Amazon, é até um exemplo melhor que ebay.
O cv não te respondeu isso? De qualquer modo como vou saber que Grails não va precisar de uma mudancinha para aguentar minha aplicação? Cadê os cases"
Espero poder publicar em breve Adianto que fiz uns pequenos testes com ferramentas como Mercury Load Runner e JMeeter. Se valer , publico para comparação.
Acabou de dar minha argumentação. O OracleMix é um sitezinho simples e precisou de ajustes. Está entre contido no percentual de 99% e aí está o problema !
Antes ele fosse atípico, assim sua argumentação seria válida.
Não é esse motivo e sim porque tem uma “Melhor Integração”, porque faz uso de projetos consistentes como os já citados - Spring, Hibernate, Lucene, Compass, Acegi e por aí vai e se vai usar JRuby, prefiro usar a JVM direto, menos overhead, não transformo tipos de objeto Java para JRuby por exemplo.
Para mim faz sentido Rails se vou usar uma arquitetura LAMP sem Java no meio. Aí concordo em utilizar o framework.
Aham.
Tirando cluster (que não e usado por arqutieturas web escaláveis de verdade) qual o problema do Rails com as outras técnicas?
Seu problema é mantêr o estado de sessão em ambientes qual alto tráfego? Qual o problema do Rails em fazer isso? Aliás você nunca programou pra Facebook né? Dê uma olhada em como ele faz proxing de aplicações e chame isso de simples novamente, por favor.
Estamos esperando ansiosamente. Claro que estamos esperando o novo eBay e funcionalidades (front e back office, número de acessos além da querida “plataforma”), do contrário sua argumentação inicial sobre “complexidade de sites” é simplesmente fora da realidade não só da maioria das pessoas aqui bem como da sua (que surpresa seria…não?)
Você acabou de admitir que não sabe nada sobre o Oracle Mix pro CV mas continua afirmando que é uma aplicação simples? Quem disse que o mix é simples? Com base em quê? Com que sistemas ele se conecta? Quais os requisitos de performance?
Eu não costumo falar do que não conheço então vamos dar uma olhada no Mingle, que já conheço alguma coisa tanto como observador interno quanto externo. Nem chegando nas funcionalidades (que não são simples) você pode me esclarecer se acredita que uma aplicação vendida como produto, que pode ser instalado em qualquer ambiente, que pode ser vendida como produto ou serviço, que é personalizável ao extremo, que posui uma interface rica baseada em quilos de ajax (seja isso bom ou ruim, eu tenho minhas dúvidas), que possui um verificação de serial number, que possui código ofuscado e etc. é simples?
No mais, nem Mingel nem OracleMix são aplicações de referência de JRuby on Rails.
Se você gosta mais de abacaxi, ótimo. Só não venha falar sobre frutas que não conhece.
Will see meu caro padawan… mas adianto, que penso muito mais em regras como mencionei. Sindicalização, One-to-One Marketing utilzando redes neurais, cross-selling, sistemas de tagging utilizando Thesaurus e por aí vai … Estou desenvolvendo há um certo tempo e possui sim mais complexidade do que vc pode imaginar.
Agora se vai ser ou não um sucesso, é outro ponto. Estou pensando em realizar algo que tenho em mente e isso pra mim já valeu… sonho .
Não, eu fiz um questionamento ao CV sobre o que tem por debaixo da aplicação, para saber se é ou não simples. Disse que “aparentemente”, me parece uma aplicação simples. Completamente diferente.
Coloquei alguns pontos sobre o que eu acho particularmente complexo e ocuparia um certo processamento entre os requests, o que poderia onerar a performance diretamente.
Ainda não comparou com o Xplanner …Até onde conheço, existem ofuscadores para o ambiente Java que conseguem até mesmo incrementar a performance, otimizando. Aqui não sou especialista, talvez o Louds possa nos dar um help sobre esse processo, mas não seria um argumento para necessitar de tanta máquina, que foi o mencionado sobre o Mingle.
Verificação de Serial Number ? Depende de como vai implementar…Já vi diversos projetos utilizando as mais variadas técnicas e não justificaria esse incremento de requistos de hardware.
O que seria ? BaseCamp ? Existe uma certa onda no OracleMix para tornar o projeto OpenSource. Se isso ocorrer, vamos poder discutir isso de forma coerente, analisando os fontes, vou adorar
Por isso mesmo, pedi ao cv uma explanação sobre o que tem por debaixo da aplicação, para não ser injusto !
O que, seu projeto não segue os critérios baseados no eBay que você mesmo mencionou como miniamente razoáveis? Ah, então essa tecnologia é tosca, não funciona. Melhor ir para EJB 2.1 que é utilizado or todos os grandes bancos e grandes consultorias, e nós sabemos que sso é sinal de qualidade não? Por favor…
Por que diabos em compararia com xplanner? Além de não estar aqui para vender produto, a última versão do xplanner que usei foi o que? 2003? Não falo do que não conheço, já disse. E mais uma vez você já deixa claro que “não é especialista” (i.e. vai dar um chute) nos poucos requisitos não funcionais do Mingle que citei e ainda assim fala do que não cnhece. Tsc tsc.
Ok, eu paro por aqui. Basecamp é Ruby on Rails, não jRuby on Rails. Existe uma grande diferença entre os dois e enquanto você não conseguir entender isso a única coisa que vai conseguir escrever são seus suitspeak (mais Você S/A que HBR/FastCompany, aliás), especulações sem fundamento e as hipérboles habituais. É querer discutir um tópico avançado com quem não entende(, não quer entender e tem raiva de quem entende) o básico.
Boa sorte no seu projeto.
O que, seu projeto não segue os critérios baseados no eBay que você mesmo mencionou como miniamente razoáveis? Ah, então essa tecnologia é tosca, não funciona. Melhor ir para EJB 2.1 que é utilizado or todos os grandes bancos e grandes consultorias, e nós sabemos que sso é sinal de qualidade não? Por favor…Por que diabos em compararia com xplanner? Além de não estar aqui para vender produto, a última versão do xplanner que usei foi o que? 2003? Não falo do que não conheço, já disse. E mais uma vez você já deixa claro que “não é especialista” (i.e. vai dar um chute) nos poucos requisitos não funcionais do Mingle que citei e ainda assim fala do que não cnhece. Tsc tsc.
Ok, eu paro por aqui. Basecamp é Ruby on Rails, não jRuby on Rails. Existe uma grande diferença entre os dois e enquanto você não conseguir entender isso a única coisa que vai conseguir escrever são seus suitspeak (mais Você S/A que HBR/FastCompany, aliás), especulações sem fundamento e as hipérboles habituais. É querer discutir um tópico avançado com quem não entende(, não quer entender e tem raiva de quem entende) o básico.
Boa sorte no seu projeto.
Fim … vc entende pra caramba, estou maravilhado com suas respostas, aliás todas de uma profundidade … tsc ! Parei por aqui, legal vai ser se o OracleMix virar OpenSource. Aí, meu caro, faço questão de reabrir o tópico, com algo tangível em mãos.
Com relação ao meu projeto, will see … embora grande parte dos projetos atuais não se baseiam em arquiteturas ultra-sofisticadas , vide Django utilizando à torto e direito, além de me preocupar com os paradigmas de negócio também quero algo escalável e confiável, pelo menos para segurar o crescimento mínimo.
Se ele crescer, contrato vcs fodões da TW para refactoring
Estou prendendo a respiracao ate la.
Arquiteturas sofisticadas são apenas isso, elas não conferem nenhuma vantagem quanto a escalabilidade, por exemplo. A lingua inglesa, curiosamente, pode explicar sua predileção por elas, no ingles podemos usar fancy ou poch para qualificar aquilo que vem falando. Desculpa te avisar, mas normalmente aquilo que escala melhor são as arquiteturas simples.
Já desenvolvi sistemas que tinham um volume razoavel, sustentam mais de 100 requisições por segundo durante o dia todo e a arquitetura não nem nada JEE’sh nela, pelo contrario, usamos o mais simples possivel - e funciona bem. Pela minha experiência o sistema poderia ter sido escrito em Java, perl, ruby, groovy ou mesmo em bash sem comprometer o resultado.
Escalabilidade é um treco complicado demais para simplesmente assumir que ela existe por padrão e que se isso for possivel, é desejavel. Qualquer plataforma hoje possui uma escalabilidade vertical razoavel, suficiente para a grande maioria das aplicações enterprise. Falo isso por experiência própria, metade dos sistes do UOL poderiam ser escritos com RoR, rodar em uma máquina só e estariam muito bem.
“Otimization is the root of all Evil”, por um terno no capeta não ajuda a esconder os chifes, o rabo e, principalmente, o cheiro de enxofre.
Editado: Vc está provavelmente falando de um sistema web, logo meu post foi viagem, me desculpem…
só um adendo, antes que alguém caia em cima disso
A questão não é java pra toda obra, e sim Groovy e Grails , utilizando estrutura pré-existente. Você vai continuar com os preceitos do David, mas se baseando num legado sólido.Por “legado solido” vc diz dezenas de milhares de sistemas usando Struts 1.x e EJB 2? Hmm… solido e marrom, ne?
CV, você esta sendo radical em sua defesa do Ruby. Não só radical, mas esta despresando o Java para fortalecer seus argumentos em favor do RoR.
Java não é só Struts 1.x e EJB 2, e mesmo assim existem muito bons sistemas em produção usando estas duas tecnologias.
Que EJB (*) e Struts é muito ruim ninguém discute. Quem usou não foi por falta de aviso aqui no GUJ, visto que há milhares de anos muita gente fala que isso não presta. Até foquinhas foram sacrificadas em prol dessa causa.
(*) Ok, EJB3 é aceitável, mas também depois de refazer a coisa do zero 3 vezes já estava na hora de acertar a mão.
Quanto ao RoR eu concordo que a coisa é muito legal e bem feita, mas eu acredito que ainda ficarei com o Java durante um bom tempo. Os meus argumentos são bem parecidos ao desse cara aqui:
só um adendo, antes que alguém caia em cima disso
Na verdade é “premature otimization is the root of all Evil”.
Doubloe fault.
Aquele é um post antigo, e se você ler criticamente, vai ver que os problemas estão sendo endereçados pelas comunidades Ruby/JRuby/Rails ou nunca foram problemas pra começo de conversa:
Ruby é muito difícil: Balela pura. Já reparou como todo mundo entende Ruby, mas estão sempre dizendo “mas os outros…” Cadê os outros?
Ruby on Rails é muito avançado: Bobagem de novo. Rails é uma DSL construída em cima de Ruby. Se você não se importar em saber como “a mágica” funciona, do mesmo jeito que a maioria dos programadores não se preocupa com o lifecycle de componentes num JSF ou Webforms, ou como é feita a injeção de bytecode em Spring, você pode se virar muito bem em Rails.
Faltam IDEs: Faltavam. Free, para Windows, você tem Netbeans 6, Aptana, e Komodo. Precisa mais?
Fanatismo e mentalidade de rebanho: Frameworks como Merb, Camping e Sinatra mostram que nem todo mundo que faz Ruby bebe do mesmo Kool-Aid. Quem não tolera ActiveRecord pode ajudar no projeto DataMapper.
O fantasma da escalabilidade: Estamos pra ver um grande projeto falhar por falhas na escalabilidade do Rails, até porque ele encoraja um modelo “share nothing” que naturalmente escala bem. O mesmo não pode ser dito de outras plataformas. :roll: O que não quer dizer que não estão trabalhando em performance. O que fizeram com JRuby foi simplesmente fantástico, e a versão 1.9 do Ruby, planejada para começo do ano que vem, está com ganhos reais de performance por volta dos 200%.
Hosting Rails: Onde tem consumidor, aparece solução, especialmente num mercado disputado como webhosting. As empresas ainda estão experimentando pra encontrar a melhor forma de disponibilizar Rails, mas se você tem um orçamento de 20 dólares por mês já da pra colocar seu site no ar num VPS de 256MB. Tenta colocar o Glassfish em 256MB!
Enfim, 2007 foi o ano em que o hype abaixou e resultados concretos começaram a aparecer. Eu não sou tão otimista quanto o “Shoes”, mas realmente espero ver Java perder os primeiros projetos “tradicionais” para Rails em 2008.
A questão não é se é fácil ou difícil, até porque isso é relativo. Talvez se for comparado a C++ / Objective C seja fácil mas se for comparado a Java seja difícil. Java é uma linguagem OO BEM fácil, e isso é importante para a produtividade dos meros mortais que estão no mercado de trabalho. Se a oferta de profissionais altamente capazes, que conseguem entender e dominar Ruby de uma hora pra outra fosse grande, tudo bem, mas é sabido que contratar bons profissionais no Brasil e no mundo na área de TI é complicadíssimo para Java, o que se dirá para Ruby.
Ruby On Rails é muito legal mas está anos-luz do Java em termos de penetração nas empresas, profissionais capacitados, projetos open-source, livros, artigos, comunidade, etc. Simplesmente não dá para comparar a posição do Java hoje com a posição do Ruby, mas as pessoas afirmam com naturalidade que RoR agora é a referencia e o resto é coisa do passado. Se esse passado for Struts, JSF, EJB então tudo bem.
A questão é muito simples: Será que os milhares de desenvolvedores Java vão migrar lentamente para o Ruby só para programar no maravilhoso Ruby on Rails ou será que os frameworks Java vão competir com o Ruby on Rails na suposta produtividade e eficiencia?
O meu sentimento é que grande parte do sucesso do Ruby on Rails se deve a coisas como Struts, JSF, EJB, etc.
Perguntei antes e volto a perguntar: O que Ruby On Rails oferece que um framework web em Java não pode oferecer ou implementar? Acho difícil haver alguma coisa tão determinante que não possa ser implementada em Java.
O que o cara do artigo fala com perfeição é que Ruby é uma linguagem fabulosa e RoR é um framework web bem legal, mas por causa disso achar que a linguagem e o framework vão dominar o mundo é muita inocência. Assim como a Apple não dominou o mundo (talvez agora depois de 25 anos consiga), asssim como Smalltalk não dominou o mundo, muita água ainda vai ter que rolar para que o Ruby on Rails ameace um pouquinho só a supremacia do Java no server-side.
Concordo que Java nao eh soh Struts 1.x e EJB 2.x, e concordo que mesmo assim existem sistemas muito bons escritos nessas duas tecnologias. Mas, assim como existem sistemas muito bons escritos em Perl, eu quero passar o mais longe possivel dessa linguagem justamente pela maioria esmagadora de sistemas escritos nessa linguagem que nao ha perfume suficiente no mundo pra fazer ficar cheirosinho.
Eu tenho 25 anos agora, e eu me preocupo em aprender coisas novas e me livrar das ultrapassadas o quanto antes pq eu nao quero ser um programador de 60 anos que ganha dinheiro limpando as cagadas feitas ha meio seculo atras, como vemos hoje com o pessoal de COBOL e outras 4GL. Pode apostar que Struts e EJB 1.x e 2.x vao ser uma dor de cabeca tao grande quanto.
Voce nao deve comparar a posicao do Rails hoje com a posicao do J2EE hoje. Compare a posicao do J2EE em 2001, 3 anos depois de comecar pra valer, com o Rails hoje, 3 anos depois de comecar.
Sempre que vc for olhar pra esse tipo de coisa, preste atencao na curva de adocao sobre o tempo decorrido. Recomendo: http://en.wikipedia.org/wiki/Crossing_the_Chasm
Ja te respondi isso nessa mesma thread: ActiveRecord e named routes. Nao da pra fazer em Java pq Java nao tem mix-ins, nao tem method_missing e nao tem classes abertas.
E o que te leva a acreditar que Ruby e Rails nunca vao ter o mesmo poder de dominar o mundo que Java e J2EE tiveram? Fazer analogias a Apple e Smalltalk eh facil (ja que os dois sempre foram underdogs celebrados), mas pq nao olhar o que foi extremamente popular, tambem?
Rake, RSpec, gems… Java tem suas vantagems Ruby tem as suas. É só achar o lugar certo de cada (e das outras) e temos um bom lugar para investir.
E o jRuby está aí para ajudar
Se você quer homem-hora, concordo plenamente. Mas eu não poderia responder a isso melhor que o Paul Graham.
Mas 90% de Java é Struts, JSF, EJB. Eu sei que para alguém que desenvolveu seu próprio framework é difícil de engolir isso, mas hoje, 4 de dezembro de 2007, tem gente começando projeto com Struts 1 e DAO feito na unha. Tem gente para quem JSF ainda é o futuro. Existe muita inovação em Java? Claro. Mas até aí, existe Cobol Orientado a Objetos e até Cobol.NET.
Se todos os desenvolvedores Java do mundo morassem numa cidade, ela teria a população do Rio de Janeiro. É claro que existe uma inércia enorme aí, mas essa inércia é uma espada de dois gumes. As comunidades Ruby e Rails ainda são pequenas e muito mais ágeis. Houve mudanças bastante significativas entre as versões 1.0 e 1.2 de Rails, mas a comunidade está acompanhando. Conforme ela crescer, as mudanças vão se tornar mais difíceis, mas pelo menos elas vão se solidificar em torno de uma arquitetura mais sólida que Struts.
Ruby on Rails não depende de custom classloader e geração de bytecode, então toda a “mágica” fica em Ruby e pode ser estendida em plugins que vão muito mais fundo que um componente ou uma biblioteca. Veja por si mesmo a variedade de plugins disponíveis.
Sim, existe cacas enormes por ai, sinceramente, eu já dei manutenção em sistemas legados em C que se hoje cair na minha mão, ou eu peço demissão ou eu peço alguma coisa na casa de 6 digitos. Mas na época eu precisava de grana, sabe como é.
O ponto é que o problema não é a linguagem e sim a cultura do desenvolvedor. Acredite, deixe RoR cair na “massa” de desenvolvedores e você vai ver código em Ruby que vai dar vontade de sentar e chorar.
A luta não é pela melhor linguagem, mas pelo desenvolvimento de forma mais profissional.
Eu tenho 25 anos agora, e eu me preocupo em aprender coisas novas e me livrar das ultrapassadas o quanto antes pq eu nao quero ser um programador de 60 anos que ganha dinheiro limpando as cagadas feitas ha meio seculo atras, como vemos hoje com o pessoal de COBOL e outras 4GL. Pode apostar que Struts e EJB 1.x e 2.x vao ser uma dor de cabeca tao grande quanto.
Eu tenho 30, vi Java nascer e brigar para se firmar da forma que ele esta hoje. Java trouxe muitas boas idéias, e acredito que ainda tenha potencial para mais. Acredite, um dia você vai estar no forum GUR defendendo seus pontos de vista sobre RoR argumentando que ele tem seus pontos positivos, apesar do pontos negativos, para adeptos de uma nova tecnologia que vai surgir.
Sistemas legados sempre vão existir, as pessoas/empresas não querem e nem podem largar aquilo que esta funcionando e custou muito dinheiro apenas porque tem algo mais cool no mercado.
Struts 1.x não sei se vai dar tanta dor de cabeça, mas EBJ 2.x vai custar milhões de horas de sono ainda.
Mesmo assim, não acho que seja a culpa do EJB2.x e muito menos do Java, e sim da cultura de usar EJB para tudo que tinhamos a 3 anos atràs. Eu mesmo assumo minha parcela de culpa.
Gosto da ideía da ferramenta certa para certo problema. Mas não acho que Java seja tão diabólico assim.
[]'s
Olá
Cara, gostei do que você escreveu e concordo plenamente.
Aliás, no RejectConf07 falei com o Carlos Brando sobre isto. As tecnologias chegam, parecem a melhor coisa do mundo e depois aparece outra coisa que apresenta vantagens.
Estudei Ruby e achei uma linguagem bem mais poderosa do que Java. Hoje entendo porque algumas aplicações Ruby bem complexas podem ser feitas escrevendo MUITO menos código que uma outra similar feita em Java. Ando estudando RoR e também me impressiono com a possibilidade bem maior de me focar no problema a resolver ao invés de precisar de atitudes ninjas.
Tive meu primeiro contato com Java em 1996 e fui um dos presentes naquelo famoso evento Java World Tour de 1997 que apresentou o Java no Brasil. Comecei a desenvolver profissionalmente com Java em 1999 pois até então sabia programar mas não conseguia clientes.
Posso dizer que gosto muito de Java.
Mas meu testemunho é a impressão de que a maioria dos sites que a gente faz usando Java ficariam prontos mais rapidamente se fossem feitos usando RoR.
Se alguém acredita na experiência de um velho de 62 anos que já passou por Fortran, Basic, Cobol, PL1, Assembler (vários), APL, Clipper, C/C++, Pascal, Delphi, Visual Basic e Java, corra para aprender Ruby e RoR.
Java significa a empregabilidade atual. RoR pode significar continuar trabalhando com projetos inovadores no futuro.
[]s
Luca
Gostei do que o pessoal está falando do RoR. Eu mesmo, venho trabalhando em um projeto onde estou, feito em JRuby on Rails. Começou instável, devido a falta da evolução do JRuby no princípio e agora, com as melhorias da nova versão do JRuby, vem acelerando.
Eu diria que Ruby é ótima e o framework Rails bem bolado. Conheci Ruby em 2003 e não dei tanta bola na época, aprendi para um projeto Linux e parei por ai. Preferi o Python (e ainda prefiro) como linguagem.
Bom, vejo todos falando como se Java fosse ser enterrado, mas não penso assim. Acredito que a Sun está chegando em um novo estágio. Eu costumo fazer uma analogia ao meu modo de vida de antigamente. Eu gostava muito de jogar games de mesa . Com o passar do tempo, perdi a vontade de jogar e passei apenas a assistir e ensinar. A Sun está fazendo o mesmo. Veja o Groovy, é a primeira vez que surgiu uma segunda linguagem oficial para a plataforma JVM (isso poderia ter sido feito a muito tempo). Creio que a terceira será JRuby e a quarta…
Bom, enfim, a plataforma Java agora terá novos rumos. Focar na excelência da Virtual Machine e deixar com que os outros criem seus próprios “jogos” sobre ela. Isso eu chamo de amadurecimento.
Quanto a frameworks, minha nossa, Java tem demais isso. De certa forma, foi incentivo deles mesmos, uma vez que a linguagem não ajudava na produtividade. De repente, aparece RoR. Isso me lembra uma outra história, do imã da porta da geladeira. Enquanto uma empresa norte-americana havia desenvolvido a porta da geladeira com abertura pela parte de dentro (crianças morriam antigamente se ficassem presas dentro da geladeira) e JÁ estava treinando as pessoas em como usar, veio uma invenção simples, de um imã em uma borracha que além de vedar, não deixava a porta presa. Bom, dá pra imaginar o resto.
O problema é que muitos estão comparando o novo com o velho. Não dá pra comparar RoR com JSF, porque o último nasceu pra combater o ASP.NET, que na minha humilde opinião, não fez ainda jus ao seu legado, pois o .NET é melhor, mais simples e mais rico que o JSF.
RoR não parece com outros frameworks Java, mesmo o Grails com suas características similares (mas ainda nada tão fácil), porque este paradigma ainda não existia. Mas vejam que outros frameworks estão sendo criados partindo agora deste princípio “novo” e acredito que em breve surgirão vários fazendo o mesmo (em Java mesmo). Isso não é exclusividade mais do RoR, caiu na comunidade, vai ser imitado até que “alguém”, sei lá quando, inove novamente.
Agora, vejo o pessoal da ThoughtWorks comemorando o empenho do JRuby com o site feito para a Oracle. Convenhamos, uma empresa grande como a Oracle (meu momento “visão empresário”), claro que tem que saber o potencial de uma “novidade” como JRuby. JRuby ainda não foi testado a ferro e fogo em sistemas com grandes requisições. Mas todos sabemos que a ThoughtWorks tem tudo para dar certo, uma vez que um de seus desenvolvedores é nada mais que Ola Bini, que participou do projeto diretamente.
Agora porque JRuby e não Ruby? Meus amigos, todos sabemos que o potencial da JVM. E a integração com Java é simples.
Agora, porque muitos gostam de RoR? Bom, a verdade é nua e crua. Qualquer sistema, seja qual for, tem sempre as mesmas características básicas centrais (pra não dizer banais). Passamos a maior parte do tempo desenvolvendo e resolvendo isso.
RoR é fácil, mais que fácil, é quase “humano”. Agora é mais simples desenvolver qualquer coisa pra Web que usar PHP do modo mais macarrônico que existe.
A pergunta que fica é: Quantos de vocês acreditam que no futuro, profissionais desenvolvedores sejam bem pagos, como ocorre com Java hoje, uma vez que RoR não exige que tenhamos alguns “anos” de experiência para se tornar bons em “corrigir” problemas?
[]'s a todos e bom debate
Será? Obviamente em breve vai surgir algo muito mais simples e eficiente que Rails para aplicações web mas pelo que eu conheço do Carlos provavelmente ele vai ser a primeira pessoa a postar isso aqui. É uma das pessoas mas pragmáticas que eu conheço, não se apega à tecnologia ou ao framework específico e sim ao que importa: boa escolha tecnológica.
Seja Jara->Ruby, Ruby->Java, JRuby->Bainfuck… o que importa é que a indústria evolua e que não barremos esta evolução pelo medo da mudança.
E vai ser escrita em Clojure!
Isso, se não saírem com JErlang e JHaskell até lá.
Com relação ao meu projeto, will see … embora grande parte dos projetos atuais não se baseiam em arquiteturas ultra-sofisticadas , vide Django utilizando à torto e direito, além de me preocupar com os paradigmas de negócio também quero algo escalável e confiável, pelo menos para segurar o crescimento mínimo.
Arquiteturas sofisticadas são apenas isso, elas não conferem nenhuma vantagem quanto a escalabilidade, por exemplo. A lingua inglesa, curiosamente, pode explicar sua predileção por elas, no ingles podemos usar fancy ou poch para qualificar aquilo que vem falando. Desculpa te avisar, mas normalmente aquilo que escala melhor são as arquiteturas simples.
Já desenvolvi sistemas que tinham um volume razoavel, sustentam mais de 100 requisições por segundo durante o dia todo e a arquitetura não nem nada JEE’sh nela, pelo contrario, usamos o mais simples possivel - e funciona bem. Pela minha experiência o sistema poderia ter sido escrito em Java, perl, ruby, groovy ou mesmo em bash sem comprometer o resultado.
Escalabilidade é um treco complicado demais para simplesmente assumir que ela existe por padrão e que se isso for possivel, é desejavel. Qualquer plataforma hoje possui uma escalabilidade vertical razoavel, suficiente para a grande maioria das aplicações enterprise. Falo isso por experiência própria, metade dos sistes do UOL poderiam ser escritos com RoR, rodar em uma máquina só e estariam muito bem.
“Otimization is the root of all Evil”, por um terno no capeta não ajuda a esconder os chifes, o rabo e, principalmente, o cheiro de enxofre.
Louds, a maior parte dos projetos do UOL tratam ContentManagement , uma ou outra aplicação é um pouco mais softisticada (Ao menos até 2003, pois prestei consultoria ao UOL).
Completamente diferente de um software para gestão de fundos de investimento, por exemplo, que requer uma série de regras, segurança e por aí vai.
Você me deu um número de performance, e eu falei em escabilidade, que aliás foi a justificativa que você me deu para o desenho da arquitetura da NEC (sua arquitetura), projeto que fui contratado para fazer refactoring de algumas partes e que faz uso intensivamente de EJB.
Não estou dizendo que é a única solução para escabilidade, deixo claro isso. É apenas uma alternativa viável.
Poderia pensar em GigaSpaces por exemplo, trablhar com Pojos e Spring integrado ao mesmo de maneira simples e eficiente.
Tá aí. Gostaria que alguém me provasse por A + B que EJB é escalável.
Tenho esse voto de desconfiança desde o dia em que eu, um programador inexperiente, fui instruído por um arquiteto sem noção a fazer uma separação em uma camada de EJB de persistencia (tipo: save, load…) em baixo de um EJB de negócio. A idéia era resolver problemas de escalabilidade, porém, IN-CRI-VEL-MEN-TE, não escalou nada!
caramba e afinal, sem querer ser chato
qual foi a conclusão da pergunta do tópico?! JSF é o futuro nas empresas
tomara que seja, senão morrerei de fome rsrs
caramba e afinal, sem querer ser chatoqual foi a conclusão da pergunta do tópico?! JSF é o futuro nas empresas
tomara que seja, senão morrerei de fome rsrs
O projeto precisa melhorar muito ainda…Há o senão do renderkit para flex/flash e afins, se não vingar, duvido que fique muito tempo.
Pelo que eu entendi, a conclusao ate agora foi “nao, JSF eh irrelevante. Aprenda Rails”
O sucesso de tecnologias como JSF e ASP.NET depende mais do uso de boas práticas por parte da equipe de desenvolvimento. É possível sim criar software limpo e elegante com uma camada de apresentação orientada a componentes com suporte nativo a AJAX e cross-browser. O problema é que muitos desenvolvedores acostumados a frameworks como Struts não tem tempo para (ou não querem) adaptar-se adequadamente ao modelo orientado a componentes - um paradigma que obviamente favorece a criação ágil de interfaces com o usuário, mas não necessariamente transforma tudo em “espaguete”, como alguns pensam.
Na empresa em que trabalho criamos algumas aplicações avançadas, como um cliente B2B e um Dasboard, utilizando ASP.NET e consumindo Web Services. Os resultados superam as expectativas em termos de facilidade de manutenção (isso mesmo) e TTM. Acredito que resultados semelhantes poderiam ser obtidos com JSF + NetBeans 6.0.
That’s All!
realjn wrote.: Na empresa em que trabalho criamos algumas aplicações avançadas, como um cliente B2B e um Dasboard, utilizando ASP.NET e consumindo Web Services. Os resultados superam as expectativas em termos de facilidade de manutenção (isso mesmo) e TTM. Acredito que resultados semelhantes poderiam ser obtidos com JSF + NetBeans 6.0.Como vc. pode afirmar isso, vc. está fundamentado em quais exemplos ou modelos.
olha, aplico JSF a mais de 1 ano e meio e sinceramente, não troco ele por nada
integração com o Spring está super legal, facilidade de manutenção e afins, já participei de 3 projetos grandes com JSF e to fazendo um agora
é muito fácil falar mal sem sequer saber como faz um HelloWorld ou parar em qualquer problema
Se está referindo-se ao fato de que JSF poderia dar os excelentes resultados obtidos com ASP.NET, não trata-se de “afirmação” mas “suposição” baseado na abordagem orientada a componentes que as duas tecnologias utilizam e que obviamente as torna semelhantes entre sí. É claro que JSF levava uma série desvantagem até o lançamento do NB 6.0 o qual introduziu melhorias significativas no suporte JSF da IDE e que (guardadas as diferenças entre as tecnologias) faz lembrar o suporte oferecido pelo VS ao ASP.NET 1.1.
O grupo responsável pela JSR-127 está constantemente revisando as especificações do Java Server Faces e devemos esperar que alguns avanços (como melhor integração com XML Web Services) sejam introduzidos posteriormente e quem sabe a comunidade Java passe a acreditar mais na tecnologia, pois o feedback que tenho visto é decepcionante.
Como não tive ainda oportunidade de criar uma aplicação JSF feita para o Mundo Real, deixarei a prova de conceito como dever de casa para algum colaborador que esteja acompanhando o post.
That’s All !
Eu não vi até agora ninguém falar mau porque não conhece ou encontrou algum problema.
Da uma lida nos posts anteriores que você vai ver que o problema é outro.
Onde tah o “obvio”, que eu nao vi?
E o que JSF tem de agil?
Essas coisas servem pros caras criarem ferramentas que engessam a arquitetura e são cheias de wizard tipo JCompany, que estão querendo colocar aqui na empresa. 
Onde tah o “obvio”, que eu nao vi?E o que JSF tem de agil?
Amigo, como enxergar isso é um dos segredos mais bem guardados que existem. Para descobrí-lo por sí só, alguém precisa desenvolver e manter durante alguns anos aplicações Web de missão crítica em um framework como o Struts, que suporte Ajax, cross-browser, com interface complexa e customizações quase semanais. Depois aparece uma Fada que apresenta JSF ou ASP.NET para o cara… Quem já passou por isso, sabe do que estou falando.
Apesar disso, reconheço que a maioria das pessoas se sente mais à vontade ao utilizar a tecnologia que conhece melhor - mesmo que esta não seja a melhor opção existente. E a melhor parte é esta: no final das contas, a tecnologia do futuro é aquela que vai pagar nossas contas - gostemos disso ou não.
That’s All!
realjn wrote: O grupo responsável pela JSR-127 está constantemente revisando as especificações do Java Server Faces e devemos esperar que alguns avanços (como melhor integração com XML Web Services) sejam introduzidos posteriormente e quem sabe a comunidade Java passe a acreditar mais na tecnologia, pois o feedback que tenho visto é decepcionante.Poxa agora fiquei mais tranquilo pois a JSR-127 (JSF 1.0) de 03/2004 tinha tantos bugs que para usar erá necessário ser um bom contorsionista.O que estamos falando hoje é da JSR-252(JSF 1.2.0x)-JEE5 e, não precisamos esperar por avanços de WEB Services, SOA,J2ME,Java Card etc.etc. elas estão presentes no nosso dia a dia e integradas entre si vide os projetos da SRF. O feedback da comunidae é esse que vc. está lendo “JSF é o futuro nas empresas???”=22/08/2005 = e está super atualizado se voltar a ler o post vai ver que as discussões e as informações são de um nível muito superior ao simples devaneio esóterico
Amigo, como enxergar isso é um dos segredos mais bem guardados que existem. Para descobrí-lo por sí só, alguém precisa desenvolver e manter durante alguns anos aplicações Web de missão crítica em um framework como o Struts, que suporte Ajax, cross-browser, com interface complexa e customizações quase semanais. Depois aparece uma Fada que apresenta JSF ou ASP.NET para o cara… Quem já passou por isso, sabe do que estou falando.Mais ainda assim retorno a minha pergunta:
Então vc não poderia falar que JSF é bom, pois parece (não tenho certeza, mas é o que o seu post dá a entender) que vc nunca experimentou outra coisa seriamente. É como o cara que só conhece Struts e acha maravilhoso.
A questão do JSF é que, quando comparado com outros frameworks que estão por aí, ele parece meio espalhafatoso, enrolado, cheio de pequenos detalhes e passos desnecessários, não-simples e não-produtivo para o cara que está começando a mexer com ele. Se o cara já trabalha com ele a 2 anos então isso obviamente não se aplica!
Vc falou que usa ele com Spring. Isso, na minha opinião, é um problema dos projetos web em Java. Vc usa Spring, JSTL, Hibernate, Commons DBCP, Commons Email, Velocity, Sitemesh, MyFaces, JAAS, e por aí vai…
Só dá para dizer se JSF é bom ou não se compararmos ele a outra coisa. Por si só ele é maravilhoso para quem usa e entende.
Quem quiser ver uma comparação do SEAM (JSF) com o Mentawai pode dar uma olhada nesse post aqui: http://forum.mentaframework.org/posts/list/1707.page
Só peço que por favor coloquem qualquer comentário no post relacionado, e não aqui…
Se você nao tem argumentos fatuais (e, preferencialmente, científicos) pra discutir uma coisa como a adoção de uma tecnologia de desenvolvimento web, como você pode aludir que nós somos os cegos e o único esclarecido nesse forum, que tem mais de 30 mil usuários, eh você?
E antes que eu me esqueça, eu não sou seu amigo.
Eu já passei por experiências similares, mas geralmente eu estava bem longe de qualquer tipo de tecnologia a nao ser as empregadas na produção de ácido lisérgico. E não, eu não sei do que você esta falando. Por favor, esclareça.
A tecnologia do futuro eh a que vai resolver os problemas de tecnologia da informação que empresas e organizações têm. Se ela vai pagar as contas ou não eh totalmente irrelevante - o mundo nao gira em torno do seu saldo bancário, mas sim do valor de negócio produzido pelo seu trabalho. A julgar pela sua descrição envolvendo criaturas míticas e apego a tecnologias dependentes de ferramentas e desenhadas para permitir que programadores inexperientes e de baixa capacidade consigam produzam aplicações com as mesmas qualidades, ele eh pouco.
Sim, você tem toda razão. JSR-252 define a especificação atual. Talvez a causa de tanta antipatia pelo JSF e seu modelo orientado a componentes seja o receio de que o transformem no “Swing da Web”. Sim, isso é possível se você cruzar um engenheiro de software com um evangelista sectário.
Acho absolutamente desnecessário provar que uma tecnologia criada para simplificar a construção de interfaces gráficas Web (como JSF/ASP.NET), com reutilização de componentes e orientada a eventos seja menos produtiva para criar aplicações Web interativas do que com frameworks MVC. Já vivenciei os dois lados da moeda e para mim está muito claro. Por que gastar nosso tempo discutindo religião ?
Feliz Natal!!
Se você nao tem argumentos fatuais (e, preferencialmente, científicos) pra discutir uma coisa como a adoção de uma tecnologia de desenvolvimento web, como você pode aludir que nós somos os cegos e o único esclarecido nesse forum, que tem mais de 30 mil usuários, eh você?
E antes que eu me esqueça, eu não sou seu amigo.
Você não entendeu Carlos, é segredo e ele não vai te contar por que você não é do clube do bolinha.
Se você representa o fórum como moderador, deveria respeitar a opinião de seus usuários. O único lugar em que sou obrigado argumentar “cientificamente” sobre a adoção de uma tecnologia é na empresa em que trabalho, pois me pagam para isso. Creio que os usuários deste fórum são pessoas inteligentes e esclarecidas e não se deixarão levar sobre essa “alusão à cegueira” que foi citada por você, não por mim.
Não leve isso a sério nem para o lado pessoal. Aqui onde vivo é Natal.
Não sei o que é “ácido lisérgico”. É algum tipo de droga?
Para mim e para a maioria dos desenvolvedores que postam em fóruns e tem vidas de verdade, ganhar dinheiro é relevante.
A julgar pela sua descrição envolvendo criaturas míticas e apego a tecnologias dependentes de ferramentas e desenhadas para permitir que programadores inexperientes e de baixa capacidade consigam produzam aplicações com as mesmas qualidades, ele eh pouco.
Feliz Natal !!
Nao disse que todos os desenvolvedores que usam IDEs sao inexperientes e de baixa capacidade. Eu uso IntellIJ IDEA e me dou muito bem com ele, obrigado. Estava me referindo a ferramentas, frameworks e plataformas que te obrigam a usar uma IDE. Delphi, VB, JSF e ASP.NET sao exemplos classicos disso, e todos eles foram desenvolvidos com o suporte a IDEs para as massas de programadores que nao sabem direito o que estao fazendo como foco primario.
Ok, obrigado por ter esclarecido sua intenção quanto ao comentário. A essa altura o pessoal do forum deve estar fazendo rolar alguma aposta para ver quem nocauteia quem primeiro. Eu estou em desvantagem pois sou apenas um humilde “o que é um classpath” neste fórum. Por isso estou acenando a bandeira branca da paz. Sendo assim sugiro que usemos nossas massas cinzentas a partir de agora apenas para escrever código limpo e livre de erros…
Reitero meus votos de Feliz Natal.
Te falo que eu sou um …hahahaha… (brincadeira)
Venho acompanhando essa ‘discussao’ e tô achando mtooo interessante…
vi coisas q sequer sabia q existiam…ao longo dessas 9 paginas, sempre tirava uma coisa ou outra dos posts e pesquisa no google, literalmente buscando novas informacoes a respeito do q estava sendo falado …
gostaria de agradecer a vcs, aprendi mta coisa com a briga, opsss…rs…, com o debate de vcs …
[]'s e Feliz Natal …
ps: nao tem ngm querendo bater em ninguem ai nao ne!? :roll:
Venho acompanhando essa ‘discussao’ e tô achando mtooo interessante…
gostaria de agradecer a vcs, aprendi mta coisa com a briga, opsss…rs…, com o debate de vcs …
Feliz Natal !!
Espero que vc tenha concluído que JSF = http://en.wikipedia.org/wiki/Rube_Goldberg_machine
Mas tudo é subjetivo… Então sejamos felizes com as nossas escolhas, sejam elas quais forem…
heheheh…
essa foi boa saoj…
Recentemente comecei a definir um projeto individual. Vai ser um projeto web. No entanto ainda não defini com o que vou desenvolver, já que não conheço muitas tecnologias. Meu espaço se limita a JSP, servlet, Stuts 1.1 e JSF. Confesso que de todas elas a que mais me atraía era JSF. Já participei de um projeto grande(50.000 hrs) usando struts(o cv ficaria feliz :lol: ), e depois disso espero que nunca mais na minha vida eu trabalhe com esse negocio. Tenho participado de pequenos projeto em JSF, e não uso uma IDE pra fazer o serviço, faço praticamente tudo no braço.
Das tecnologias que conheço, acho JSF a melhor, mas acho que tem muita limitação ainda, e as vezes me geram problemas que dão muita dor de cabeça.
Estava quase decidido a usar JSF no meu projeto pessoal, por achar mias fácil e ter um conhecimento razoável, mas acho que vou estudar outras alternativas como rails ou outras.
Mesmo porque vou precisar de escalabilidade no projeto, e usar uma tecnologia que poucos são a favor me deixa com um pé atrás.
Legal a discussão deste thread. Foi uma das que eu mais aproveitei.
Não parta para o Struts 1.x não. Ele já foi muito usado, e na época era o que tinhamos. Mas hoje esta ultrapassado e tem coisas bem melhores hoje.
Tente também os frameworks ageis* em Java. Temos dois bons exemplos brasileiros, o JRaptor e o Mentawai
http://www.mentaframework.org/
http://www.vraptor.org/
Essa discussão trouxe algumas lembranças do fundo do baú. Quando programava em C++ há alguns anos lembro que havia uma opção do compilador que permitia a emissão do código Assembly em formato “legível” por seres humanos, resultado da compilação do código-fonte em C++. Lembro que em algumas tarefas que exigiam timing muito preciso ou controlavam algum aspecto do hardware, nós tinhamos a opção de editar esse Assembly e compilá-lo diretamente com o masm, eliminando alguns vacilos do compilador C++ que consumiam clocks preciosos numa época de hardware escasso. Após algum tempo, os compiladores ficaram mais espertos e nós abandonamos essa prática.
Creio que parte das reservas quanto à adoção de JSF/ASP.NET pelo pessoal “high-end” seja justamente o fato de que não é possível atualmente ter controle absoluto sobre o que o browser vai renderizar. Se o requerimento da aplicação envolve emitir tags bem comportadas, css e xhtml compliant, então esses frameworks deixam a desejar. Isso acontece porque os componentes que você coloca em um form emitem suas próprias tags, afinadas para o caso de uso médio - que afinal pode não ser o que você deseja. Embora alguns ambientes permitam customizar a geração de código isso acaba tornando-se uma tarefa paralela e muitos acabam desistindo da idéia e fazendo tudo na mão ou com a ajuda de frameworks mais leves. Isso sem falar na largura de banda: programadores experientes tendem a criar código mais compacto que se comporta melhor quando carregado a partir da Web.
Por favor, veja que não estou dizendo que JSF/ASP.NET geram apenas lixo e caos. Estou dizendo que para algumas aplicações com requerimentos especiais o código gerado pode não ser adequado.
Esse aspecto particular da tecnologia (geração de código) é bem interessante e talvez mereça um fórum especifico.
That’s All !!
xandroalmeida wrote.:Não parta para o Struts 1.x não. Ele já foi muito usado, e na época era o que tinhamos. Mas hoje esta ultrapassado e tem coisas bem melhores hoje.Sem partir pra briga, poderiamos incluir ai o Struts 2.0.11 " http://struts.apache.org/2.x/ " ele é bem prático e simples.
bom, eu tinnha respondido no inicio da thread, e depois de ler todos os post acho que esse comentario reflete exatamente o meu pensamento.
volto a dizer, JSF tem facilidades, principalmente se vc usar uma IDE que de suporte, mas EU particularmente não gosto muito.
Um dos motivos é o citado acima.
Ainda não vi nada que gere codigo java de forma decente, talves a propria linguagem limite isso, não sei. Mas por isso não gosto muito de frameworks que p/ vc ser produtivo se baseia em wizards.
[]´s
Acho que ta longe ainda de máquina escrever código melhor que o ser humano
Compiladores como o gcc fazem otimizações de código bem específicas de cada caso afim de gerar o assembler mais adequado. Não é impossível um ser humano fazer isso, mas é insano achar que alguém avaliaria as melhores situações para cada instrução em milhares de linhas de código. É aí que a máquina é melhor.
Compiladores como o gcc fazem otimizações de código bem específicas de cada caso afim de gerar o assembler mais adequado. Não é impossível um ser humano fazer isso, mas é insano achar que alguém avaliaria as melhores situações para cada instrução em milhares de linhas de código. É aí que a máquina é melhor.
E quem falou de otimizações de compiladores ? Estamos falando de geradores de códigos a partir do zero. Demos como exemplo IDEs fabulosas para gerar código para JSF e outras porcarias semelhantes.
é acho que o JSF precisa de mais uns 5 anos ainda…
ele é legal pra quem ta migrando da programação desktop para WEB, mas não sei por que sinto um certo disturbio na força quando vejo sistemas em JSF 
Pessoalmente EU (tambem) não gosto de JSF, mas pagando bem que mal tem, ne?
Galera nao usem JSF, porque é uma bosta!!!
Deixem que eu uso, e dai eu ganho toda a grana dos projetos por vcs, e enquanto vcs tao fazendo um crud-tabular eu ja to nas validacoes com Seam !!! :roll:
outra ponto importante é que usando uma IDE com suporte voce pode ser muito produtivo usando JSF.
mas não se esqueçam que produtividade NÃO É SO TEMPO DE DESENVOLVIMENTO.
O maior custo de um software é manutenção(não seio nde coloquei o link sobre isso).
[]´s
Galera nao usem JSF, porque é uma bosta!!!Deixem que eu uso, e dai eu ganho toda a grana dos projetos por vcs, e enquanto vcs tao fazendo um crud-tabular eu ja to nas validacoes com Seam !!! :roll:
[]´s
Ta bom vc´s sabem td de jsf entao alguem me explique como gerar wml apartir do jsf tipo hora que o cliente acessar a pg se for celular mostra wml se for browse normal mostra html como se faz isso?
Isso não tem nada haver com JSF. Simplesmente essa informação virá num header, daí vc saberá se tem que jogar o cara para o site em html ou para o site em wml. E nem pensa em usar XSTL para ficar transformando XML em HTML em WML em XXX. Isso foi outra coisa tipo EJB e JSF que passou longe de dar certo… Alguém chegou a usar cocoon?
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 ???
Isso não tem nada haver com JSF. Simplesmente essa informação virá num header, daí vc saberá se tem que jogar o cara para o site em html ou para o site em wml.
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 ???
Alguma coisa que roda WML e não HTML muito provavelmente não vai ter suporte a JavaScript, então os seus componentes serão praticamente NULOS ou Não-existentes.
WML (o tal do WAP) nunca existiu na minha opinião… é uma coisa tosca que serve para muito pouco… se vc quer um site em WML, vc terá uma versão para web e outra para WML totalmente independente e diferente, ambas acessando a mesma base de dados…
WAP/WML não conseguiu nem engatinhar… eu cheguei a mexer com isso… era uma coisa muito triste… não existe mundo celular/web antes do IPhone… a coisa começou/nasceu agora com o Iphone…
e isso não absolutamente nada haver com JSF
hum dexa eu ver se entendi entao vai ter que ser separado mesmo uma pg html e outra pra wml, mas da para usar os componentes do jsf pra isso né os input e output ai eu mudo o renderkit é isso?
ha e o mobilefaces qdo usar isso?pra que serve especificamente?quais recursos oferece?
Galera nao usem JSF, porque é uma bosta!!!Deixem que eu uso, e dai eu ganho toda a grana dos projetos por vcs, e enquanto vcs tao fazendo um crud-tabular eu ja to nas validacoes com Seam !!! :roll:
Validacoes? Mas eu fiz em Rails e ja terminei…
Validacoes? Mas eu fiz em Rails e ja terminei…
parabnes entao vaza, cai fora e deixa o jsf pra nos o homem rails :twisted:
:shock: :shock: :shock:
parabnes entao vaza, cai fora e deixa o jsf pra nos o homem rails :twisted:
Este tópico já teve dias melhores. :shock:
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” .:
Olá Amigos… discussãozinha acirrada. Bem, posso estar completamente maluco e falando a maior besteira da minha vida, mas vocês não acham que a discussão toda roda em cima de framework web component-based vs action-based?
Vamos lá… desenvolví várias aplicações em Struts 1, ainda não conhecí Struts 2, ví exemplos do WebWork e do Mentawai, ainda não ví do VRaptor… Basicamente Action Frameworks trabalham de maneira similiar e abstrações parecidas. Não vou citar Rails pois não conheço tanto para fazer comparações.
O que quero colocar aqui é que JSF, ou qualquer framework component based, trabalha com uma abstração melhor que frameworks action-based, e melhores abstrações são mais fáceis de serem construídas e mantidas. Deixa eu pegar um exemplo Mentawai vs SEAM:
package org.helloworld.action;
import java.util.Collection;
import org.helloworld.entity.User;
import org.helloworld.service.UserService;
import org.mentawai.core.BaseAction;
import org.mentawai.filter.ModelDriven;
public class UserAction extends BaseAction implements ModelDriven {
private UserService userService = new UserService();
public Object getModel() {
return userService;
}
public String add() {
if (isPost()) { // POST
String name = input.getStringValue("name");
if (name == null || name.trim().equals("")) {
addError("Por favor digite um nome!");
return ERROR;
}
User u = input.getObject(User.class);
userService.add(u);
return SUCCESS;
} else { // GET
return JSP;
}
}
public String list() {
Collection<User> users = userService.getUsers();
output.setValue("users", users);
return SUCCESS;
}
}
Usando o SEAM, essa Action poderia ser um Application Facade:
package application;
import java.util.List;
import domain.User;
import domain.UserRepository
import org.jboss.seam.annotations.In;
import org.jboss.seam.annotations.Name;
@Name("usuarioFacade")
public class UsuarioFacade {
@In
UserRepository repository;
@In
User user;
public void add() {
repository.add(user);
}
public List<User> getUsers() {
return repository.getAll();
}
}
Os dois exemplos acima fazem a mesma coisa. Antes de comentar vamos às páginas:
Primeiro no Mentawai (partes não interessantes foram cortadas):
<h3>Please enter you name:</h3>
<mtw:outError><font color="red"><mtw:out /></font><br /><br /></mtw:outError>
<form action="<mtw:contextPath />/UserAction.add.mtw" method="post">
<mtw:input name="name" type="text" size="20" /> <br /><br />
<input type="submit" value="Say Hello" />
</form>
<h2>The following persons have said "hello" to Mentawai:</h2>
<mtw:list value="users">
<mtw:isEmpty>
<h4>Nobody has said so yet!</h4>
</mtw:isEmpty>
<mtw:loop var="user">
<mtw:out value="user.name" /><br />
</mtw:loop>
</mtw:list>
No SEAM:
<h:messages globalOnly="true" styleClass="message"/>
<h:form>
Please enter your name:
<h:inputText value="#{user.name}"/>
<h:commandButton action="#{usuarioFacade.add}"/>
</h:form>
<h2>The following persons have said "hello" to SEAM:</h2>
<h4><h:outputText value="Nobody has said so yet!" rendered="#{usuarioFacade.users is null}"/></h4>
<ui:repeat value="#{usuarioFacade.users}" var="usr">
<h:outputText value="#{usr.name}"/>
</ui:repeat>
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é!!!
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:
package org.helloworld.action;
// imports here...
public class UserAction extends BaseAction implements ModelDriven {
private UserService userService = new UserService();
private User user;
public Object getModel() {
return userService;
}
public String add() {
if (isPost()) { // POST
userService.add(user);
return SUCCESS;
} else { // GET
return JSP;
}
}
public String list() {
output.setValue("users", userService.getUsers());
return SUCCESS;
}
}
O que está acontecendo aqui? Temos um filtro (VOFilter) que vai popular um User object com os valores do formulário e injetar na action. Se assim for desejado podemos abrir mão do input e injetar tudo na action. Como a minha action NÃO É o meu modelo de negócios ou o meu facade/service, então não vejo problema em utilizar o input ali, mas tem gente que prefere abrir mão dele, talvez para deixar a action bem desacoplada do framework, como se um TOTAL desacoplamento fosse possível ou desejável. Ele só deve ser possível e desejável para o seu modelo de negócios e fachadas (services).
Nó código do SEAM, não entendi como a lista de usuários vai chegar na camada view. Faltou um return ou um outject ali. Ou um getter... Não sei...
O código HTML me parece bem parecido, mas o inputText com o value não é legal, poderia ser como o Mentawai que calcula o valor internamente (no caso de checkbox por exemplo, o value não vai te ajudar em nada). Também não entendi da onde ele pega o parametro name. Talvez tenha faltado um name="name" ali...
Minha única crítica ao seu comentário é que vc não mencionou como as coisas efetivamente acontecem e são codificadas no SEAM. A classe que vc listou não é equivalente a classe UserAction do Mentawai. Ela é equivalente a classe UserService (poderia ser UserFacade) que eu listo abaixo e que está incluída no exemplo do Mentawai:
package org.helloworld.service;
import java.util.Collection;
import org.helloworld.entity.User;
import org.helloworld.repository.UserRepository;
public class UserService {
// Injeção vai acontecer aqui (IoC)
private UserRepository userRepo;
public UserService() { }
public void add(User user) {
userRepo.add(user);
}
public Collection<User> getUsers() {
return userRepo.getUsers();
}
}
O facade do Mentawai é IGUAL ao facade do SEAM. A questão é que entre o FACADE e a requisição web há uma action que vai organizar o meio de campo. Muitas vezes ela funciona simplesmente como um ponte. Outras vezes checa se temos um POST, se temos cookies, se temos algo na session, qual o IP da requisição, qual o browser, etc e tal. Quem faz esse meio de campo no SEAM? Um arquivo XML? Como vc pode querer abstrair ou ignorar isso? Alguém tem que ser responsável por isso e, ao meu ver, esse é o papel da action: fazer o meio de campo entre o facade e a requisição web.
Também faltou explicar como o SEAM faz o pool de conexões, a inversão de controle para injetarmos o repositório correto, o auto-wiring da conexão pra dentro do repositório, configuração das páginas JSP que vão tratar dessa requisição, persistencia do objeto User no banco de dados, etc. Essas coisas com certeza não vão acontecer por mágica e se vc pensar bem são 90% do trabalho pesado de uma aplicação web. É isso que o Mentawai procura abstrair do usuário.
A abstração que vc falou é realmente importante. O Mentawai separa claramente UserAction do UserFacade. No seu caso o UserFacade ficou atrelado ao framework em questão. No caso do Mentawai o acoplamento do Facade é zero.
A questão de indicar no botão qual a action que será executada não me parece muito diferente de indicar na action do formulário qual a action que será executado pelo framework. É a velha questão de transformar programação web em programação desktop orientada a eventos. Eu não acho isso legal, mas há muitas pessoas que, talvez por terem tido muita experiência com desenvolvimento desktop (Visual Basic, Delphi, etc), prefiram encarar a coisa dessa maneira.
O objetivo do Mentawai desde os primórdios foi abstrair toda a complexidade e trabalho pesado de uma aplicação web e também eliminar o XML. Acredito que hoje em dia, o primeiro objetivo é o que diferencia o framework dos outros, mesmo sabendo que a grande maioria ainda insiste no XML e/ou Annotatinos, o que além de contra-produtivo é desprazeroso.
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.
Me desculpe, estou tentando colaborar e aprender também. Acho que a minha pergunta foi válida.
Mas se eu tiver que tratar um cookie, como eu faço? Se quiser pegar o IP da requisição para passar para o meu model, como eu faço? Se eu quiser pegar um header da requisição para saber em que browser o cara está, como eu faço? Onde eu configuro o IoC e o DI? Onde configuro o pool de conexões? Só estou tentando entender onde isso vai estar se não estiver na action… Annotations-programming ou XML-programming…
Validação em XML ou Annotations é péssimo. Se duvida então dá uma olhada no Struts2, que vc citou como exemplo: http://struts.apache.org/2.x/docs/validation-annotation.html
Validação feito em código Java é bem melhor, na minha opinião. Para uma comparação você pode dar uma olhada aqui: http://forum.mentaframework.org/posts/list/1112.page
Sua opinião, que eu respeito. A minha é bem diferente…
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.
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.
Se é post ou se é get o Seam consegue injetar na Façade. Porém, creio que são poucos os casos que a chamada se diferencia por POST ou GET. O Seam possui uma maneira de deixar as coisas RESTFull, não pesquisei isso pois até o momento a injeção do Seam resolveu a minha vida. Quanto a arquivos XML, o Seam não usa, só se você quiser (minha aplicação atual não tem 1 linha de XML para configurações funcionais). O XML de configuração do Seam é bem limpinho, é convention over configuration até o último fio de cabelo.
A validação ocorre, só que não precisamos nos preocupar com ela. Dá pra fazer via Hibernate Validator ou na Action… mas o Validator é bom, resolve 99% dos casos, quando não resolve, colocamos na Action ou no próprio Entity usando código Java no @PrePersist/Update.
Sim, mas você vê que eu preciso ficar lidando com esse filtro? A abstração que a implementação JSF do SEAM me traz é que o que estou mexendo na view é o meu Entity, e não algo que será enfiado dentro de uma HttpServletRequest que é uma tripa de Strings que vai cair dentro do meu Entity. Eu poderia até referenciar #{user.adress.streetName} na minha view de forma transparente, tanto para obter o dado como para settar o dado (e o framework validaria). Independente do Action Framework, enfiar coisas no request sempre me obrigam a lidar com tripas de String.
Faltou um return… já corrigi a listagem.
ué, porque não é legal? Quando vejo um <h:inputText value="#{user.name}"/> a abstração que me vem a cabeça é que quero um campo de entrada de texto para a entidade user, propriedade name. Não está faltando nada no código.
Bom, como falei não é uma crítica. O código SEAM está completo para essa aplicação. E é aí que a mágica acontece, como não preciso me preocupar com a infraestrutura Web, o Seam não precisa de algo que se chama Action. O pessoal do Seam até chamam o que chamei de Facade como Action, mas não tem a mínima razão para essa nomenclatura. Esse backing bean não é uma Action, poderia até ser um EJB Stateful. Esse backing bean é um Application Facade a lá Fowler. Não preciso da Action. Pra falar a verdade, algumas situações nem preciso da Façade. Um CRUD como exemplo daria para ser implementado inteirinho na VIEW sem abrir mão de OO e com um código XHTML muito limpo. (veja link)
http://docs.jboss.org/seam/1.2.1.GA/reference/en/html/framework.html
Como falei, é esse nível de abstração que gostei de trabalhar: LIGAR A VIEW DIRETAMENTE À CAMADA DE APLICAÇÃO, sem me preocupar com infraestrutura Web. E melhor, o troço funciona e é MUITO produtivo. É produtivo mesmo fazendo os XHTML na mão como eu faço. JSF não é dependente de ferramenta. Fazer JSF na mão com o Seam é mais produtivo que fazer JSP na mão com Action Frameworks (isso é extremamente IHMO). Como é IMHO, meu sentimento é que com o Seam a abstração é melhor, o código é mais claro e raramente você entra em Débito Técnico.
É esse meio de campo que traz abstrações pobres para Action Frameworks. Pare para ver e você verá que para a maioria das aplicações web e com banco de dados o que mais ocorre são POSTs. Se precisamos lidar com Cookies e outros é só acessar @FacesContext. Realmente isso não é tão natural para o Seam, mas também não é algo que você precisa ficar lidando toda hora.
Não sei porque você fala tanto em XML… Não tem nada oculto em XML no SEAM… particularmente, eu tenho NOJO de XML e a culpa disso foi um projeto Spring relativamente grande. Gosto do Spring, mas só volto a usar ele quando der para fazer tudo em Annotation ou outra convenção…
Faz tudo isso em cima de tecnologia Jboss ou Ejb3. IOC/DI uso EJB3. Configuração das páginas JSP não precisa. Você pode controlar o fluxo da própria Facade, ou se quiser em arquivo XML. Eu faço na propria Facade (é só colocar um return “/usuario.xhtml” e fazer o method binding retornar String).
Discordo muito de você nesses 90%. A parte servidora da aplicação é feita em minutos com EJB3, JPA, Hibernate Validator e DDD. O que realmente enche o saco e toma tempo é integrar isso com camada de apresentação, principalmente quando o Binding não é transparente. As vezes até acho que tenho algum bloqueio mental ou algo do tipo, mas fazer entidades, repositórios, regras de negócio é muito fácil na minha opinião com essas ferramentas que citei.
Bem, minha Facade é POJO. Só tem anotações do SEAM. Se por alguma razão eu precisar ligar ela com o Mentawai seria possível e fácil (seria só implementar a Action, mas como falei, no Seam eu não preciso dela). Como você mesmo falou, ela é bem parecida com o seu service. :lol:
Sim, a abstração do Visual Basic e do Delphi é melhor nesse sentido, assim como as aplicaçõezinhas Swing que desenvolví. Se eu precisar que o mesmo formulário execute duas funções no SEAM/JSF é assim:
<h:form>
Please enter your name:
<h:inputText value="#{user.name}"/>
<h:commandButton value="Criar" action="#{usuarioFacade.add}"/>
<h:commandButton value="Remover" action="#{usuarioFacade.remove}"/>
</h:form>
Como isso seria feito num Action Framework? (no Struts eu recorria a JavaScript ou tratamentos na Action). Seja sincero, que abstração é melhor? Limpe a sua cabeça de toda experiência que teve com Action Frameworks e do HTML puro e responda: Um formulário é uma acão?
saoj… sei que você foi o cara que concebeu o Mentawai… quero que você tenha em mente que não é crítica e nem comparação Mentawai x Seam. Mas sim, como falei, é Action Framework vs Component Based Framework, levando em consideração “abstrações melhores”. Mas por conta, nesses exemplos, prefiro escrever @Name(“usuarioFacade”) do que implementar umas 10-15 linhas de Action.
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)
Um paralelo: Eu acredto que DSLs são melhores que GPLs para desenvolver alicações. Ate’hoje não vi nenhuma ferramenta ara DSL realente usável então ão uso DSL como gostaria.
Da mesma forma se a melhor ferramenta ara desenvolver uma coisa não está dentro do que e considero aceitável e não a usaria. Eu uso JSF ara coisas simples mas não colocaria esta ferramenta coo fturo de nada, é apenas a coisa menos pior seguindo este paradigma que eu conheço. Para fazer algo mais comlexo e abro mão alegremente do conceito que doeria ser melhor em favor de uma ferramenta melhor.
Crie uma aplicação Restful com interfaces em HTML e HTTP para as mesmas coisas. Este é o tipo de aplicação que faz uso de HTTP.
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.
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…
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.
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:
<mtw:input name="name" />
É 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
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…
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!)
Galera nao usem JSF, porque é uma bosta!!!Deixem que eu uso, e dai eu ganho toda a grana dos projetos por vcs, e enquanto vcs tao fazendo um crud-tabular eu ja to nas validacoes com Seam !!! :roll:
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
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.
:roll:
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
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…
caraca kvillaca vc acaba de ressucitar um dinosauro. :shock:
Rapaz que tópico, fui pesquisar sobre VRaptor achei um comparando VRaptor com JSF e acabei chegando nesse. Tirando a parte do RoR que não tem nada haver com o tópico achei a discussão boa e foi legal ver 2 anos depois as novas opiniões. Achei tão legal que queria ver as opiniões hoje, passando quase 4 anos, com JSF 2 e JEE 6 no mercado, com a compra do Java pela Oracle, Java 7, e surgimento de novos framework o que ainda acham sobre o JSF, é o futuro nas empresas?
Vou dar minha humilde opinião. Tenho 34 anos e 17 anos de experiência na área, comecei com Cobol, depois fui para VB, passei por PowerBuilder e acabei parando no Java. Porque parei no Java, na minha opinião Java é diferente de tudo o que já tinha visto pelo simples fato de Java não ser uma linguagem como Cobol, VB, Clipper, Delphi, PowerBuilder, etc… e sim uma Plataforma. O que não existe em Java? Citaram 2 coisa aqui named routes e ActiveRecords? Acredito que possa ter surgido alguma coisa nova que não existe no Java e pouquíssimos projetos dependem disso, mas tenho certeza que em breve será incluído. Trabalho apenas 6 anos com Java, antes de começar fiz uma especialização de 18 meses voltada somente ao Java, desde HTML/CSS, passando por Servlet, JSP, JSTL e terminando no JSF. Felizmente os projetos que trabalhei e ainda trabalho são JSF, teve alguma exceções e cheguei a mexer em um com Struts, Servlet puro e agora estou tendo que usar o VRaptor. Se eu pudesse escolher usaria JSF em todos. Pelo simples fato de ser a tecnologia que mais me sinto produtivo. Por já está acostumado.
Li alguém dizendo que Cobol parou no tempo e isso é mentira basta ver em http://en.wikipedia.org/wiki/COBOL. Se o Cobol ainda não parou no tempo imagine o Java.
Estou fechando minha mente para as novas tecnologias que surgem aos montes todos os anos? Não, ainda tem muita coisa em Java para aprender e muita coisa a aprimorar. Observo que a maioria dos comentários contra JSF são dito por quem não usa, não gosta ou defende outra tecnologia. Muitas vezes as pessoas não sabem, acham que sabe ou tiveram uma experiencia mau sucedida e já taca pedra na tecnologia. Problemas tem em todas, soluções também. Não existe bala de prata, mas Java tem bala para todo tipo de calibre. Pode até ser que tecnologia B faz determinada coisa com N/2 linha de código que Java, mas e o custo de ter que aprender essa nova tecnologia só para economizar N/2 linha de código não é muito alto? Desenvolvedor poliglota é a melhor coisa para o dono da empresa que acha que um funcionário pode dominar mais de uma tecnologia e para isso ele não precisa contratar outro. Esse é o sonho dos OutSourcing, o cara sai de um projeto com tecnologia A e no outro mês já está em outro com tecnologia B. E quanto a qualidade desse código gerado? O Papa fala não sei quantas linguás, mas em quantas ele consegue escrever um livro?
Para mim JSF continuará nas empresas pelo simples argumento da Longevidade. Afinal ela é a especificação da comunidade. Ela surgiu e continuará se aprimorando diante do sucesso de tecnologias paralelas. Basta observar a evolução do JSF 1 para o 2. Pegaram o que o Struts, Spring, Seam, etc… tinha de bom e incorporaram. Assim tb com JEE. Na minha opinião todos deveriam usar, opinar, sugerir e ajudar a especificação evoluir. A maioria dos post contra JSF são de gente tentando convencer as pessoas a usarem seu framework, ou seguir a onda da nova tecnologia, qualquer que seja ela, sempre vai surgir um que vai aprender e tentar convencer a aprendermos também por que ninguém quer ficar só.
Esse grupo é de JAVA e acho que todos deveriam defender e disseminar o uso dele e não vim aqui e dizer que Rails, Scala, etc… é melhor. Ainda bem q algumas precisam da JVM.
Falaram aqui que JSF gera lixo no HTML, mas isso é uma implementação da JSF, nada impede de vc criar uma que gere HTML Semântico. Realmente o intuito original do JSF era dar poder a IDE de criar interface parecida com .NET, do tipo arraste e solte. Até existe algumas boas e o próprio NetBeans evolui muito, mas a maioria de quem usa e gosta de JSF, faz na mão mesmo sem comprometer a produtividade. Vamos usar EJB2, logico que não, mas como alguém fez o favor de mencionar o problema não era no EJB2 e sim na atitude errada de querer usar o EntityBean para tudo e isso ainda hoje acontece muito em outro conceitos, as pessoas usam a tecnologia de forma errada, sem conhecimento e depois dizem q ela não presta (Isso eu tive a oportunidade de ver na pratica e na época questionei com o time que isso era errado mas ao invés de ouvir e aprender se resumiram a dizer “É a especificação que manda”).
Eu como sou mais novo, não sou moderador, fodão e nem tenho blog fico mais na escuta, mas não pude deixar de dar meus 0,2344 de contribuição. Também posso esta errado, mas estou nadando junto com a comunidade e ela tá evoluindo e com a ajuda dos fodões vai evoluir mais rápido.
A discussão acaba aqui. Se vc é produtivo e se sente confortável então posso afirmar com seguranca que JSF é excelente e bem produtivo para raphael_pf.
Agora pega um cara que nunca viu JSF nem Wicket nem Click e passa um projeto pra eles. Acho que o JSF vai apanhar pelas suas complexidades desnecessárias o que leva a uma curva de aprendizado grande.
Não estou nem colocando no mesmo saco frameworks action-based. Fica difícil comparar VRaptor, RoR, Mentawai com JSF.
Eu nem sei como está o JSF, mas quando foi lancado era muito ruim mesmo. Claro que depois de refazerem a coisa do zero 23 vezes, já deve estar legalzinho, mesma coisa que aconteceu com o infame EJB1.
Que o mercado utiliza jsf não há dúvidas, que o jsf facilita o desenvolvimento de interfaces mais ricas e atrativas também não é novidade.