Apache Pivot est un framework de développement d’applications Internet riches (RIA). Du buzz autour de ce framework est en train de se produire sur la toile. Bien qu’entamé en 2007, Apache Pivot est mentionné de plus en plus ces derniers jours grâce à sa promotion au rang de “Top Level Project” par la fondation Apache en Décembre 2009.

En théorie, cela veut dire que les développeurs du framework, qui a rejoint Apache Incubator en Janvier 2009, respecte les principes et les process de la fondation, se basant sur la méritocratie. En pratique, cela signifie que le projet devient plus visible, et une certaine communauté de développeurs se formera autour du projet. On verra certainement plus de billets de blog, des exemples, de la documentation et des critiques autour du framework. La quantité et la qualité dépendra certainement du succès de celui-ci.

Tout développeur Java peut se demander comment se positionne Apache Pivot par rapport à JavaFX. Sur la page FAQ du projet, les développeurs présentent Pivot et JavaFX comme répondant à des besoins “légèrement” différents avant d’admettre que les deux technologies ne sont pas pour autant exclusives et que -je cite- “Pivot represents what we think Sun should have done instead of JavaFX.” (traduction: Pivot représente, à notre avis, ce qui aurait du être fait par Sun au lieu de JavaFX.)

A mon avis, Pivot se positionne comme une alternative sérieuse à JavaFX pour tout développeur Java travaillant sur un projet RIA. Les raisons sont assez claires:

• Le code est en Java (et non un langage de script à apprendre);
• Le développeur a l’option de programmer son interface graphique déclarativement (en XML);
• L’intégration avec les composants serveur est plus souple.

Dans la page de la proposition de projet à Apache Incubator, quelques comparaisons existent (formulées par les développeurs de Pivot) avec Swing, GWT et JavaFX.

Mon intention n’est pas de dire que Pivot est le framework de développement RIA par excellence, loin de là. A mon sens, ce n’est qu’un projet qui débute, mais qui reste prometteur.

Je vous invite à aller découvrir les démos et les tutoriaux, qui peuvent, je pense, être complétés par un exemple intégrant un traitement coté serveur avec Pivot. Un exemple que nous allons essayer de vous le proposer dans un prochain billet.

L’usage des documents électroniques dans les processus de collaboration, de communication et de prise de décision ne cesse de s’intensifier: Les décisions stratégiques se basent, entre autres, sur des analyses documentées. La communication intra et inter-entreprise, qui se base sur les messages électroniques et les sites web, se doit de cibler une large audience et représente un media de choix pour communiquer avec les partenaires et les clients.

Les éditeurs logiciels se sont très tôt intéressés au domaine de la gestion des contenus de l’entreprise ou Entreprise Content Management (ECM). Au fil des années la pile logicielle (l’ensemble des logiciels inter opérant au sein d’une entreprise pour compléter un processus métier) s’est complexifiée et a vu une multitude d’intervenants opérants entre eux. Cette interopérabilité est essentielle et même stratégique dans certains cas. Elle est aussi couteuse car les éditeurs sont peu enclins à dévoiler leurs protocoles et leurs interfaces, ceci venant s’ajouter à une hétérogénéité des langages informatiques.

A défaut de pile ECM intégrée, les entreprises se sont donc tournées vers le développement de solution ad-hoc. Tâche qui peut s’avérer ardue et qui aboutit, généralement, à un produit non réutilisable et difficile à maintenir.

Ceci n’est pas sans rappeler les problèmes auxquels furent confrontés les développeurs dans les années 80 avec les systèmes de gestion des bases de données (SGBD). Ce problème a été résolu par l’adoption de standards (ODBC, SQL …) par l’ensemble des fournisseurs de SGBD. Cette solution ayant fait ses preuves, les principaux protagonistes du monde ECM, c’est-à-dire Microsoft, EMC et IBM ont élaborés un nouveau standard nommé CMIS (Content Management Interoperability Services) pour mettre fin à cette véritable tour de Babel des ECM.

La première version de a été soumise fin 2008, et très vite elle a suscité l’intérêt de plusieurs acteurs du marché logiciel tel Alfresco, SAP et Drupal …

Suite à cet engouement, l’organisme de standardisation OASIS adopta le projet pour en faire une norme de l’industrie des ECM. Dès lors, les implémentations de CMIS ont commencés à apparaitre et le premier à en proposer une fût Alfresco suivi par ECM et IBM. Mais Microsoft ne proposa aucune solution pour son produit SharePoint et ce n’est que vers février 2009, que l’on voit apparaitre un article sur MSDN traitant du sujet.

Microsoft SharePoint : une success story

SharePoint est devenu au fil des années un des produits phares de Microsoft (plus de 1 milliards de dollars (US$) en licences vendues durant l’année 2008). Cette large implémentation en entreprise a favorisé l’éclosion d’une communauté très active autour de SharePoint notamment à travers le programme MVP de Microsoft, Codeplex et les clubs SharePoint un peu partout dans le monde.

La part du marché des ECM qu’occupe Microsoft est tellement importante que plusieurs entreprises se sont spécialisées dans l’édition de connecteurs spécifiques pour des logiciels tiers interagissant avec SharePoint. Microsoft devant cet engouement pour le développement sous SharePoint a fait preuve de bonne volonté; en intégrant les protocoles de communication SharePoint dans ses initiatives Open Protocol et Open specification. Ceci a conduit à l’apparition de plusieurs produits compatibles comme par exemple l’intégration de SharePoint dans OpenOffice.org.

La norme CMIS est dans la droite lignée de cette ouverture de Microsoft et sa participation à l’élaboration des standards. Mais malgré ses bonnes intentions, Microsoft reste en retard par rapport à ses concurrents en ce qui concerne l’implémentation des services CMIS, menaçant ainsi son adoption en tel que standard de l’industrie.

CMIS4SharePoint :

S’inscrivant dans un objectif de veille technologique, CMIS4SharePoint est avant tout une étude de faisabilité. L’objectif initial était de démontrer qu’une implémentation de CMIS en utilisant uniquement le modèle objet SharePoint était possible.

Au fil des développements, et après quelques concessions dues à la structure même de SharePoint. Il s’est avéré que cette implémentation était opérationnelle. La décision fût alors prise de faire profiter la communauté de ce développement, c’est ainsi que IP-Tech propose la première implémentation du standard CMIS pour la plateforme SharePoint.

L’architecture nécessite plusieurs aménagement du serveur SharePoint car il se base sur le .NET Framework 2.0 or nous utilisons WCF pour exposer les web services SOAP et REST. Ceci ne peut se faire qu’avec le .NET Framework 3.5 et un « tweak » de SharePoint pour rajouter le support de WCF.

Un scenario simple illustrant l’utilisation de CMIS, peut être la mise en place d’un outil pour l’utilisation offline de SharePoint. Cet outil peut s’avérer très utile pour fournir une meilleure expérience utilisateur dans l’utilisation de SharePoint, car il bénéficie de la puissance de calcul des clients lourds. Aussi on peut envisager sa réutilisation pour d’autres ECM, tel Alfresco ou FileNet. Ainsi, si l’entreprise procède à une migration elle sera presque transparente pour l’utilisateur final. Il conservera la même interface graphique et les mêmes habitudes de travail évitant le réapprentissage imposé par chaque changement d’ECM.

Pour illustrer la facilité qu’apporte l’abstraction CMIS à la création des outils, nous avons développé un client qui liste le nom et l’URL de l’ensemble des bibliothèques de documents disponible dans un site SharePoint.
Pour tester CMIS4SharePoint il faut commencer par créer sur une machine cliente (autre que le serveur SharePoint) un nouveau projet Console sous Visual Studio 2008. On appellera ce projet “ClientTestCMIS”.
Après la création de ce projet, faites un clique droit sur le projet dans explorateur de solution, et sélectionnez “Ajouter référence de services” (Add Service Refrence).

Dans la boite de dialogue qui s’est ouverte, saisissez l’adresse de votre service, appuyez sur “Go” puis sélectionnez le service retrouvé, comme l’illustre cette capture :

Renommez le Namespace du service puis validez.
Maintenant Visual Studio a généré un proxy qui reprend tout les services exposé, il ne reste plus qu’a implémenter le programme dont voici le code source:

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using ClientTestCMIS.CMISReference;

namespace ClientTestCMIS
{
    class Program
    {
        static void Main(string[] args)
        {
            //création du proxy qui va nous permettre de consommer les services
            RepositoryServiceClient repositoryClient = new RepositoryServiceClient();

            //ouverture de la liaison
            repositoryClient.Open();

            //envoi de la requête pour l’obtention de
            //la liste des repositories (des bibliothèque de documents)disponible dans le site SharePoint
            cmisRepositoryEntryType[] repositories = repositoryClient.GetRepositories();

            //fermeture de la liaison
            repositoryClient.Close();

            //affichage du nom et de l’url de chaque bibliothèque de document
            foreach (cmisRepositoryEntryType item in repositories)
            {

                Console.WriteLine(”Name={0}\nURL={1}\n”, item.repositoryName, item.repositoryURI);

            }
        }
    }
}

Perspectives

L’avenir de CMIS4SharePoint est totalement lié à l’intérêt qu’il suscitera auprès de la communauté. Du chemin reste à faire avant de pouvoir proposer une implémentation totalement opérationnelle mais ceci ne saurait tarder.

CMIS4SharePoint peut être utilisé comme une base pour de applications plus élaborée afin de promouvoir l’utilisation de CMIS. Car un standard qu’on n’exploite pas est un standard qui ne sert à rien. CMIS ne subira pas le même sort que les autres tentatives de standardisation des ECM et tout comme JCR il ne sera pas classé comme « une norme de plus ! » (Just another standard !).

First time I had to build my own silverlight control, I asked myself a simple question from where I should start.

Usually, I start by defining the control specific properties that I will implement as a dependency property, after that I specify the default look for this control.

Through this tutorial, we will build a round button control that could be easily personalized.

Now, let’s open Visual Studio select NewProject choose silverlightApplication follow the wizard and you will get two projects a webApplication and a silverlightProject.

The Next step is to create a silverlight library to do this, select the solution explorer right click and choose add NewProject. This time choose silverlightLibary and follow the wizard.

You will end up with something like this:

Dependency Property:

To make our button round, we will use an ellipse. Its width, Height, fill color and stroke color will be specified by the user of our control.

To make that happen we have to add a class in the silverlight class library and make it inherit from Control.

In order to make this class useful we have to.

• Write a constructor
• Write the specific properties as Dependency properties

Achieving these two tasks is pretty straightforward all that we have to do for constructor is to write a line like shown below:

#region Constructor
   public RoundButton()
    : base()
      {
         DefaultStyleKey = typeof(RoundButton);
      }
#endregion

For dependency property, all we have to do is to register the dependency property and implement a setter and a getter for it like the example below:

This code may look cryptic the first time; however don’t worries we will go through it step by step. First this line of code

public static readonly DependencyProperty CircleWidthProperty =
DependencyProperty.Register("CircleWidth", typeof(double), typeof(RoundButton), null);

All that we are doing is registring CircleWidth as a dependency property, this name CircleWidth is very important because it’s the name that will appear in the xaml file when we will use our control in silverlight application, so pick a meanful name.

The first typeof is the type of our dependencyProperty.

The second typeof is the type of our Control if our class was ShinyButton for example the typeof will be ShinyButton instead of RoundButton here.

For the last parameter the one set at null it’s a PropertyChangedCallBack that in case we want to enable our control to change it’s dependency properties values after that it has been seted we have to implemented,we don’t really need it for our Control so we pass null.

The  rest of the dependency property is this:

public double CircleWidth{

get { return (double)GetValue(CircleWidthProperty); }

set { SetValue(CircleWidthProperty, value); }

}

This implementation is prety simple :

For the getter, we have to cast the return to the Property type, double in our case and we have to use the GetValue method that take as parameter CircleWidthProperty that is the DependencyProperty var name.

For the setter we have to use the SetValue method with the appropriate DependencyProperty name as is shown in the picture.

We have to do the same thing for the rest of Dependency Properties and we are done with the control class.

Default Look:

The edition of the default look of our control is done in the generic.xaml file. This file has to be placed under the Themes folder that is created on the silverlight class library. The generic.xaml file has to be a resource file. The generic.xaml.cs file has to be deleted.

Inside the generic.xaml file we have to change UserControl to ResourceDictionary and to import the control namespace.

After that we can start to describe the look of our control.

The generic.xaml has to look something like that:

Conclusion:

We are done with our simple Silverlight control. It’s definitely not the most useful control in the world, but it’s a good starting point for developing your own.

Keep tuned for part 2 of this Silverlight series.

Download source code: SilverlightBlogExample.rar.

Donc on a cherché un outil qui permettrait aux candidats de passer les tests à distance ou dans nos locaux, de garder leurs résultats, de recomposer les quizzes pour les faciliter ou les compliquer en fonction des résultats des premiers tests, etc…

On voulait que cet outil gère les quizzes chronométrés, les questions ouvertes, les questions à plusieurs bonnes réponses, les quizzes à session uniques, etc…

Notre site institutionnel est sous joomla. Très classique. Mais on n’a trouvé aucun composant gratuit joomla qui répond à notre besoin. Donc on l’a créé !

D’où JQuarks

JQuarks est un composant libre et gratuit de gestion de quiz s’intégrant nativement à la version 1.5 du Content Management System Joomla! La version actuelle est la 0.2.2 et elle permet notamment :

• La gestion des questions, ensembles de questions et quizzes.
• L’affectation des utilisateurs enregistrés Joomla! aux quizzes et leur notification par e-mail.
• Le support de trois types de questions (réponse libre, question à choix unique, question à choix multiple).
• Quiz paginés et chronométrés.
• Quiz privé et publique.
• Export des réponses des utilisateurs en format csv (exploitable sous OOSpreadsheets et MSExcel).

JQuarks est le moyen idéal de tester facilement et rapidement les acquis d’étudiants suite à un cours ou de leur proposer des tests blancs, d’effectuer une présélection lors de l’embauche de nouveaux employés etc…

Depuis le site officiel JQuarks.org vous pourrez télécharger JQuarks, avoir accès au guide d’utilisation et même tester JQuarks via notre site de démo.

Cet article a été publié dans le numéro actuel (Octobre 2009) du magazine « PROgrammez ». La version PDF de l’article est mise à votre disposition en téléchargement gratuit.

La configuration basique de OSWorkflow

La configuration par défaut de OSWorkflow repose sur un fichier xml nommé osworkflow.xml (et qui devrait être présent sous la racine du projet ou sous le répertoire META-INF). La structure de celui-ci devra comprendre deux choses essentielles : la classe de persistance et la classe de la factory. La classe de persistance est la classe qui gère la persistance des instances de workflows, des actions, des étapes…alors que la factory gère les descripteurs qui modélisent le workflow. Ci-dessous un exemple de fichier de configuration où la persistance se fait en mémoire (qui n’est bien entendu utile qu’en cas de tests) et où la factory lit (et éventuellement écrit) les modèles à partir de descriptions dans des fichiers XML.

<osworkflow>
   <persistence class="com.opensymphony.workflow.spi.memory.MemoryWorkflowStore"/>
   <factory class="com.opensymphony.workflow.loader.XMLWorkflowFactory">
      <property key="resource" value="workflows.xml" />
   </factory>
</osworkflow>

En partant de ce type de configuration, le point d’entrée dont on dispose pour utiliser OSWorkflow depuis notre code, est d’instancier une classe qui implémente l’interface com.opensymphony.workflow.Workflow et qui, généralement, hérite de com.opensymphony.workflow.AbstractWorkflow. La classe fournie la plus basique (comme son nom l’indique) est BasicWorkflow, qu’on peut utiliser ainsi :

Workflow workflow = new BasicWorkflow("UtilisateurCourant");
DefaultConfiguration config = new DefaultConfiguration();
workflow.setConfiguration(config);

Inconvénients de la configuration basique

Les inconvénients d’une telle utilisation sont assez clairs. En effet, l’instance du workflow qu’on a créé est associé à l’utilisateur « UtilisateurCourant ». Et comme toute application de workflow « sérieuse » fait intervenir plusieurs utilisateurs, on aura au moins une instance par utilisateur. Le deuxième inconvénient se rapporte au fait qu’il sera « lourd » de gérer un point unique et global depuis lequel on invoque les instances du workflow pour lancer des requêtes ou effectuer des actions. C’est pour cela qu’on propose de définir un bean Spring unique dans l’application, qu’on pourra injecter dans les services qui en auront besoin et dont la récupération de l’utilisateur en cours (connecté) se fait de manière transparente à partir du contexte Acegi.

Implémentation Acegi du contexte workflow

Pour mieux appréhender le problème d’integration de Acegi, une compréhension du mécanisme interne de récupération de l’utilisateur (nommé “Caller” dans le vocabulaire de OSWorkflow) s’impose. En fait, la classe AbstractWorkflow récupère le caller à partir d’un service implémentant l’interface com.opensymphony.workflow.WorkflowContext en invoquant la méthode getCaller de celui-ci. Nous allons donc développer notre propre classe de contexte (qui implémente com.opensymphony.workflow.WorkflowContext) et qui renvoie le caller à partir d’un IUserService (un service utilisateur de base), et notre propre classe de workflow (qui hérite de AbstractWorkflow) qui supporte l’injection d’un contexte de façon dynamique.

public class IPTechWorkflow extends AbstractWorkflow {

public IPTechWorkflow() {
}

public void setContext(WorkflowContext wfctx)
{
   super.context = wfctx;
}

}

public class ConnectedUserWorkflowContext implements WorkflowContext{

private IUserService userService = null;

public ConnectedUserWorkflowContext() {
}
public String getCaller() {
   return userService.getConnectedUserInfo().getUsername();
}
public void setRollbackOnly() {
   // Gestion de Rollback non couverte dans cet article
}
}

Nous avons, dans ce code, supposé que l’interface IUserService dispose d’une méthode getConnectedUserInfo() et qui renvoie une instance d’une classe “User”.

Une des avantages de ce type d’integration est qu’il est complétement décorrélé du système d’authentification (remarquez qu’on n’a pas encore évoqué Acegi). Il nous suffit donc, à présent, de fournir une implémentation de l’interface IUserService et qui interroge le contexte Acegi pour récupérer l’utilisateur connecté :

public User getConnectedUserInfo() {

   Object objt = org.acegisecurity.context.SecurityContextHolder.
getContext().getAuthentication().getPrincipal();

   return (User)objt;

}

Définition des beans de configurations

Définissons à présent, les beans Spring qu’on injectera :
- Le bean du service utilisateur qui récupère l’utilisateur à partir de Acegi (implémenté par une classe qu’on appellera AcegiUserServiceImpl)

<bean id="userService"
class="com.iptech.programmez.authentication.AcegiUserServiceImpl">

</bean>

- Le bean du contexte workflow qui renvoie un caller à partir du service utilisateur

<bean id="workflowContext"
class="com.iptech.programmez.workflow.ConnectedUserWorkflowContext">
   <property name="userService" ref="userService"/>
</bean>

- Le bean du workflow qui permettra l’injection d’un contexte

<bean id="workflow"
class="com.iptech.programmez.workflow.IPTechWorkflow">
   <property name="context" ref="workflowContext"/>
</bean>

Nous allons, maintenant, traiter la configuration de la factory et de la persistance avec Spring. Rien ne nous empêche, bien entendu, de laisser les choses comme elles le sont, et définir cette configuration dans notre osworkflow.xml, mais on aurait dans ce cas deux fichiers de configuration distincts. Le but étant de définir un bean pour la factory et un bean pour la persistance et de les injecter directement dans notre bean de workflow.
La distribution de OSWorkflow vient avec la classe com.opensymphony.workflow.config.SpringConfiguration qui est une classe de définition de configuration, qui ne lit pas à partir de osworkflow.xml (comme la configuration par défaut), mais qui nous permet d’injecter directement des beans (elle expose des setteurs pour ceux-ci). L’injection de la configuration devient alors directe.

<bean id="workflow"
class="com.iptech.programmez.workflow.IPTechWorkflow">
   <property name="context" ref="workflowContext"/>
   <property name="configuration">
      <ref local="osworkflowConfiguration"/>
   </property>
</bean>

<bean id="osworkflowConfiguration"
class="com.opensymphony.workflow.config.SpringConfiguration">
   <property name="store">
      <ref local="idBeanDePersistance"/>
   </property>
   <property name="factory">
      <ref local="idBeanDeFactory"/>
   </property>
</bean>

Déclaration du resolver permettant l’utilisation de beans Spring

Nous allons à présent aborder un autre aspect de l’integration de OSWorkflow avec Spring, et qui porte sur l’utilisation de beans Spring comme des pré-fonctions, des post-fonctions et des conditions sur les actions du workflow. En effet, lorsque nous modélisons les étapes et les actions de notre workflow, nous avons la possibilité d’indiquer au moteur de workflow qu’une condition, ou une fonction est implémenté dans un bean Spring plutôt que de lui indiquer directement le nom de la classe. Ceci se fait en injectant au bean du workflow ce qu’on appelle un « resolver ». Le resolver est utilisé par le moteur de workflow pour résoudre les types des conditions et fonctions. Dans notre cas, on s’intéresse à un resolver qui sait interpréter le type « bean spring » et qui récupère celui-ci pour l’invoquer. Un tel resolver est inclus dans la distribution de OSWorkflow, il s’agit de com.opensymphony.workflow.util.SpringTypeResolver qui reconnait les conditions et les fonctions de type « spring » (en minuscule) et invoque le bean dont l’id est indiqué comme valeur de l’argument « bean.name ». On pourra donc, dans notre modélisation, utiliser le bout suivant :

<restrict-to>
   <conditions>
      <condition type="spring">
         <arg name="bean.name">allowOwner</arg>
      </condition>
   </conditions>
</restrict-to>

Et il ne nous reste que d’indiquer au moteur d’utiliser le resolver approprié :

<bean id="workflow"
class="com.iptech.programmez.workflow.IPTechWorkflow">
   <property name="context" ref="workflowContext"/>
   <property name="configuration">
      <ref local="osworkflowConfiguration"/>
   </property>
   <property name="resolver" ref="workflowTypeResolver"/>
</bean>

<bean id="workflowTypeResolver"
class="com.opensymphony.workflow.util.SpringTypeResolver" />

Nous arrivons à la fin de cet article où on a pu mettre en place un bean Spring de workflow qu’on pourra injecter dans nos classes de services, où la récupération de l’utilisateur connecté se fait de manière transparente à partir du contexte Acegi.

Améliorer son IDE en installant des plugins ou en créer est pour le développeur une activité qui va en parallèle avec le cours normal de son travail de développement.

On ne parle pas des améliorations à l’infrastructure utilisée (JEE, .NET Framework, MFC, etc.), dont l’effet va se voir sur le programme développé et ses dépendances : cela est le cas par exemple d’une bibliothèque d’extension à MFC, ou une bibliothèque .NET qui apporte un nouveau controle avec la palette RAD servant à le manipuler via le designer.

Il s’agit plutôt d’améliorations touchant le processus du développement :

• Le refactoring : par exemple, envoyer automatiquement l’implémentation d’une méthode C++ écrite dans le .h, vers le .cpp.
• L’édition:  cela comprend l’intellisense, la façon dont le code est visuellement présenté (coloriage) et la navigation intelligente entre les blocs de code.
• La compilation : certains plugins permettent de la compilation distribuées de projets (exp. Incredibuild)
• La gestion du code : “versionning”, annotation, etc.

L’intérêt de certaines fonctionnalités peut ne pas se justifier facilement, surtout quand il s’agit de besoins spécifiques à une même personne ou un même projet. Dans le cas contraire, où l’amélioration concerne une population plus large, il est opportun d’automatiser cette amélioration et la partager avec la communauté des développeurs.

En revanche, pour passer à la concrétisation, il n’est pas évident de se donner le temps de comprendre l’architecture d’extensibilité d’un IDE donné : comment implémenter une fonctionnalité particulière qui s’installe dans son interface et comment il communique avec ses composants en interceptant et réagissant aux évènements d’intérêt

Visual Studio (VS) n’est pas exception. Par contre, DxCore, publié gratuitement par Devexpress, offre énormément de possibilités pour créer ce type de plugin pour VS.

Mise à jour: Après l’écriture de cet article, DevExpress a rendu public une version légère de son produit CodeRush baptisée CodeRush Express. Cette distribution est fournie avec le noyau DxCore ainsi que plusieurs plugins.

La création d’un plugin est en elle même assistée par des outils RAD. Le développeur n’a qu’à faire des drag-and-drop  du composant de son choix à partir de la toolbox. Ensuite, il a accès à toutes ses propriétés, à la surcharge de ses méthode virtuelles, etc,

Encore plus intéressant : l’accès au résultat du parseur de code DxCore. Dans une override de type OnEditorPaintLangageElement par exemple, qui est appelée par le DxCore lorsque l’éditeur est en train de dessiner un morceau de code particulier, le dévelopeur peut accéder à l’elément en cours, tester son type, accéder à son étendu dans l’éditeur et puis agir sur les propriétés du dessin en modifiant une structure PaintArgs passée en paramètre.

Le sujet est assez intéressant et à la porté de tous les développeurs. Je vous invite à consulter ces liens pour créer vos propres plugins qui vous éviterons les tâches les plus fastidieuses:

• Screencasts officiels
• Plusieurs plugins sur Google Code

This article is also available in English.

java.lang.NullPointerException
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:261)
at java.lang.ClassLoader.loadClass(ClassLoader.java:299)
at com.sun.appserv.server.util.ASURLClassLoader.loadClass(ASURLClassLoader.java:100)
at java.lang.ClassLoader.loadClass(ClassLoader.java:299)
at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
at com.sun.enterprise.util.ConnectorClassLoader.loadClass(ConnectorClassLoader.java:176)
at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1405)
at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1292)
at com.opensymphony.module.propertyset.PropertySetManager.getInstance(PropertySetManager.java:51)
at com.opensymphony.module.propertyset.PropertySetManager.getInstance(PropertySetManager.java:31)
at com.opensymphony.workflow.AbstractWorkflow.canInitialize(AbstractWorkflow.java:395)
at com.opensymphony.workflow.AbstractWorkflow.canInitialize(AbstractWorkflow.java:364)

Mon premier réflexe était de la googler. Suivre les quelques liens de résultats que j’ai trouvé (comme ici, là et là) n’a pas résolu le problème. Des questions sont restées sans réponses, d’autres, ont eu le conseil de vérifier les jars et le packaging. Cela m’a poussé à aller de l’avant, et à analyser le code source pour le déboguer et retracer l’origine du problème.

Ce que j’ai découvert, c’est que le problème réside dans la méthode canInitialize de la classe AbstractWorkflow. Comme tout Workflow (classe qui implémente l’interface Worklflow) hérite de AbstractWorkflow (même si vous développez vos propres implémentations, il est fortement recommandé d’hériter de AbstractWorkflow), vous pouvez avoir ce genre d’exceptions si vous appelez la méthode canInitialize. Il est évident que le fait d’appeler canInitialize existe dans toute application (ou presque) qui se base sur OSWorkflow, tout simplement parce que cette méthode indique si l’utilisateur courant est autorisé à démarrer une nouvelle instance d’un workflow donné.

Les lignes 394 et 395 sont les plus intéressantes (de la méthode canInitialize) :

// since no state change happens here, a memory instance is just fine
PropertySet ps = PropertySetManager.getInstance("memory", null);

Ce que ce bout de code signifie exactement c’est : demander au PropertySetManager d’instancier l’implémentation PropertySet qui a été configuré avec le nom “memory” dans le fichier de configuration de PropertySet. Cela fonctionne à merveille avec la configuration par défaut de PropertySet. Mais qu’en est-il si le développeur choisis d’avoir une configuration PropertySet propre à lui (en ayant son propre propertyset.xml) qui ne définit pas une implémentation PropertySet avec le nom “memory” ?

C’était exactement le cas de tous ceux qui ont fait face à cette exception. A mon avis, une telle implémentation soumet le développeur à une forte contrainte qui n’est mentionné nulle part dans la documentation.

Première solution : Le contournement

La première solution qui peut venir à l’esprit de chacun est celle de définir, tout simplement, une implémentation PropertySet avec le nom “memory”, en ajoutant :

<propertyset name="memory" class="com.opensymphony.module.propertyset.memory.MemoryPropertySet" />

dans le fichier de configuration.

Cette solution est rapide et facile à mettre en œuvre, mais fait introduire quelque chose que, personnellement, je déteste : du code et/ou de la configuration qui ne sert à rien, qui est juste là “pour que ça fonctionne” et que “de toute façon, ça ne mange pas de pain”.

Deuxième solution : Redéfinir la classe AbstractyWorkflow

Une solution plus “clean”, serait de réécrire la classe AbstractWorkflow (i.e. : corriger le bug). Ce qu’on devrait modifier est évidemment la 395^ème ligne.

Commençons par comprendre l’utilité de cette instance de PropertySet (stocké dans la variable ps). Si nous essayons d’examiner les lignes de code suivantes, nous nous apercevrons facilement que cette instance est utilisée pour…rien du tout !

Elle est là, juste parce que la méthode de l’interface Condition prend une instance de PropertySet comme l’un de ses paramètres. Et c’est pour cela qu’on peut lire dans la ligne de commentaire “a memory instance is just fine”, qui veut dire : “une instance mémoire est amplement suffisante”. Puisque une instance PropertySet est toujours associé à une instance de workflow, et qu’il ne s’agit ici d’aucune instance de workflow (rappelez-vous, on essaie juste de savoir si l’utilisateur courant a le droit d’en instancier), cela n’a pas vraiment beaucoup de sens de parler ici d’une instance PropertySet.

C’est une raison pour laquelle affecter ‘null’ à la variable ps peut être suffisant. Mais, si votre (propre) condition dépend du PropertySet passé en paramètre comme ci-dessous :

public boolean passesCondition(Map transientVars, Map args, PropertySet ps) throws StoreException {

String some = ps.getString("param");

Ce qui est, d’ailleurs, bizarre pour une condition d’initialisation de workflow (sauf si c’est une classe réutilisée pour d’autres conditions), vous aurez surement un NullPointerException (à moins que vous ne testiez sur la variable ps).

Bref, je vous suggère un substitut plus sure à notre 395^ème ligne :

//directly instantiate the memory propertyset implementation
//no longer rely on the way the developer configuration

PropertySet ps = new MemoryPropertySet();

Ou aussi, vous pouvez affectez une instance de classe anonyme :

PropertySet ps = new PropertySet(){

    public boolean exists(String arg0) throws PropertyException {
        return false;
    }

    public Object getAsActualType(String arg0) throws PropertyException {
        return null;
    }

    public boolean getBoolean(String arg0) throws PropertyException {
        return false;
    }

    ...
    ...
    ...

    public int getInt(String arg0) throws PropertyException {
        return 0;
    }

    public Collection getKeys() throws PropertyException {
        return Collections.EMPTY_LIST;
    }

    ...
    ...

    public boolean supportsTypes() {
        return false;
    }

};

J’espère que ce billet aidera certaines personnes. Je voulais, juste, ajouter que la deuxième solution proposée peut causer des problèmes ou des comportements inattendus, si vous mettez à jour votre version de OSWorkflow et que vous oubliez de réajustez vos modifications.

Cet article est disponible aussi en Français

java.lang.NullPointerException
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:261)
at java.lang.ClassLoader.loadClass(ClassLoader.java:299)
at com.sun.appserv.server.util.ASURLClassLoader.loadClass(ASURLClassLoader.java:100)
at java.lang.ClassLoader.loadClass(ClassLoader.java:299)
at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
at com.sun.enterprise.util.ConnectorClassLoader.loadClass(ConnectorClassLoader.java:176)
at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1405)
at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1292)
at com.opensymphony.module.propertyset.PropertySetManager.getInstance(PropertySetManager.java:51)
at com.opensymphony.module.propertyset.PropertySetManager.getInstance(PropertySetManager.java:31)
at com.opensymphony.workflow.AbstractWorkflow.canInitialize(AbstractWorkflow.java:395)
at com.opensymphony.workflow.AbstractWorkflow.canInitialize(AbstractWorkflow.java:364)

My first reflex was obviously googling it. Browsing the few results I found (like here, here and here), didn’t brought any solution. Some questions remain responseless, the others suggest verifying the jars or the application packaging. That pushed me to have a look at the source code and to debug it in order to track the problem’s origin. What I found, is that the problem resides in the canInitialize method of the AbstractWorkflow class. As every Workflow (by ‘Workflow’, I mean the classes implementing the Workflow interface) inherits from AbstractWorkflow (even if you develop your own implementation, you are highly encouraged to inherits from AbstractWorkflow), you can have this kind of exception thrown when you call canInitialize. It’s clear that calling canInitialize is present in almost every OSWorkflow based application, as this method is responsible for telling the caller where the current user have the ability to start a new instance of a given workflow.

The 394 and the 395 lines are the most intersting part of the code (of the canInitialize method).

// since no state change happens here, a memory instance is just fine

PropertySet ps = PropertySetManager.getInstance("memory", null);

What this piece of code exactly means is : Tell the PropertySetManager to instantiate the PropertySet implementation that was configured with the name “memory” in the PropertySet configuration file. That can works fine with the default configuration of PropertySet.

But, what if the developer chooses to have a custom PropertySet configuration (by having its own propertyset.xml) that does not define a PropertySet with the “memory” name ?

That was exactly my case and of many others. In my opinion, such implementation makes a tight constraint which is not mentioned anywhere in the documentation.

First solution : The workaround

The first solution that comes to someone’s mind is the workaround of defining a “memory” PropertySet, by adding :

<propertyset name="memory" class="com.opensymphony.module.propertyset.memory.MemoryPropertySet" />

in the custom configuration file.

This is the kind of solutions that are fast, and very easy to implement, but also, the kind of ones that I personally hate, simply because I hate that unused and useless piece of code or piece of configuration, that is here just “to make it work” and that anyway “doesn’t hurt” !

Second solution : Redefining the AbstractyWorkflow class

A cleaner solution would be to rewrite the AbstractWorkflow class (i.e : correct the bug). What have to be changed is obviously the 395^th line.

Let’s begin by understanding what the PropertySet instance (stored in ps variable) is used for. If we try to examine the following lines of code, we easily notice that it is just used for nothing !

It’s there just because the passing conditions methods require a PropertySet instance as one of their parameters. And that’s why, the comment line says “a memory instance is just fine”. And since a PropertySet is always associated with a workflow instance, and we are not dealing with any workflow instance here (remember, we just want to know if the current user can start a workflow), it has no sense to talk about a PropertySet instance here.

That’s why, storing ‘null’ in the ps variable can be enough. But, if your (custom) condition classes rely on the PropertySet passed parameter as below :

public boolean passesCondition(Map transientVars, Map args, PropertySet ps) throws StoreException {

String some = ps.getString("param");

which, by the way, is really weird for a starting workflow condition (only if it’s a reused class for other conditions), you’ll have a NullPointerException thrown (if you’re not testing in the ps variable). So, I suggest a safer replacement for our famous 395^th line :

//directly instantiate the memory propertyset implementation
//no longer rely on the way the developer configuration

PropertySet ps = new MemoryPropertySet();

Or you can also store an anonymous class instance :

PropertySet ps = new PropertySet(){

    public boolean exists(String arg0) throws PropertyException {
        return false;
    }

    public Object getAsActualType(String arg0) throws PropertyException {
        return null;
    }

    public boolean getBoolean(String arg0) throws PropertyException {
        return false;
    }

    ...
    ...
    ...

    public int getInt(String arg0) throws PropertyException {
        return 0;
    }

    public Collection getKeys() throws PropertyException {
        return Collections.EMPTY_LIST;
    }

    ...
    ...

    public boolean supportsTypes() {
        return false;
    }

};

I hope this post could help some people, I want just to add finally that the second solution can cause problems or unexpected behaviour if you make an update of your OSWorkflow jars, and decide to rely on a newer version of the framework, and besides, forget to merge your modifications with the newer class.

Vous avez probablement lu cet article rédigé par mon collègue et dont un extrait a paru dans le magazine français PROgrammez (Version PDF). Savez vous par contre qu’on peut produire des interfaces aussi charmantes en C++ natif ?

Même si l’orientation des éditeurs vers des architectures basées sur les frameworks Java ou Micorosft .NET s’explique essentiellement par la facilité apportée par ces derniers en termes de gestion de complexité, on ne peut nier les effets de mode et les efforts marketing des éditeurs et des communautés de ces produits.

J’estime par ailleurs qu’il est judicieux d’inclure le langage C++ comme une des alternatives pour le développement des nouveaux produits. On ne peut pas imaginer par exemple, un système qui devra interagir avec du hardware ou bien effectuer de gros volumes de calcul algorithmique sans que l’on pense à envisager C++ comme langage de programmation.

Une autre approche consiste à considérer ce langage pour le développement de quelques briques logicielles et les intégrer par la suite à des modules développés sous Java, MS.NET ou autre. Cependant, l’effort de bridging dépensé peut s’avérer parfois beaucoup plus important que tout faire en C++.

Je ne suis pas le seul à promouvoir C++ comme architecture logicielle pour les applicatifs de bureau : il vous suffit de considérer ces deux produits:

• Nefsis : Application de vidéoconférences entourée d’une architecture distribuée pour le streaming et le codage adaptatif.
• Mindmanager : Application de mind-mapping et de brainstorming. Je la connais depuis deux ans mais ce n’est que récemment que j’ai découvert que tout était basé sur C++.

Ces deux applications implémentent Office Fluent UI dans leurs interfaces. Vous pouvez les tester pour croire vos yeux !

Plusieurs éditeurs travaillent aujourd’hui sur l’implémentent de ce type d’interfaces pour les offrir sous formes de classes C++ (codejoke.com, bcgsoft.com, prof-uis.com, etc.). D’autre part, une implémentation C++ en tant qu’extension à MFC a été aussi rendue publique par Microsoft.

Pour illustrer l’implémentation des FUI en C++, on reprendra des bouts de code de « Easy Profiler ». Easy Profiler est un profiler C/C++ composé d’un Collector et d’un Observer. Le collector est une bibliothèque de routines qui sert à générer un fichier XML que l’Observer permet d’illustrer d’une manière intuitive. Ces deux composants ainsi que leur documentation sont téléchargeables sur notre portail Labs.

L’Observer est développé avec MFC 9.0 et fait appel aux nouvelles classes implémentant Office 2007 Fluent UI. L’application permet le changement de thème :

Easy Profiler, disponible sous l’espace LABS, lui, est développé en utilisant MFC 9.0 et les nouvelles classes implémentant Office 2007 Fluent UI :

Ainsi l’application supporte le changement de thème :

En utilisant le thème Office 2007 Blue Luna, l’effet est :

Avec l’effet Aqua :

Plus techniquement, cette fonctionnalité est pilotée par une instance dérivée de CMFCVisualManager. Ainsi, les classes visuelles de MFC délèguent la pluparty de leur code de dessin, à l’instance active en cours. L’appel à CMFCVisualManager::SetDefaultManager permet de sélectionner cette instance.

Le bouton-menu affiché dans l’image 1 est attaché à un menu avec des items dont les ID se trouvent dans l’intervalle [ID_VIEW_APPLOOK_WIN_2000, ID_VIEW_APPLOOK_OFF_2007_AQUA].

Un handler acceptant un UINT est déclaré dans le Message_MAP de la fenêtre principale dont le bouton-menu est un fils, pour gérer cette liste d’ID: ON_COMMAND_RANGE(ID_VIEW_APPLOOK_WIN_2000, ID_VIEW_APPLOOK_OFF_2007_AQUA, &CMainFrame::OnApplicationLook).

Dans le corps de la fonction OnApplicationLook on n’a qu’à sélectionner le VisulaManager en passant une instance dérivée de CMFCVisualManager :

void CMainFrame::OnApplicationLook(UINT id)
{
	CWaitCursor wait;  

	theApp.m_nAppLook = id;  

	switch (theApp.m_nAppLook)
	{
	case ID_VIEW_APPLOOK_WIN_2000:
		CMFCVisualManager::SetDefaultManager(RUNTIME_CLASS(CMFCVisualManager));
		break;  

	case ID_VIEW_APPLOOK_OFF_XP:
		CMFCVisualManager::SetDefaultManager(RUNTIME_CLASS(CMFCVisualManagerOfficeXP));
		break;  

	case ID_VIEW_APPLOOK_WIN_XP:
		CMFCVisualManagerWindows::m_b3DTabsXPTheme = TRUE;
		CMFCVisualManager::SetDefaultManager(RUNTIME_CLASS(CMFCVisualManagerWindows));
		break;  

	case ID_VIEW_APPLOOK_OFF_2003:
		CMFCVisualManager::SetDefaultManager(RUNTIME_CLASS(CMFCVisualManagerOffice2003));
		CDockingManager::SetDockingMode(DT_SMART);
		break;  

...

Avant de retourner (return !), il est nécessaire de diffuser un message aux fenêtres filles pour mettre à jour leurs surfaces.

RedrawWindow(NULL, NULL, RDW_ALLCHILDREN | RDW_INVALIDATE | RDW_UPDATENOW | RDW_FRAME | RDW_ERASE);

Vous voyez que finalement, avec C++ on peut imaginer des interfaces moins sombres que celle sous l’invite de commandes et plus conviviales que celles développées avec les anciennes versions de MFC.

Devant l’insuffisance des outils proposés par les systèmes d’exploitation, en particulier celui proposé par Windows, je me suis dit qu’il serait intéressant d’en faire un! ça sera à la fois pour avoir des bureaux plus spacieux mais aussi pour introduire Poco, qui est une excellente bibliothèque C++.

A travers cet article et un autre qui le suivra, on proposera une approche qui n’exige aucun changement de comportement de la part des propriétaires de tels bureaux. On va cependant leurs offrir un outil qui automatisera l’opération de rangement selon leurs préférences prédéfinis.

On commencera par préparer un squelette applicativ multithread permettant d’interagir avec l’utilisateur via une icône de la Taskbar. Dans le second article, je vous présenterai une bibliothèque intéressante, Poco C++, qui grâce à l’exploitation de certaines de ses routines, notamment la DirectoryIterator, on va pouvoir implémenter les fonctionnalités qu’on désire mettre en place.

Notre squelette sera dérivée de celle d’une application MFC native à base de boite dialogue :

Le point d’entrée InitInstance de l’objet CWinApp crée et initialise une boite dialogue dont les composants sont batis à l’aide du designer.

CMainDlg dlg;
m_pMainWnd = &dlg;
INT_PTR nResponse = dlg.DoModal();

La fonction DoModal déclenche la fonction virtuelle CDialog::OnInitDialog avant de rentrer dans une boucle implicite d’appel à ::PeekMessage et AfxPumpMessage (regarder le code de RunModalLoop). C’est notre thread principal qui permet d’interagir avec l’utilisateur.

Au niveau de CDialog::OnInitDialog nous avons la main pour initialiser le menu Tray à travers lequel l’utilisateur pourra interagir avec l’application:

m_nid.hWnd = GetSafeHwnd ();
m_nid.uCallbackMessage = UM_TRAYNOTIFY;

// Set tray icon and tooltip:
m_nid.hIcon = m_hIcon;

CString strToolTip = _T("Organize my files..");
_tcsncpy_s (m_nid.szTip, strToolTip, strToolTip.GetLength ());

Shell_NotifyIcon (NIM_ADD, &m_nid);

C’est grâce au message UM_TRAYNOTIFY que nous pouvons insérer un callback qui intercepte l’évènement de clique droit sur l’icône tray et affiche un menu contextuel :

LRESULT CMainDlg::OnTrayNotify( WPARAM wp, LPARAM lp )
{
	UINT uiMsg = (UINT) lp;

	switch (uiMsg)
	{
	case WM_RBUTTONUP:
		{
			CPoint point;
			::GetCursorPos (&point);

			CMenu menu;
			menu.LoadMenu (IDR_MENU1);

			CMFCPopupMenu::SetForceShadow (TRUE);

			HMENU hMenu = menu.GetSubMenu (0)->Detach ();
			CMFCPopupMenu* pMenu = theApp.GetContextMenuManager()->ShowPopupMenu(hMenu, point.x, point.y, this, TRUE);

			pMenu->SetForegroundWindow ();
		}

		return 1;
	}

Pour le menu IDR_MENU1, on a construit quatre boutons simples : un bouton Start permettant de démarrer/arrêter un thread silencieux exécutant sa tâche en arrière plan, un bouton About, Configuration et Exit. Chaque bouton est relié à une méthode de la boite de dialogue.

Particulièrement, nous voulons que le texte du bouton start change en fonction de l’état du thread (démarré ou arrêter). De même, on ne doit pas permettre l’accès au bouton configuration quand le thread est en cours d’exécution. Cela est possible en insérant des handlers ON_UPDATE_COMMAND_UI à nos deux commandes et exploitant les méthodes Enable et SetText du paramètre CCmdUI en input.

Le bouton configuration permettra d’afficher la boite de dialogue qu’on s’efforcera de cacher initialement. Là, l’utilisateur pourra spécifier les paramètres du programme qui affecteront l’algorithme exécuté par le thread silencieux.

Dans cette première partie, on se contentera du fonctionnement suivant: L’application s’exécute et se place dans le taskbar. A chaque commande start (exécutée à partir du menu tray), on lance un thread qui à l’échéance d’un durée configurable émet un simple beep. La boite de dialogue permettra de saisir quelques paramètres comme la durée de la période du thread background. La sauvegarde de ces paramètres se fait dans la base de registre.

Une classe abstraite pure CBackgroundThread contiendra la logique de l’exécution de la tâche de fond :

void CBackgroundThread::start()
{
	m_hAbortEvent = CreateEvent(NULL, TRUE, FALSE, NULL);
	ResetEvent(m_hAbortEvent);
	AfxBeginThread(threadProc, this);
}

void CBackgroundThread::stop()
{
	SetEvent(m_hAbortEvent);
}

L’évènement m_hAbortEvent permet de demander au thread lancé de s’arrêter. Ce qui suit est l’algorithme exécuté par le thread d’arrière plan :

void CBackgroundThread::sleepAndExecute()
{
	m_bRunning=true;

	m_hSleepEvent = CreateEvent(NULL, TRUE, FALSE, NULL);
	ResetEvent(m_hSleepEvent);
	//
	HANDLE            hWaits[2];
	hWaits[0]        = m_hSleepEvent;
	hWaits[1]        = m_hAbortEvent;

	UINT    sleepTimeMs=theApp.GetInt(_T(”Sleep Duration”),3)*1000;

	//
	while(true)
	{
		MMRESULT result = timeSetEvent(sleepTimeMs, 1,
		(LPTIMECALLBACK) m_hSleepEvent, 0, TIME_ONESHOT|TIME_CALLBACK_EVENT_SET);
		if (result==NULL)
		break;

		if(WaitForMultipleObjects(2, hWaits, FALSE, INFINITE)==(WAIT_OBJECT_0 + 0))
		{
			//
			executePeriodicJob();
			ResetEvent(m_hSleepEvent);
		}
		else
		break;
	}
	//
	CloseHandle(m_hAbortEvent);
	CloseHandle(m_hSleepEvent);
	m_bRunning=false;
}

Quand le thread d’interface intercepte la command Stop, si le thread d’arrière plan est bloqué sur WaitForMultipleObject, celui-ci retourne immédiatement en retournant l’offset 1 par rapport à la constante WAIT_OBJECT_0 indiquant que l’objet m_hAbortEvent a été signalé, ce qui nous mène à faire un break. Si le thread de travail est en cours d’exécution de executePeriodicJob alors il s’apercevra du signal de terminaison à la prochaine boucle.

Pour notre première version, on a dérivé une classe qui surcharge executePeriodicJob pour exécuter un Beep avant de collecter les paramètres nécessaires, déjà saisis par l’utilisateur.

L’article suivant modifiera cette logique pour boucler sur les fichiers se trouvant dans le répertoire du bureau pour les transférer dans d’autres répertoires selon des règles prédéfinis.

Téléchargements

• Codes sources : OrganizeMyFiles_SourcesC++MFC.zip

Si vous préférez tester l’exemple sans avoir à compiler les sources, vous pouvez téléchearger l’exécutable Windows (.exe):

• Executable : OrganizeMyFilesEXE.zip
  CheckSum de l’exécutable (à calculer après décompression du ZIP)

  CRC32: 3E4CF456
  MD5: 3C26191224AC4667CBD69AF1344C072F
  SHA-1: 290220D84FBEBEEBE33E9CA7395B2199997E387F