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

JavaEvangelist Membro desde: 11/05/2006 12:10:38 Mensagens: 329 Offline

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:

Apache wrote:
* last JDK-1.4 release (next release will be Java 5 based)
* first Apache release: renamed packages to <code>org.apache.wicket</code>
* simplified models API
* simplified converter API
* simplified validator API
* now works with zero-config behind a proxy server using relative URLs
* added Google Guice support
* use your Wicket pages directly in a portal without changing a line of code (JSR-168/JSR-286 support)
* switched logging API from commons-logging to slf4j
* use velocity templates as panels in your pages with wicket-velocity
* YUI-calendar and Joda time based date picker (wicket-datetime)
* improved Ajax support
* improved, more robust header contributions
* filters duplicate javascript references
* supports onload/ondomready events
* javascript resources are gzipped by default
* stateless pages and components for those parts of your application that needs to scale to extremely large numbers of users
* improved AjaxTree/AjaxTreeTable
* hybrid URL encoding makes search engines and your users happy
* nested form components?create panels that contain forms and use them anywhere without worrying about the nesting of form tags
* minimized session use by storing component hierarchy in file system (DiskPageStore)

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

Alguem já fez algo profissional? Relate como foi.

JavaEvangelist Membro desde: 11/05/2006 12:10:38 Mensagens: 329 Offline

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

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...

This message was edited 2 times. Last update was at 04/01/2008 12:21:29

o click é bem mais simples que o wicket

JavaEvangelist Membro desde: 11/05/2006 12:10:38 Mensagens: 329 Offline

toninho wrote:
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...

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...

ricardolecheta wrote:
o click é bem mais simples que 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

mcbarsotti wrote:
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...

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?

JavaEvangelist Membro desde: 11/05/2006 12:10:38 Mensagens: 329 Offline

toninho wrote:
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.

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

)

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

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 é...!

mcbarsotti wrote:

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.

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

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

This message was edited 7 times. Last update was at 05/01/2008 11:56:46

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.

ricardolecheta wrote:
o pessoal gosta de falar de OO, boas praticas ... DDD e bla bla bla.. mas pq ninguem usa OO já na camada view ?

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.

mcbarsotti wrote:
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 )

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.

mcbarsotti wrote:
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.

É 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

ricardolecheta wrote:
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.

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.

pcalcado wrote:

ricardolecheta wrote:
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.

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.

é uma também

Notícias, artigos e o maior fórum brasileiro sobre Java