Diferença entre Apache Tapestry e Apache Wicket

Question

Postigo Apache ( http://wicket.apache.org/ ) e Tapeçaria Apache ( http://wicket.apache.org/ ) são estrutura web orientada a componentess - ao contrário de estruturas baseadas em ação como Stripes - da Apache Foundation.Ambos permitem que você construa seu aplicativo a partir de componentes em Java. Os dois são muito parecidos comigo.

Quais são as diferenças entre essas duas estruturas?Alguém tem experiência em ambos?Especificamente:

• Como está o desempenho deles, até que ponto o tratamento de estados pode ser personalizado, eles podem ser usados ​​​​sem estado?
• Qual é a diferença em seu modelo de componentes?
• O que você escolheria para quais aplicações?
• Como eles se integram com Guice, Spring, JSR 299?

Editar:Eu li a documentação de ambos e usei ambos.As perguntas não podem ser respondidas suficientemente com a leitura da documentação, mas com a experiência de usá-la por algum tempo, por ex.como usar o Wicket em modo stateless para sites de alto desempenho.Obrigado.

Answer 1

Algumas diferenças relevantes a meu ver:

• A tapeçaria usa uma estrutura de página semi-estática, onde você pode trabalhar com condicionais e loops para obter um comportamento dinâmico.Wicket é completamente dinâmico;você pode carregar componentes dinamicamente, substitua-os em tempo de execução, etc.As consequências de isso é que a tapeçaria é mais fácil de otimizar, e que Wicket é mais flexível em seu uso.
• Ambos os frameworks são aproximadamente igualmente eficientes em execução, mas Wicket confia em armazenamento do lado do servidor (por padrão, o página atual na sessão e passada páginas em um 'cache de segundo nível' que é padrão um arquivo temporário no arquivo sistema).Se isso te incomoda, pense sobre quantas sessões simultâneas você espera ter em horários de pico e Calcule com digamos ~100kb por sessão (que provavelmente está no lado alto).Isso significa que você pode executar aproximadamente suporte a 20k sessões simultâneas para 2GB.Diga 15k porque você precisa disso memória para outras coisas também.De claro, uma desvantagem de armazenar estado é que só vai funcionar bem com afinidade de sessão, então isso é um limitação ao usar Wicket.O A estrutura fornece um meio para implementar páginas sem monitoração de estado, mas se você está se desenvolvendo totalmente sem estado aplicativos que você pode considerar um quadro diferente.
• O objetivo do Wicket é oferecer suporte máximo à digitação estática, enquanto o Tapestry trata mais de salvar linhas de código.Portanto, com o Tapestry, sua base de código provavelmente é menor, o que é bom para manutenção, e com o Wicket, você é digitado estaticamente, o que facilita a navegação com um IDE e a verificação com um compilador, o que também é bom para manutenção.Algo a dizer para ambos, imho.

Já li algumas vezes que as pessoas acham que o Wicket funciona muito por meio de herança.Gostaria de enfatizar que você tem uma escolha.Existe uma hierarquia de componentes, mas o Wicket também suporta composição por meio de construções como IBehavior (sobre as quais, por exemplo,O suporte Ajax do Wicket é construído).Além disso, você tem coisas como conversores e validadores, que você adiciona aos componentes, globalmente, ou mesmo como uma preocupação transversal usando alguns dos ouvintes de fase que o Wicket fornece.

Answer 2

REVISADO depois de estudar Tapeçaria 5.

O gol do postigo é uma tentativa de fazer desenvolvimento web semelhante à GUI de desktop um.Eles conseguiram fazer isso muito bem às custas do uso de memória ( HTTPSession ).

Objetivo da Tapeçaria 5 é fazer muito otimizado (para CPU e memória) framework web orientado a componentes.

A grande armadilha para mim foi respondido "Wicket suporta componente apátrida!" aos argumentos "Wicket tem fome de memória".Embora o Wicket de fato suporte componentes sem estado, eles não são "um foco do desenvolvimento do Wicket".Por exemplo, um bug no StatelessForm não foi corrigido por muito tempo - veja StatelessForm - problema com parâmetros após falha na validação.

• IMHO usar o Wicket é um pouco mais fácil até que você otimize/ajuste os parâmetros do aplicativo da web
• IMHO Wicket é mais difícil de estudar se você programou aplicativos da web e deseja pensar em termos de processamento de solicitações
• Tapeçaria 5 automaticamente recarrega classes de componentes assim que você os alterar.Ambas as estruturas recarregam a marcação do componente.
• Forças de postigo marcação/separação de código, Tapestry 5 apenas oferece essa habilidade.Você também pode usar uma sintaxe menos detalhada no Tapestry 5.Como sempre, esta liberdade exige que sejam tomadas mais precauções.
• O núcleo do Wicket é mais fácil de depurar:os componentes do usuário são baseados em herança, enquanto os componentes do usuário do Tapestry 5 são baseados em anotações.Por outro lado, isso poderia tornar as transições para as versões futuras mais fáceis para o Tapestry do que para o Wicket.

Infelizmente Tutorial de tapeçaria 5 não enfatiza que exemplos de código do Tapestry como 't:loop source="1..10"...' podem ser uma prática ruim.Portanto, algum esforço deve ser feito para escrever convenções/boas práticas de uso do Tapestry se sua equipe não for muito pequena.

Minhas recomendações:

• Use o Wicket quando a estrutura de suas páginas for muito dinâmica e você puder gastar de 10 a 200 Kbs de memória HttpSession por usuário (esses são números aproximados).
• Use Tapestry 5 nos casos em que você precisa de um uso mais eficiente de recursos

Answer 3

Aqui está uma comparação bastante completa do Developer Works da IBM.

http://www.ibm.com/developerworks/java/library/os-tapestrywicket/index.html?ca=drs

Atualizar:o link está morto, mas você pode encontrar a página em http://web.archive.org/web/20131011174338/http://www.ibm.com/developerworks/java/library/os-tapestrywicket/index.html?ca=drs

Answer 4

Acho que o Wicket é um framework mais simples de usar.

Além disso, o Wicket permite o recarregamento de classes por meio do sistema de substituição de código ativo do seu IDE.Isso é tudo o que é necessário para o Wicket executar versões modificadas das classes de um aplicativo atualmente em execução.As restrições usuais se aplicam à substituição de hot-code, como ter que executar no modo Debug (Eclipse) e não poder alterar aspectos estruturais de uma classe (ou seja,nome da classe, alterando assinaturas de métodos, etc...).

Answer 5

Não gosto do modelo de programação Tapestry e conheço muitos desenvolvedores que estão deixando o Tapestry por causa de muitas mudanças e incompatibilidades no desenvolvimento.Ver: http://ptrthomas.wordpress.com/2009/09/14/perfbench-update-tapestry-5-and-grails/

Answer 6

Wicket é um framework web muito bom.O melhor de tudo o que sei.Eu uso desde a versão 1.3 e sempre consigo o que quero.O Wicket tem excelente integração com Spring - basta usar a anotação @SpringBean em seu código para injetar qualquer bean Spring em suas classes.

Answer 7

Tentar http://incubator.apache.org/click/ .É uma estrutura web java incrível.Algumas pessoas chamam isso de “Wicket feito certo” ;-)

Answer 8

Como eu disse quando o 4.1 era o lançamento oficial estável:

Você deve dar uma boa olhada no histórico de desenvolvimento do Tapestry antes de se comprometer a usá-lo.O Tapestry fez muitas atualizações incompatíveis, sem continuação do suporte para versões mais antigas.Patches para 4.1 não são mais processados ​​dentro de um prazo razoável.No meu ponto de vista, isso não é aceitável para a versão estável oficial.

Comprometer-se a usar o Tapestry 5 significa:

você deve se tornar um committer;você precisa acompanhar todos os novos desenvolvimentos, abandonar as versões antigas o mais rápido possível;mantenha você mesmo versões estáveis.