Tuesday 7 November 2006

Un point sur Wicket-Dojo-Contrib

Voila près de 15 jours que j'ai mis les mains dans le code de Wicket-Dojo-Contrib et voila les fonctionnalités que j'ai ajoutées/réparées :
  • DojoAjaxUpdate - permet de rafraichir des widgets sur modification d'un widget
  • DojoAutoUpdate - Placé sur un component, il permet de l'auto rafraichir à une période donnée
  • Drag'n'Drop - Evenement coté serveur lors du deplacement d'éléments
  • Effet de fondu, explode, wipe
  • DojoDialog
  • DojoFloatingPane
  • DojoTooltip - l'exemple ne fonctionne pas encore

Tout ces widgets ne seront disponibles que pour la prochaine version 2.0 de Wicket.

Des exemples de ces widgets sont disponibles ici

je pense que les prochaines integrations seront autour des TabContainer et des Tree
D'autres idées ?..

Sunday 22 October 2006

Integration de widget Dojo dansWicket

L'intégration de Dojo dans wicket est actuellement un peu pauvre, en effet aucun widget n'est encore integré. Pour l'instant seul les effets visuels et quelques mécanismes de base sont intégrés.

Je me suis donc motivé pour intégrer des nouveaux widgets et mécanismes. Pour l'instant je n'ai intégré que le Drag'n'Drop et le widget Dialog, cependant ceci ne fonctionne qu'avec la future version 2.0 de wicket et je n'ai pas encore fait le patch pour le bug reporter de Wicket-contrib-dojo sur SourceForge.
Ceci parceque j'ai changé la façon dont Wicket-contrib-dojo utilise Dojo et le patch fait plus de 4Mo donc je ne peut pas le soumettre sur le bug reporter. J'ai mis au courant les responsables du projet et j'attends une réponse pour savoir que faire de ce "gros patch" : http://www.jroller.com/page/ruudmarco?entry=woohoo_the_first_real_release#comments

Un petit message pour Vince : voilà le drag'n'drop existe maintenant dans Wicket ;)

Thursday 19 October 2006

Un second patch pour Wicket-dojo-contrib

Décidemment wicket-dojo-contrib n'a pas monté en version en suivant Wicket, en effet après avoir écrit un patch pour faire compiler les samples : http://svn.sourceforge.net/viewvc/wicket-stuff?view=rev&revision=1014
Il m'a fallu faire marcher les effets dojo avec celui-ci https://sourceforge.net/tracker/index.php?func=detail&aid=1580673&group_id=134391&atid=730668
Allé il reste encore des petit truc à corriger et wicket-dojo-contrib refonctionnera bien, il sera alors temps d'intégrer des nouveaux composants
Merci à Jbq pour son aide et ses commits

Monday 16 October 2006

Wicket et Dojo-contrib

Après avoir fait un check-out de wicket sur l'incubateur d'apache (https://svn.apache.org/repos/asf/incubator/wicket) ainsi que la contribution Dojo et ses exemple (https://svn.sourceforge.net/svnroot/wicket-stuff/trunk/wicket-contrib-dojo et https://svn.sourceforge.net/svnroot/wicket-stuff/trunk/wicket-contrib-dojo-examples) et après avoir passer une grosse heure à installer Maven et tout et tout, je me mets à compiler mon wicket(pas de pb) puis wicket-contrib-dojo et la à ma grande surprise, wicket-contrib-dojo n'est pas compatible avec wicket.

En effet l'API de construction des widgets de wicket a changé sur la head. Avant un widget se déclaré de cette façon :
Widget w = new Widget("id");
parent.add(w);
Alors que maintenant on l'instancie à la swt :
Widget w = new Widget(parent, "id")
Conclusion : impossible de compiler la head de Wicket avec la Head de wicket-contrib. Moi qui voulais jeter un petit coup d'oeuil à l'intégration de Dojo dans Wicket, me voila désespéré ;) . Je vais donc attendre un peu ou prendre mes petits doigts pour essayer de faire fonctionner tout ça. Quelle déception!

Sunday 15 October 2006

L'authentification avec Wicket

Une chose primordiale au niveau du développement d'application web est l'authentification. Nous allons voir ici comme mettre en place ce mécanisme au niveau d'une application wicket:

Tout d'abord il faut utiliser le module wicket-auth.


La première étape est d'écrire la classe de l'application qui au lieu d'étendre la classe WebApplication il s'agit d'étendre la classe : AuthenticatedWebApplication
[UPDATE] Mise à jour de l'exemple suite au commentaire de Philoops
public class MonAppWeb extends AuthenticatedWebApplication
{
        public static class MaSession extends AuthenticatedWebSession
        {
                public MaSession(AuthenticatedWebApplication application)
                {
                        super(application);
                }
 
                public boolean authenticate(String username, String password)
                {
                        //tout type d'authentification peut être fait
                        return username.equals("vincent") && password.equals("mdp");
                }
 
                public Roles getRoles()
                {
                        if (isSignedIn())
                        {
                                return new Roles("RoleUtilisateur");
                        }
                        return null;
                }
        }
 
        protected Class< ? extends AuthenticatedWebSession> getWebSessionClass()
        {
                return MaSession.class;
        }
 
        protected Class< ? extends SignInPage> getSignInPageClass()
        {
                return AuthPage.class;
        }
 
        public Class getHomePage()
        {
                return Accueil.class;
        }
}
l'application est maintenant en place il reste à definir la page pour l'authentification :
public final class AuthPage extends wicket.authentication.SignInPage
{
}
<html>
<head>
    <title>Autentification</title>
    <link rel="stylesheet" type="text/css" href="style.css"/>
</head>
<body>
        <h2>Identifiication</h2>
    <i>login et mot de passe</i>
    <p>
    <span wicket:id="signInPanel"/>
</body>
</html>
On definit maintenant une page pour se deconnecter :
 
public class SignOutPage extends wicket.authentication.SignOutPage
{
}
 
<html>
<head>
    <title>Deconnection</title>
    <link rel="stylesheet" type="text/css" href="style.css"/>
</head>
<body>
        <h2>Aurevoir!</h2>
        <p>
        <wicket:link>
                <a href="Accueil.html">Accueil</a>
        </wicket:link>
</body>
</html>
On peut maintenant definir 2 pages : une qui necessite une identification et l'autre accessible à tout le monde. Notons que l'authentification se fait maintenant par annotation java
 
public class Accueil extends WebPage
{
}
<html>
<head>
    <title>Accueil</title>
    <link rel="stylesheet" type="text/css" href="style.css"/>
</head>
<body>
    <h2>Bienvenue</h2>
 
    Page accessible à tout le monde.
    <p>
        <wicket:link><a href="AdminPage.html">Page administrateur</a></wicket:link><br/>
        <wicket:link><a href="SignOutPage.html">Deconnection</a></wicket:link>
 
</body>
</html>
@AuthorizeInstantiation("RoleUtilisateur") // page necessitant une authentification
public class AdminPage extends WebPage
{
}
<html>
<head>
    <title>Page administrateur</title>
    <link rel="stylesheet" type="text/css" href="style.css"/>
</head>
<body>
    <h2>Administrateur</h2>
    <p>
        <wicket:link><a href="Accueil.html">Accueil</a></wicket:link><br/>
        <wicket:link><a href="SignOutPage.html">Deconnection</a></wicket:link>
 
</body>
</html>
Et voila, ce code est suffisant à lui même pour fonctionner.

Wicket un framework de dévloppement d'applications web 100% java

J'ai décidé d'ouvrir une nouvelle catégorie sur mon blog pour parler de ce nouveau framework de développement d'application web. Un nouveau framework! encore un! Oui en effet il existe déjà un très grand nombre de framework pour écrire des applications web comme Structs, RubyOnRails, Cocoon, etc... Etant un très gros utilisateur de Cocoon je me suis intéressé à un autre framework : Wicket.

La première question est de se demander quel est l'interret d'utiliser un autre framework. Evidemment tous ces frameworks ne sont pas équivalents. Ceux qui connaissent Cocoon savent qu'il permet de faire n'importe quel type d'application avec quand même de très nombreux atouts en ce qui concerne la publication de contenu. Wicket lui doit plutôt être comparé au block Form de Cocoon. En effet son orientation est clairement l'écriture de formulaires web. Une autre grosse différence avec Cocoon est le type de langage utilisé : Cocoon permet de développer sans forcement avoir de grosses connaissances Java puisqu'il est basé sur XML/XSL alors que Wicket est beaucoup plus orienté Java avec une API très proche de SWT.

Un nouvel avantage qui va donner de la crédibilité à Wicket aux yeux des décideurs. Le projet est actuellement en "incubation" dans la fondation apache... Wicket va donc d'ici peu devenir un projet Apache...