Tutorial: Começando com Apache Wicket (Parte I)

Já que não tem Apache Wicket no JavaOne Brasil, vai um tutorial de Apache Wicket, entitulado "Começando com Apache Wicket (Parte I)" publicado no Lado Servidor, com o apoio do Paulo Jerônimo e da wdev, que contribuíram para minha participação no The Developers Conference 2010, em Florianópolis. O bacana desse tutorial é que produzi um video também, para acompanhar (sem cortes) o desenvolvimento da aplicação de exemplo.

Curioso em saber como ficou o resultado? Então vai logo ver.

Tutorial: Começando com Apache Wicket (Parte I)

E se você perdeu a Trilha Web do TDC 2010 e não viu minha palestra, confira ao menos os slides.

Apache Wicket derruba o padrão JSF

[]'s
Bruno

Errar, corrigir, committar - Sobre o JavaOne Brasil

Um programador quando encontra um erro, automaticamente, como que por instinto, sente vontade de corrigí-lo e mandar para o repositório, para ter segundos após, a sensação de um trabalho bem feito. Um orgulho de sí próprio. Às vezes, queremos fazer a mesma coisa na vida real. Com os erros do dia-a-dia, com os erros que envolvem pessoas.

Aproximadamente 3 semanas atrás, me empolguei com uma mensagem da Yara Senger, e submeti para o comitê do JavaOne Brasil, 3 palestras relacionadas à Apache Software Foundation. Soube ao mesmo tempo do The Developers Conference 2010, em Florianópolis, onde meu amigo Rodrigo Cândido, participara da organização. Não hesitei e sugeri à Wdev, cuja empresa agora faço parte, que levasse ainda mais conteúdo para este grande evento. Levamos palestras interessantes. Uma sobre Desenvolvimento para iPad, do Felipe Cypriano, e outra sobre Integração Contínua, do Marcelo Behera. Além das minhas duas palestras sobre projetos Apache (Wicket e Camel); as mesmas que havia submetido para o JavaOne Brasil.

No dia 3 de Novembro, recebi um e-mail do Sharat Chander agradecendo minhas submissões, mas que infelizmente o conteúdo não foi aprovado para o JOBra. Sem razões, sem explicações. E também disse que não é comum enviarem notificações desse tipo. Geralmente o pessoal fica no vácuo.

Ao mesmo tempo, no meio de todos estes eventos, a Oracle com seu processo contra o Google, blogs começam a dizer que a Apache copiou código para dentro do projeto Harmony. Ela esclareceu, mas não encerrou o assunto. De fato, iniciou uma guerra contra a Oracle, em defesa do Software Livre.

Por fim, no dia 8 de Novembro saiu a programação do JavaOne Brasil. Anunciada pela Fabiane Nardon. E obviamente fui conferir a grade, atrás de palestras interessantes e palestrantes a serem prestigiados. Entretanto ao ler o conteúdo, me decepcionei. Por 3 fatores:

• (tweet, tweet, tweet) Falta de conteúdo relacionado à Apache Software Foundation
• Conteúdos repetidos (alguns assuntos, com mais de 2 palestras)
• (tweet, tweet) Metade dos analistas de conteúdo vão palestrar

O que mais me chateou mesmo, foi o primeiro item, e em seguinda o segundo. Com assuntos sendo apresentados mais de uma vez, não seria o caso de pensar melhor na escolha das palestras, e evitar repetição, abrindo espaço para expôr outros projetos? Considerando a Apache com principal fornecedora de projetos Open Source para a plataforma Java?

Claro que fiquei chateado por não ter sido aprovado a participar do JavaOne. Mas frente ao o que está acontecendo, constatei que, não apenas minhas palestras, mas toda e qualquer outra associada à Apache que tenha sido submetida, foi rejeitada, ao que parece, propositalmente. E isso é o que me deixou realmente chateado. E por favor alguém me corrija se eu estiver errado. Seria muito bom saber os reais motivos.

Não reconhecer a Apache, e não incentivar a comunidade brasileira a participar da ASF é ir contra o Software Livre. A falta de palestrantes e palestras entusiasmados com projetos da Apache no evento, ao que parece, é reflexo dos desejos da Oracle.

Pedido de desculpas aos palestrantes

Com toda a minha chateação, e sem refletir bem a respeito, acusei amigos injustamente. É fato que metade dos analistas de conteúdo vão palestrar. Mas como muitos outros eventos, isso é normal. Eu mesmo, por causa da minha amizade com algumas pessoas, obtive espaço no TDC2010. Não bastasse uma palestra, levei duas. E ainda abri espaço para dois outros profissionais.

Acusei amigos injustamente por algo que eu mesmo havia feito alguns dias antes.

Alguns dos analistas são amigos, outros são conhecidos. E muitos outros que irão palestrar, também são meus amigos, de empresas que trabalhei anteriormente. 

Que fique claro: todos os palestrantes selecionados merecem estar lá. Tenho certeza que a escolha foi difícil, e com critérios como +assunto, +técnica, +histórico e +mérito, os melhores palestrantes foram selecionados. Jamais disse algo contrário. 

Por fim, peço desculpas ao Bruno, com quem aprendi muito. À Yara que me incentivou muito para submeter conteúdo ao JavaOne e me deu total apoio no TDC2010. Ao Vinicius (que ironicamente retweetou meu desabafo), Paulo, Guilherme, Bruno Ghisi, Fabiane e Fabio Velloso.

Vocês são excelentes palestrantes e há muito tempo contribuem com a comunidade. Com certeza, estão no evento por mérito.

Um excelente JavaOne Brasil a todos.

Um alô para o Liaw Mike e principalmente ao Michael Nascimento, que me ajudou a enxergar o bug. :-)

ApacheCon Brazil and why we need it?

I'm not sure if this mailing list is the right one to write about this, but I'm gonna take the risk. I suppose "Community" means anything related to it. And this is definitely about community.

Before anything, I'd like to share my history with ASF. (skip if you want... :D)

When I started to get involved with the Apache Software Foundation in a deeper level, I was still just a user, downloading Tomcat and using it. I guess most Java developers for the Web environment still do that.

5 years a go, I joined the Apache Wicket community and then my relationship with ASF has born. And for the last 5 years I've been speaking about it in Brazil, either in JUG meetings or at conferences around the country and sharing everything I wanted to share on my blog. I've even created a Google Groups for that, called Wicket pt_BR. With my contributions as an "evangelist" I gave birth to friendships with great people like Martijn Dashorst, Jeremy Thomerson, Eelco Hillenius and others from the Wicket community.

Then, in 2008 I heard about the Apache TAC and, thanks to ASF, I could meet them in person during ApacheCon @ New Orleans. It was better than anything I've ever experienced. Considering how close I was to great people, professionals and friends, and how easy I could start chatting about anything to them, I thought that was the best conference it could ever exist. I thought: "ApacheCon is the best. I got free beer!". That was cool. Every conference I go here in Brazil, I wish someone put some beers instead of Coke. Until now... only #fail

Then, right after I came back from New Orleans, I started to play with the SOA stack (Camel, CXF, ServiceMix and ActiveMQ). I also became friend of great people like Bruce Snyder, Claus Ibsen, Hadrian Zbarcea and Debbie Moynihan.

Last year, 2009, when I heard about ApacheCon in San Francisco, I took the chance to apply again to the Apache TAC (no, I wasn't bargaining; it really is expensive to fly from Brazil to the USA, specially SF). I just applied for the tickets, and for accommodation I was safe with CouchSurfing friends I already knew. Also, I really wanted to help the organization. It was when I met Nick Burch, Ross Gardler and Noirin Shirley. Could not forget my latin friends Amelia Blevins and Carlos Sanchez. Other names like Jesse McConnell, David Blevins and Yeliz Eseryel are also in my good memories of ApacheCon 2009. Unfortunately this year, because of personal reasons (not because of TAC rules), I couldn't be present at ApacheCon.

With the help of Bruno Souza, I discussed with some people, including Sally Khudairi, the idea of bringing ApacheCon to South America.

What I saw on ApacheCon '08 and '09 was something amazing. Perfect for South America. Perfect for Brazil. The Apache Way is something that must be shared with everyone. 

A few months a go, I went to Brasilia (country's capital) to talk about the ASF in general, not on an specific project. It's amazing how people are unaware of what the ASF really is. And how people limit their knowledge to only what the big players show to them. Still, they all know Struts and Tomcat. It seems that South America is a big user of Apache projects rather than truly contributors.

Now this year, with JavaOne going to happen in Brazil, and the sessions that were scheduled, I believe it is now the time to drive ApacheCon south. There's no single talk about anything related to the Apache Software Foundation in this South American version of JavaOne. And I feel really sad about that. Sad that people that are behind the organization had the opportunity to accept papers (I myself proposed Wicket and Camel - papers I have been presenting since 2008 for rooms of 30~40 attenders).

And I'm sure everyone will use Maven, Ant or Tomcat to demonstrate something.

I don't know if this happened because of recent issues between Oracle and Apache, or just because of Java standards (like JSF, JavaFX, EJB) are more important than non-standard projects. It doesn't matter. I'm sure there was room. On my count, there are at least 3 subjects with more than 1 submission approved. Look at JavaOne track.

Now, if the ASF, the most voted JCP EC member (with 95% votes), has no space on JavaOne Brazil, the country who have been participating in the Open Source movement, giving birth to the OpenJDK thanks to Javali project, and Bruno Souza, than we should start considering other alternatives. Alternatives to standards, like Wicket or Camel.

We already have ApacheCon Europe and North America. I'm sure we can do ApacheCon South America.

Let's do this happen. Let's do it the Apache way.

Bruno Borges

Apache Wicket ainda mais divertido: Parte 1

Este é o primeiro de uma série de artigos para mostrar o Wicket à comunidade brasileira. Cada artigo que eu ler sobre JSF, Facelets e afins que achar interessante e me questionar: "seria ainda mais divertido fazer isso com Wicket", vou fazer um "fork" do artigo e codificá-lo com o Apache Wicket.

Para começar, vou forkar o artigo do Eder Magalhães sobre como tornar um trecho de código Facelets em um componente reutilizável, chamado "Facelets ainda mais divertido! Parte II".

[início do fork]
Neste post vou comentar sobre a criação de componentes usando somente HTML simples e Java puro - na minha opinião o grande diferencial do Wicket. O cenário é um formulário de manutenção de registros de funcionários, e o protótipo é simples:

É comum um protótipo ser entregue por Web Designers, e o nosso trabalho está em adaptar aquele protótipo para processar informações dinâmicas. A página acima se chama CadastroFuncionarios.html e a seguir, o código que o Web Designer entregou:

CadastroFuncionarios.html

Mas é comum ter trechos de telas que são repetitivos. Como os botões de ações deste formulário. Então é interessante tornar isso um componente para ser reutilizado e quando exigir modificação, que seja apenas uma vez, em um único lugar.

No Wicket, páginas são componentes, e funcionam em pares (Java e HTML). Como queremos construir um componente com os botões, precisamos de um painel, para ser reutilizado em outras páginas. O primeiro passo é criar a classe e um HTML exclusivo para o painel, contendo somente os componentes de botão.

Para criar um novo painel para agrupar componentes, existe a classe Panel. Vamos criar uma subclasse dela e especializá-la:

BarraBotoes.java

Por se tratar de um painel de botões, deixei implementado 3 métodos associados 1 para cada botão. Quem utilizar este componente, poderá facilmente sobrescrever estes métodos para adicionar funcionalidades por ação. Outra vantagem aqui está na documentação gerada automaticamente, se o programador preencher o Javadoc.

Para finalizar o componente (segunda etapa), é preciso o HTML do painel, chamado de BarraBotoes.html

BarraBotoes.java

A tag wicket:panel é uma das poucas tags especiais (carregadas pelo DTD). Aqui ela serve para delimitar o que representa o painel, sem prejudicar as ferramentas WYSIWYG. Deixei propositalmente o restante do código HTML por fora da tag para representar um protótipo, que pode ser visto pelo designer e ajustado por ele próprio, caso queira mudar folhas de estilo. A vantagem é que ele pode avaliar se estas mudanças atenderão os requisitos de design. Ou seja, o protótipo continua funcional. Também foi feito o binding entre os componentes no HTML e os componentes em Java através do atributo wicket:id.

A partir desse momento, o painel pode ser reutilizado. Nenhuma outra configuração é necessária. Exceto um import da classe em outras páginas. :-)

Agora precisamos ajustar a página que conterá o painel. Abaixo, o novo HTML da página CadastroFornecedores.html já com os ajustes para binding com Wicket:

CadastroFuncionarios.html

E o código Java para a página:

CadastroFuncionarios.java

Para implementar uma ação, o programador precisa somente sobrescrever os métodos que lhe for necessário. Agora que a página está pronta, e utilizando o componente, o próximo passo é melhorar a inteligência do componente, com zero de alterações nos HTMLs, poucos ajustes na classe do painel BarraBotoes, e uma linha de alteração na classe da página.

• Apresentar o botão excluir de forma condicional, com base em um boolean
• Botão cancelar deve sempre abortar o formulário onde estiver contido

Caso seja de interesse do programador acrescentar mais lógica no componente, para que por exemplo os botões tenham visibilidade condicional, ajustes na classe BarraBotoes devem ser feitos. E somente nela. No HTML nada precisa ser alterado. Abaixo, o código da classe com lógica de visibilidade condicional de botões:

BarraBotoes.java

A primeira acao foi adicionar um construtor que recebesse um Model (assunto para outro post), do tipo Boolean, e associar este Model como condicional para o método isVisible() do botão excluir.

A segunda ação foi ajeitar o construtor padrão para continuar funcionando como anteriormente, e mantendo assim compatibilidade com páginas que sempre mostram o botão excluir. Novas páginas poderão utilizar o novo construtor e condicionar a exibição do botão, se quiserem.

A terceira ação foi cancelar o processamento dos dados do form quando o botão cancelar for clicado. Para isto, a propriedade defaultFormProcessing deve ser desabilitada.
[fim do fork]

A grande vantagem do Wicket está em jogar para o lado Java toda a programação da interface, deixando o protótipo limpo, estático, e mesmo assim permitindo o programador manipular com uso inteligente da orientação a objetos, os componentes de tela.

O que mais você gostaria de saber sobre o Wicket?

Abraço,
Bruno

PS: mock de tela feito no Mockflow