Foi liberada a versão 1.5 do Wicket, um framework para desenvolvimento Web para Java dentre os mais utilizados. São diversas as novidades, dentre elas:
[list]Novos componentes HTML5[/list]
[list]Simplificação do código de renderização[/list]
[list]Suporte a caching melhorado[/list]
[list]Melhor suporte para rodar atrás de proxy[/list]
[list]Configuração simples para HTTPS[/list]
[list]Novos eventos entre componentes[/list]
Mais detalhes em: http://wicket.apache.org/2011/09/07/wicket-1.5-released.html
Lá no Banco Central, aqui de brasília, o wicket é o framework padrão.
E tem vários programas em produção lá.
E em dezembro, o sistema q estou implementando entrará em produção tbm.
Lá a gente usa WiSH: Wicket + Spring + Hibernate. Usamos tbm XP E TDD
Quem utiliza o Wicket, o que poderia me dizer dele no que diz respeito a produtividade comparado a outros fremaworks como VRaptor, Struts ou JSF. É mais ou menos produtivo?
E quanto a questão performance e desempenho, em ambiente de produção, ele se comporta bem? Tem uma boa velocidade de resposta e aguenta um grande número de conexões simultâneas sem problemas?
[quote=caiosiqueira]Quem utiliza o Wicket, o que poderia me dizer dele no que diz respeito a produtividade comparado a outros fremaworks como VRaptor, Struts ou JSF. É mais ou menos produtivo?
E quanto a questão performance e desempenho, em ambiente de produção, ele se comporta bem? Tem uma boa velocidade de resposta e aguenta um grande número de conexões simultâneas sem problemas?[/quote]
Caio, em relação a produtividade, o wicket é muito bom.
Já trabalhei com Struts, JSF 1,2 e 2.0.
E comparando com esses, o wicket tem uma produtividade monstra.
É muito rapido criar telas e fluxos complexos com ele.
Pq tudo é java. Quase nada(quase nada MESMO) fica em tela.
E quando tem um bug, fica fácil achar onde é.
Já desempenho, não posso falar muito, pois não atuo muito nessa area.
A primeira vez q trabalhei com wicket em produção, ele foi tão bom quanto o Struts 2 q estava anteriormente.
Já aki no BaCen eu não sei, pq ainda não coloquei o sistema em produção, mas todo mundo aqui fala q a diferença dos novos sistemas feitos em wicket são bem melhores q os antigos feitos em Struts.
eu não consigo entender como pode ser bom esse monte de HTML, CSS e JS dentro do source misturado com o código Java, sempre pensei que isto fosse errado, sera que o problema sou eu ?
Já utilizei o Wicket em um sistema muito grande, e achei muito ruim.
Pra fazer sisteminhas quadradinhos vai bem, quando vc precisa de algo um pouco diferente é horrível.
Para otimizar a carga de JS, CSS e várias práticas para melhorar a velocidade e cache na web tem que fazer muita gambiarra, afinal ele é feito pra “esconder” a web do programador.
Sem contar que tive vários bugs relacionados a performance, pois tem vários “sinchornized” dentro do controle de sessão dele, e tive que fuçar dentro do código dele para encontrar os problemas, e o código que vi, deu até vergonha !
Sugiro antes de utilizar, baixe o código e dê uma navegada, só pra ter idéia do que eu estou falando…
Então tah bem diferente do GWT: otimizado, produtivo e maduro. Até a RedHat, que supostamente deveria utilizar JSF, já vem usando a alguns anos o GWT em suas consoles.
There’s no perfect Web Framework. Você deve utilizar o melhor framework para a combinação seu projeto+seu conhecimento prévio. Se seu projeto é para ser um portal a-lá G1, melhor usar Python/Rails/Play/Grails.
Se é para fazer uma RIA, melhor usar GWT/Flex/ExtJS/Vaadin.
Se é para fazer uma aplicação e-commerce ou corporate (crud-oriented), melhor usar JSF/Wicket/Tapestry.
Se você precisou de algo diferente que o framework não suportava, é porque provavelmente seu projeto deveria ter optado por outra tecnologia. Ninguém constrói casas com placas de aço. Estas, servem para construir carros.
Ele é feito para que você se preocupe com outras coisas. CSS e JS podem (e devem) ficar no Apache. Se você utilizou o modelo de ResourceReference para uma folha de estilo que é única para o site inteiro, fez mau uso do framework. Algo que pode acontecer com qualquer produto.
Que bom que o código é aberto, não é? Assim deu para ver o fonte e poder corrigir os problemas. Afinal, nenhum produto é perfeito. Suponho que você ofereceu as correções dos problemas que você encontrou para a Apache Software Foundation, aplicar no framework. Isso significa que a última versão (1.5.0) já esteja corrigida.
Boa sugestão. Só olhando o código-fonte para aprendermos de verdade um produto.
Utilizamos o Wicket desde a versão 1.3 aqui na empresa e vou deixar alguns comentários a respeito.
Performance: Realmente o wicket não é um “monstro” quando o assunto é performance. Algumas otimizações podem ser feitas mas, em geral, se vc usar boas práticas, pode conseguir uma performance bem aceitável com ele. Faltam-lhe algumas opções de otimização, mas como os colegas falaram, o codigo é aberto e todo mundo pode contribuir (provavelmente vão levar uma patada do Igor, mas o mundo é assim mesmo).
Memoria: O framework, pela sua natureza, consome bastante memoria do servidor. Não é necessariamente uma coisa ruim, pois eles mesmo criaram esquemas para diminuir o uso de memoria, como o cache de segundo nivel.
Produtividade: Aqui o bixo pega! Eu desenvolvia em JSF antes e a produtividade realmente é bem baixa. Usei GWT tb e alguns outros frameworks, mas com nenhum tive tanto sucesso quando tive com wicket. Além do que, é natural programar usando o framework. Aconselho a todos a experimentarem! (Alguém aqui já criou componentes em JSF??? Sinto muito!)
Manutenibilidade : O pessoal do wicket tem trabalhado duro para fazer um framework cada dia melhor. FATO! Porém, isso quebra a compatibilidade com os sitemas antigos. Portanto, se vc desenvolveu um sistema grande, migrar ele se torna uma tarefa hercúlea! Mas isso também não é privilégio somente do wicket, pois sofro com isso desde os tempos de delphi! Com o JSF nao era diferente e com o PHP tb não é!
Suporte: A comunidade wicket é demais! Muitos dispostos a ajudar e documentação bem razoável!
Bom, acho que é isso. Como sempre, não esperem respostas prontas e canonicas. Problemas diferentes requerem ferramentas distintas. Procurem conhecê-las para, quando necessário, fazer uma boa escolha!
Ah, nosso carro-chefe em wicket é um site de e-commerce (http://ewmix.com). Porém, muitos de nossos sistemas internos sao wicket e já estamos migrando vários que estavam em JSF para wicket, na medida do possível!
There’s no perfect Web Framework. Você deve utilizar o melhor framework para a combinação seu projeto+seu conhecimento prévio. Se seu projeto é para ser um portal a-lá G1, melhor usar Python/Rails/Play/Grails.
Se é para fazer uma RIA, melhor usar GWT/Flex/ExtJS/Vaadin.
Se é para fazer uma aplicação e-commerce ou corporate (crud-oriented), melhor usar JSF/Wicket/Tapestry.
Se você precisou de algo diferente que o framework não suportava, é porque provavelmente seu projeto deveria ter optado por outra tecnologia. Ninguém constrói casas com placas de aço. Estas, servem para construir carros.
[/quote]
Concordo plenamente, exatamente por isso escrevi o primeiro parágrafo, dizendo que para sistemas mais quadrados ele serve muito bem ! E infelizmente não pude alterar o framework, afinal herança de projeto é complicado Não dá pra chegar chutando as tecnologias que já existiam antes.
Quando vc cria componentes reutilizáveis, vc associa as ResourceReferences com os componentes, afinal se vc tem um Grid pronto para um projeto, e o mesmo tem CSS e JS específicos para ele, vc não copia os arquivos para cada projeto, pois seria uma violação do DRY. Porém quando vc utiliza os componentes dentro do projeto, para cada componente ele terá um “caminho” específico, o que dificulta colocar no apache para fazer cache dos resources utilizando o path para isso. Isso tem N vantagens, porém desvantagens para fazer o cache.
Muito bom que o código é aberto, concordo com vc e tb acho que nenhum código é perfeito. Estou apenas justificando o pq não acho ele uma boa opção. E a solução encontrada para os problemas que citei, foi retirar o tratamento de sessão do Wicket e trocar por um específico, e isso nao foi para o repositório deles.
E hoje EU não começaria um projeto com Wicket, mas é claro, esse é só minha opinião, baseado nos fatos que citei acima. Cada um pode tirar a conclusão que quiser, e espero que não se sintam ofendidos como pareceu o caso do Bruno.
[quote=fincatto][/quote] Gostei da sua visão, é bem parecida com relação à memória e problemas de compatibilidade entre as versões.
O ponto em que quero chegar é que não gostamos de algo geralmente por dois motivos:
1 - experiências passadas; e/ou
2 - falta de experiência
Não gosto do JSF para construir componentes, e isso é o que eu costumo fazer, e não gosto da forma como componentes são desenhados/codificados com a API do JSF.
Entretanto, como usuário do JSF para construção de páginas, principalmente usando uma IDE como o JDeveloper ou NetBeans, o JSF é do caralho, funciona muito bem.
Outro ponto: toda vez que achamos um problema em algum framework, devemos, como profissionais da área e participantes de uma Comunidade de Software Livre, discutir estes problemas com os desenvolvedores do framework. Isto terá uma de duas possíveis consequências:
1 - O usuário do framework efetivamente descobre um problema e reporta o bug ou alguma deficiência, já oferecendo um patch ou apenas um teste para reproduzir o problema.
2 - A comunidade de desenvolvedores do framework discute o problema e chega a uma conclusão de que não é problema, mas um mal uso do framework, propondo o uso correto.
