Création d’une application de type CRUD avec Wicket

Extrait du synopsis :

Cet article va présenter le framework Apache Wicket et ce en s’appuyant sur la création d’une application de suivi de bugs (Bug tracker) qu’on nommera “Min.Bug.Tra”. Une telle application est un cas particulier de ce qu’on appèle CRUD (Create, Read, Update et Delete) mais qui a l’avantage de traiter une problématique réelle.

L’article complet est par ici : Création d’une application de type CRUD avec Wicket

On templating, and a shameless plug of Moulder

Moulder is a server-side templating system. It uses jQuery’s approach, i.e. select and transform, and works only on XML-like data. I’ve written it two times over: One time in Java and another in Scala. Both versions are available as Open source software on GitHub and released under the MIT License.

1. What is templating

Templating is generally used in (but not limited to) web applications to generate dynamic web pages. Every time you perform a search on Google or open your Facebook page, templating was used behind the scene to generate these pages.

Exploration des modèles de Wicket

Extrait du synopsis :

Cet article a pour objectif de vous présenter la notion de modèles du framework Apache Wicket et ce à travers un exemple pratique et réel. en utilisant une approche incrémentale : partir d’une solution triviale et simple, et l’améliorer progessivement en utilisant différents techniques et types de modèles

L’article complet est par ici : Exploration des modèles de Wicket

Wicket enclosures and ajax : no no

Okay, this will be my second post in English, so, don’t go too hard on me 🙂

Earlier today, I was working on a web application using Wicket as framework, and I’ve got bitten by something that I wanted to share.

More precisely, it’s about enclosures and ajax : I had a link inside a list item and I wanted to bind the visibility of the latter to of the former.

So, I went ahead and enclosed the list item in an enclosure specifying the link wicket id as a value for the child attribute :

<wicket:enclosure child="generateReport">
	<li>
		<a href="#" wicket:id="generateReport">Generate report</a>
	</li>
</wicket:enclosure>

And this worked just fine, until I’ve decided I wanted to change the link’s visibility using Ajax.

So, when generating a full web page response, Wicket is perfectly able to handle the enclosures. But when ajax is involved, Wicket simply can’t handle them because they have no corresponding element in the html page, and thus they can’t be updated later. The inner element’s (<a> in this case) visibility will be affected but that’s not the case for the enclosure whose visibility remains static (depending on whether it was visible or not when the page was generated).

Note: The Wicket’s wiki mentions this behavior :

Note: Changing the visibility of a child component in Ajax callback method will not affect the entire enclosure but just the child component itself. This is because only the child component is added to the AjaxRequestTarget.

Sortie d’Apache Wicket 1.4

Après une longue gestation, la version finale d’Apache Wicket 1.4 est enfin disponible.

Les principales nouveautés de cette version sont :

• L’utilisation des generiques (apparues avec Java 5) à travers les modèles et composants. A mort tous ces casts.
• Modification de quelques autres APIs par ci et par là pour tirer profit des nouveautés de Java 5, genre WebMarkupContainer.add(Component … components)
• Merge des jars de l’intégration Wicket/Spring dans un seul jar
• Les jars de Wicket présentent d’office les méta données SOGi. J’avais tiré profit de celà dès les premières releases candidates pour utiliser wicket comme couche web dans un conteneur OSGi

➡ L’annonce officielle de la sortie
➡ Rapport JIRA : 149 bugs fixes et new features
➡ Migration guide
➡ Et bien sûr, le lien de téléchargement

wicket:container et l’ajax

Je viens de perdre une demi heure à me casser les dents sur un truc très stupide. Je voulais donc en parler rapidement ici, peut être que ça vous épargnerait de perdre du temps dessus un de ces jours.

La version courte

Ne jamais utiliser <wicket:container> avec l’ajax !!!!

La version longue

[Suite:]

J’ai mis dans le html :

<wicket:container wicket:id=details"></wicket:container>

Côté Java, j’y avais associé un EmptyPanel (initialement) :

add(new EmptyPanel("details").setOutputMarkupId(true));

Et je voualis mettre à jour son contenu via ajax suite à un clic sur un autre élément de la page :

PersonDetailsPanel personDetailsPanel = new PersonDetailsPanel( 
    "details", new Model<Person>(p)); 
personDetailsPanel.setOutputMarkupId(true); 
addOrReplace(personDetailsPanel); 
if (target != null) { 
  target.addComponent(new PersonDetailsPanel( 
      "details", new Model<Person>(p)).setOutputMarkupId(true)); 
  
}

A l’exécution, j’obtiens un comportement bizarre : Au premier clic, ça met à jour la page html, mais les clics suivants bien que traités côté serveur ne mettent pas à jour le panel.
D’autres fois, même le premier clic ne fonctionnait pas.

Pour finir, je tiens à adresser mes remerciements les plus sincères à la console «Ajax Debug» de Wicket qui m’a permis de résoudre ce problème !

Billet original publié sur les blogs de developpez.com…

—-

Astuce Wicket : Utiliser les enclosures pour contrôler la visibilité d’un bloc

Bien que l’un des principes de base de Wicket est de séparer le HTML (présentation) de Java (le contrôle), il offre tout de même quelques goodies utilisables dans le HTML et qui permettent de simplifier les choses (sans toutefois aller jusqu’à un jeu de tags à la JSTL par exemple).

Dans ce billet, je parlais de l’un de ces goodies, qui est le <wicket:container>. Ici, je vais parler de <wicket:enclosure>.

Ce tag s’avère très utile dans la situation suivante : on a un ensemble de tags HTMLs dont l’un au moins est attaché à un composant Wicket, et la visibilité d’un de ces tags (qui doit être attaché à un composant Wicket) contrôle la visibilité de l’ensemble des tags.

[Suite:]

Par exemple :

<div class="extra_info"> 
  <span>Deuxième Nom :</span> 
  <span wicket:id="secondName">valeur</span> 
</div>

et du côté Java :

 
add(new Label("secondName", person.getSecondName());

Si par exemple une des personnes ne dispose pas de second nom (sa valeur est nulle), on pourrait décider d’afficher le

tout en liassant la valeur du second nom vide, mais on pourrait aussi décider de cacher complètement tout le bloc

.

Dans le second cas, il nous faut pouvoir contrôler la visibilité de tout le div depuis Wicket.
Or, pour ce faire, on devrait normalement attacher de div à un composant Wicket, puis cacher ce composant, ce qui est loin d’être idéal.
Pire encore, si l’ensemble de tags annexes ne sont pas groupés comme ici dans un seul tag, comme par exemple :

<h2>Infos optionnelles</h2> 
<span>Deuxième Nom :</span> 
<span wicket:id="secondName">valeur</span>

Cacher le tout serait encore plus fastidieux à réaliser : il nous faut soit attacher chacun des tags à un composant Wicket (et cacher chacun d’eux), ou encore les entourer d’un tag fantôme (<wicket:container>, décrit ici), attacher ce denier à un composant Wicket, puis le cacher …

C’est loin d’être optimal car ça pollue inutilement le code (Java et HTML).

C’est là que le tag <wicket:enclosure> entre en jeu : il permet de contrôler la visibilité de tout ses fils (tags) selon la visibilité de l’un d’entre eux.
Dans notre cas, le tag qui contrôle la visibilité du tout est le second span :

<span wicket:id="secondName">valeur</span>

Il suffit dès lors d’entourer le tout par un <wicket:enclosure> et de préciser l’identifiant du composant Wicket qui contrôle la visibilité via l’attribut child :

<wicket:enclosure child="secondName"> 
  <h2>Infos optionnelles</h2> 
  <span>Deuxième Nom :</span> 
  <span wicket:id="secondName">valeur</span> 
</wicket:enclosure>

Dès lors, si du côté Java on cache le composant “secondName”, c’est tout le bloc qui se trouve caché :

Label secondNameLabel = new Label("secondName", person.getSecondName());  
if(person.getSecondName()==null){ 
  secondNameLabel.setVisible(false); 
} 
add(secondNameLabel);

Billet original publié sur les blogs de developpez.com…

—-

Article à propos de Wicket dans developerWorks

Et un autre article sur Wicket, un ! (sur developersWork) :

https://www.ibm.com/developerworks/library/wa-aj-wicket/

Billet original publié sur les blogs de developpez.com…

—-

Développez un Editeur de Liste avec Wicket, par Igor Vaynberg

Igor Vaynberg, l’un des actifs développeurs de Wicket a encore publié un article dans le site WicketInAction.
Il s’agit de développer un composant “Editeur de Liste” pouvant être utilisé dans un formualaire.

http://wicketinaction.com/2008/10/building-a-listeditor-form-component/trackback/

Si Wicket vous intéresse, on commence à avoir de plus en plus de cours à propos de Wicket sur java.developpez.com :

Mise en oeuvre d’Apache Wicket
Exploration des modèles de Wicket

Pour ne citer que les plus récents

Billet original publié sur les blogs de developpez.com…

—-

JQuery4Wicket

JQuery c’est super ! Idem (voire plus) pour Wicket ! Donc, vous vous doutez bien qu’un truc qui s’appelle JQuery4Wicket doit bien être super !

En gros, c’est une petite lib à ajouter dans une application Wicket qui permet d’intégrer JQuery, ou de façon plus barbare fournir à JQuery un frontend Java utilisable depuis les pages/composants Wicket … Pas encore testé, mais ça m’a l’air au moins très prometteur.

C’est par ici que ça se passe http://www.noocodecommit.com/blog/nicogiard/wicket/presentation-de-jquery4wicket

J’y reviendrais plus tard si j’arrive à avoir le temps de tester ça.

Une première introduction à JQuery4Wicket vient d’être publiée ici

Billet original publié sur les blogs de developpez.com…

—-