Versão 1.3 do framework Apache Wicket é lançada

hoje foi lançada a nova versão do framework Apache Wicket que agora já tem uma versão estável (1.3) e graduada pela Apache.
Apache Wicket é uma framework web baseada em componentes seguindo a idéia e o “estilo de programação” com swing, conseguindo assim uma programação mais OO.
Como é um projeto graduado, possui o mesmo destaque de outros projetos já consagrados da Apache como Struts, Maven, Tomcat, Velocity entre outros

Segue abaixo algumas melhorias e novidades:

Eu não consegui sair do trivial com o Wicket.

Alguem já fez algo profissional? Relate como foi.

Estou fazendo um projeto pessoal com o wicket, até agora estou adorando…
Oque ainda está pegando é a falta de tutoriais e artigos, o material na internet ainda é pouco para usar o wicket com tranquilidade.

Muito produtivo, vários componentes prontos, e a comunidade ( em geral americana ) ajuda muito nas listas de e-mail…
Nas paginas html as tags que o wicket necessita para fazer seu processamento não é intrusivo, sendo que um designer pode facilmente fazer o template html e o programador só vai colocar as tags onde há necessidade.
Código limpo e organizado, maior orientação a objetos, fácil reutilização de componentes entre outros.
O projeto DataBinder que cria uma ponte entre wicket e hibernate tornando essa ligação transparente facilita muito e torna super produtivo programar com o wicket.

Bom, oque está ruim ainda é a falta de informações na internet, tutoriais, artigos e até mesmo livros, que até agora só existem 2, o Wicket in action ( está para lançar ) e o Pro Wicket os 2 em inglês.

Estou tentando tirar um tempo para me dedicar a um blog sobre o wicket para disseminar essa framework na comunidade brasileira.

é isso…

flooowwww

1 curtida

Legal, mas estava pensando aqui…

Depois de dar uma olhada na simplicidade de frameworks como ruby on rails, por exemplo, você fica até assustado ao ver os exemplos de frameworks como esses… :slight_smile:

o click é bem mais simples que o wicket

Concordo com vc, mas qual é a escolha mais provavel de uma empresa que quer fazer um site grande, seguro e estavel, agredito que entre ruby on rails e wicket, a escolha vai ser wicket, por causa de todos os pontos positivos que a jvm oferece…
Concordo que simplicidade é um grande ponto positivo de uma framework ou linguagem, mas não q isso seja o principal, existem pontos que tem maior relevancia como os já citados.
Adoro e programo ruby on rails, mas acho q a comparação não pode ser entre ror e wicket, acho q uma comparação mais aceita é entre a framework click e o wicket…

Nunca usei o click, só dei uma fuçada nele… mas tb me parece ser um projeto promissor…

ricardolecheta, pq vc acha o click mais simples que o wicket, é interessante discutir isso e expor os pontos fortes e fracos de cada framework.

floowww

Você acha então que RoR não está preparado para ser usado em grandes projetos? pergunto pois estou iniciando agora os estudos em RoR e não tenho conhecimento suficiente a respeito.

Sobre as vantagens da jvm e quanto ao Jruby? Não ofereceria essas vantagens ao desenvolvimento rails?

Não sou um profundo conhecedor da linguagem ruby, mas indo pelo raciocinio lógico, quais das 2 linguagens foram mais testadas!!! java possui uma jvm tunada, que já foi exaustivamente testada e retestada, java é uma linguagem consolidada, comprovadamente segura… já ruby eu não posso afirmar isso com toda a certesa…
Eu não apostaria minha carreira em uma linguagem que está em fase de amadurecimento em um projeto grande, acho q o estudo sobre ror é muito importante, pois é uma linguagem muito promissora mas no momento ainda não é madura o suficiente ( galera, minha opinião hein :wink: )

o Jruby é um compilador que converte codigo ruby em bytecode java. ( pode corrigir se eu estiver errado! )
esse é um projeto que eu boto fé, a idéia é exelente, só não gosto de como é feita o acesso as classes java dentro do jruby, não é uma coisa natural…
Mas usa toda a segurança, velocidade e etc da jvm, então já apostaria nele.

No momento também não colocaria minha carreira em risco usando o jruby em um projeto grande, ainda não foi bem testada, nem se quer existe um caso de sucesso.

mas tudo isso ai é minha opnião, não peguem isso como lei… pois não é…!

A meu velho, eu já perdi a fé nestas coisas, o pessoal discute sempre as mesmas bobeiras, parece que ninguem tem que fazer projetos reais,
cumprir prazos e rápido, e fazer $.

o pessoal gosta de falar de OO, boas praticas … DDD e bla bla bla… mas pq ninguem usa OO já na camada view ? com wicket e companhia isto é possível como vc ja percebeu, e o sistema baseado em eventos fica bem mais simples de programar na minha opinião, é claro que isto é preferencia pessoal.

O click é un wicketiznho se podemos falar assim, é igual mais com menos funcionalidades mas que atendem bem pelos menos os meus projetos. Sobre ser mais simples, olhe os exemplos do click e depois faça o mesmo com wicket, e vc vai ver que vc vai escrever mais código. Se um framework atende ou nao vc, somente vc pode dizer, e cada projeto um ou outro pode ser o mais ideal… eu depois que conheci o click, nunca mais usei nenhum outro, até da vontade de chorar quando vejo tudo mundo falando sempre das mesmas coisas, e novos frameworks helloworld surgindo, e esta jsf que nao morre, porra fiquei de cara, fui fazer a prova beta de scea 5 e cai um monte de jsf, até ai a sun fica querendo empurrar as coisas. Tem umas questões lá que vc acha uma coisa, mas tem que responder o que a sun acha, tipo jsf é a solução para tudo :wink: o mundo ta perdido. é por isso que RoR é tao falado, pq java ta uma zona, a sun fica pisando na bola e tudo anda devagar…muito devagar… entao o pessoal open source tem que sempre ensinar a sun como que se faz… mas até alguma coisa virar uma JSR que preste demora…

o que eu viciei é fazer telas utilizando reflexão, uma vez que estes frameworks a view é feita no java, vc pode construir um formulario, tabela, etc por refexao,… pode ter paginas inteiras que vc apenas faz un ‘extends’ altera umas 2 ou 3 coisas e pronto… tudo pq vc pode usar OO… é claro que se vc identificar uma semelhança nas telas que vc está fazendo no meu sistema, … nos meus é sempre igual… cadastro, cadastro, cadastro, tabela, tabela, tabela, relatorio, relatorio, relatorio, bla bla bla e o pessoal faz sempre a mesma coisas, escreve codigo + codigo + codigo e + + + e sempre faz a mesma coisa… eu prefiro fazer um extends MinhaPaginaModeloParaTelaDoTipoX e boa, acabou. é claro que nem sempre da de fazer magica, mas quando nao der vc vai la e faz manual mesmo, mas pelo menos ja ganhou tempo, o que vai lhe ajudar a cumprir o prazo mais facil e entao vc pode gastar tempo no que realmente é complicado. Até fiz uns esqueminhas com anotação para gerar o código mais customizado se precisar.

mas eu nao gosto de fazer muita propaganda de framework, já perdi a fé mesmo… to falando agora por que vc perguntou, até pq agora ja estou mais de 1 ano apenas com J2ME, o que faço de web são poucos sistemas e as administrações dos sites web que o celular acessa.

boa sorte, acho que no wicket vc ta no caminho certo.
Ricardo

Pode ser preconceito meu devido ao fato de que por todos os sites que eu passei havia uma equipe de desenvolvimento e uma equipe de design.

A equipe de design manja de HTML, CSS e essas coisas. OO na camada view é um contra-senso quando quem vai fazer as páginas HTML são os designers. O designer vai te entregar um HTML e vc vai preencher o HTML com as tags. Não vejo como trabalhar diferentemente disso. Em outras situações, primeiro surge o layout, e só depois o sistema. O layout funciona como um protótipo ou como uma especificação das funcionalidades desejadas. Quem é responsável por isso é o design, o dono do negócio, etc e tal. Onde OO vai entrar aqui?

A não ser que o seu sistema/site não tenha layout/design. Por exemplo um sistema de administração de estoque, etc e tal, só vai ter uns formulários e umas tabelas para administrar e visualizar o conteúdo do banco.

Sei lá, não estou falando que eu estou certo nem errado, só não vejo como mudar o paradigma. Geralmente para haver uma mudança de paradigma, tem que haver um benefício muito forte no paradima novo e uma falha muito grande no paradigma antigo. É isso que eu e milhões de pessoas que trabalham com action-based frameworks ainda não conseguimos ver. OO para as páginas webs pode ser legal quando vc é o desenvolvedor e o designer ao mesmo tempo. Talvez para sistemas e não sites isso faça sentido. Onde OO vai entrar aqui?

Será que é isso então: se vc vai fazer um sistema onde as telas são meros CRUDS exibidores de dados e entradas no banco, então alguns componentes podem quebrar o galho. Mais eu já vi e já fiz diversos sistemas web assim com action-based, sem nenhum problema. O que faço é simples: faço um HTML bem tosco, umas tabelas bem toscas, mostrando os dados. Mesma coisa para os formulários. Depois entra um DESIGNER (que estuda e ganha pra isso) e ajeita todo o html deixando a coisa bontinha. Todo mundo que programa para web tem que saber table, br, td, tr, ul, li, e essas coisas super-básicas, ou não?

E os componentes que eu preciso, tais como um selecionador de datas, um tab panel, um formatador de entrada, uma tabela paginada, etc. consigo FACILMENTE com algumas tags. Browser não é desktop, não é swing. Eu sei que muita gente gostaria que fosse, mas não é. As coisas são historicamente mais simples, intuitivas e cruas dentro de um browser.

Por que em aplicações web a Camada de Apresentação é composta por HTTP+XHTML, que não são orientadas a objetos. A maneira mais smles de lidar neste domínio é usar a lnguagem específica dele, que não é OO nem java nem Ruby mas HTML. Orientação a Objetos não é a melhor solução para todos os casos.

Eu não apostaria minha carreira em lingagem nenhuma (acho que foi o Ronaldo Ferraz que falou sobre isso dia desses) mas sua afirmação não parece como alguém que não trocaria seu ASP rodando no IIS por um projeto em Apache Struts quatro, cinco anos atrás? Ruby tem seus pontos fracos, Java em seus ontos fracos mas cuidado para não repudiar a inovação como um todo.

É complicado integrar duas linguagens quando nenhuma das duas e nem a VM foi feita pensando nisso. O JRuby é um esforço heróico.

saoj, cada sistema é diferente como eu falei para o amigo lá em acima… cada um cada um…

o fato é que para mim o framework baseado em eventos fica mais simples e ágil, não se trata de html apenas, essa é a parte fácil.
se precisar fazer o html no braço é só fazer… gerar ele automático é um plus, e nao é obrigatório… igual esta tela inicial do guj tem as noticias, forum, etc, isso é barbada, faz um forzinho tem umas tabelinhas e vc coloca uns $ para imprimir as coisas. é um caso que não justificaria um click por exemplo, mas como o velocity é integrado nele, continuaria sendo simples… Mas se este é sua realidade não tem porque sair de um framework action mesmo.
Mas caso vc atende um grande cliente (e faz varios projetos para o mesmo) é facil encontrar padroes entre as telas e todas as aplicações, ai fica simples… cada caso é diferente.

pcalcado, quando falei de OO, não estou me referindo ao modelo de negocios em si, mas em paginas que seguem um padrao. Digamos que você possua um formulario a ser preenchido para buscar alguma coisa, pode ser livros ou carros. Na página seguinte vc tem o resultado em uma tabela paginada, e se clicar em algum livro ou carro poderá ver a tela de detalhes. Isto para mim é um padrão. Entao eu faço MinhaPagina extends PadraoBuscaXYZ. Fica bem simples, escrever algumas linhas de código, informar qual a classe de modelo que está envolvida na busca, sobrescrever uns 2 ou 3 metodos e ter estas 3 telas prontas em 5 minutos, com tempo para o cafezinho. Ai vc se preocupa com o a busca em si, ou em como visualizar os detalhes. Se isto se aplica ao caso de cada um é outra história.

o fato é que eu acho toda esta discussão de frameworks uma bela perca de tempo, na prática cada um é produtivo do seu jeito, as pessoas pensam diferentes umas das outras. mas se alguns podem usar RoR maravilha, se outros preferem struts2 ou menta ok também. O fato comum a todos é que temos um negócio a resolver e o frameworkzinho que for é só o começo da brincadeira, e cada um brinca diferente.

Em empresas grandes vc tambem nao pode ficar inventando moda toda hora, existe um padrao na empresa, ou alguem que manda mais que vc, os projetos e prazos andam e vc precisa dar um jeitinho em tudo…

T+ people e feliz 2008

Você não precisa de OO para isso, apenas de um mecanismo de herança de temlates. Dado que herança de objetos é algo que é bom evitar eu duvido que usar um modelo OO neste caso seja uma coisa boa. Seguindo o velho bordão ‘favoreça composição’ páginas montadas de pedaços ao invés de páginas ‘de um tipo’ seriam mais adequadas, de qualquer forma.

[quote=pcalcado][quote=ricardolecheta]
pcalcado, quando falei de OO, não estou me referindo ao modelo de negocios em si, mas em paginas que seguem um padrao. Digamos que você possua um formulario a ser preenchido para buscar alguma coisa, pode ser livros ou carros. Na página seguinte vc tem o resultado em uma tabela paginada, e se clicar em algum livro ou carro poderá ver a tela de detalhes. Isto para mim é um padrão. Entao eu faço MinhaPagina extends PadraoBuscaXYZ. Fica bem simples, escrever algumas linhas de código, informar qual a classe de modelo que está envolvida na busca, sobrescrever uns 2 ou 3 metodos e ter estas 3 telas prontas em 5 minutos, com tempo para o cafezinho. Ai vc se preocupa com o a busca em si, ou em como visualizar os detalhes. Se isto se aplica ao caso de cada um é outra história.
[/quote]

Você não precisa de OO para isso, apenas de um mecanismo de herança de temlates. Dado que herança de objetos é algo que é bom evitar eu duvido que usar um modelo OO neste caso seja uma coisa boa. Seguindo o velho bordão ‘favoreça composição’ páginas montadas de pedaços ao invés de páginas ‘de um tipo’ seriam mais adequadas, de qualquer forma.[/quote]

é uma também 8)

Oi pessoal !! Eu ainda me considero um iniciante em desenvolvimento pra Web e a minha empresa so agora esta começando a focar os aplicativos para Web… eu vou ser o primeiro a mexer diretamente com isso então tive a liberdade de pesquisar e escolher os frameworks basicos.

Em primeiro lugar partimos do requisito que iriamos usar JEE, não vou detalhar aqui o porque. Então a maior dificuldade é exatamente que existem muuuuitos frameworks MVC e depois de pesquisar muito… cheguei a testar Struts(a documentação é péssima), desisti e passei a estudar JSF… e achei bem melhor porque é um padrão e pelo menos existe uma documentação decente.

Bom eu fiz o primeiro projeto, que é interno da empresa, em JSF. A documentação é boa, mais tem algumas coisas bobas… detalhes idiotas do JSF que eu não encontro na documentação e que me atrasaram bastante. Eu usei a implementação de referência da SUN a versão 1.2 e achei muito improdutivo… pela falta de tutoriais e exemplos. Acho que o JSF poderia ter uma comunidade muito maior e mais participativa se o projeto não fosse tão amarrado a SUN e as JSRs, sei que isso faz parte do processo de padronização masss na minha opinião o projeto esta muito fechado.

Conclusão, eu achei que o JSF ta muito imaturo em relação a outros framework´s (não padrões) com o Menta, ou o Vraptor, ou o Click, Wicket. Eu li sobre o Wicket e o Click, fiquei bem impressionado… mais ainda depois dos comentários do Ricardo. Pretendo testar os dois e usar nos meus próximos projetos… uma grande vantagem que ja percebi no Click e no Mentawai é a documentação ótima, são framework´s com a melhor documentação que ja vi… inclusive com exemplos e acho que isso é uma das coisas que impulsiona o uso, a divulgação e a evolução do projeto pela própria comunidade de usuários. Parabéns para os membros desses projetos, muito legal.

Pelo que ja li acho que a componentização da interface html é uma grande vantagem sim… não vejo o porque de se não utilizar, a vantagem é justamente o reuso. Concordo que HTML/XHTML não é OO mais qual o problema de se reutilizar componentes na view ?! Essa é a minha opinião e estou aberto a criticas… como disse sou iniciante mas ja tô caindo dentro. :smiley:

Valeuuu !!

Wicket e click são muito bons. Mas pessoalmente acho o click mais prático e fácil.

Se tiver um tempo, dá uma olhada no Stripes. É um framework “Action-based”, como o Struts, que implementa a idéia de Convensão sobre Configuração.

Estou utilizando ele nos meus freelances. Acredito que pode te ajudar.

[quote=acdesouza][quote=skyblue]
[…]Conclusão, eu achei que o JSF ta muito imaturo em relação a outros framework´s (não padrões) com o Menta, ou o Vraptor, ou o Click, Wicket.[…]
[/quote]

Se tiver um tempo, dá uma olhada no Stripes. É um framework “Action-based”, como o Struts, que implementa a idéia de Convensão sobre Configuração.

Estou utilizando ele nos meus freelances. Acredito que pode te ajudar.[/quote]

Nossa cara agora você me deixou meio perdido…heheheh
Fiquei mais confuso ainda, o Stripes tambem parece muito bom… não sei qual escolher.
Os requisitos pra projetos web que eu vou trabalhar aqui ainda são muito vagos, eu so gostaria de ja selecionar algum framework.
Acredito que não vamos desenvolver nenhuma aplicação que seja um monstro de complexidade e recursos por isso o requisito que estou utilizando para selecionar o framework MVC é simplicidade e/ou boa documentação e claro uma comunidade expressiva de usuários. :roll:

Valeu pela dica… vou dar uma olhada no Stripes

Dê uma olhada no mentawai e no vraptor tb.