samedi 24 septembre 2011

How to fresh up an old API and make it look concise, productive, clean (at last !) ?


I'm an architect of JEE framework we call Orion (MVC, IOC, Persistence, Transaction, Logging, ...).
It's an old one, we started with JDK 1.4 seven years ago.
Some parts of the Orion API are quite heavy and suffers from youth defects, but they perform well .
This API provides a way to create a Query with standard concepts : conjunction, disjunction, operators, joins, ...
Here is a use case : ask the datasource for "people with name starting with a 'D' and living in 'PARIS' "
Query query = new Query();
query.setClazz(People.class);
query.setDistinct(true);
Conjunction and = new Conjunction();
and.addExpression(new SimpleExpression(new Criterion("name"),new StartsWith(),new Parameter("D")));
and.addExpression(new SimpleExpression(new Criterion("place"),new Equals(),new Parameter("PARIS")));
query.setExpression(and);
If i could rewrite some parts of this API, i'd do it right now.
But there are many applications depending on this old,heavy API.
So what can i do to bring an elegant, concise, productive way of using this API without changing the API ?

Internal DSL

An internal DSL can improve dramatically an API usage.
Internal DSL means that we use a real programming language, like Java, to build a small set of API to support a specific domain.
DSL is a hot and huge subject but can be very simple in practice.
Our use case (the Orion API) is elegantly supported by an internal DSL pattern : the Expression Builder pattern.

Improving query manipulation

Here we go with QueryBuilder class:
public class QueryBuilder {
    
    private Query query;
    
    public QueryBuilder(){
        this.query = new Query();
    }
    
    public Conjunction and(Expression ...expressions){
        Conjunction conjunction = new Conjunction();
        for(Expression expr:expressions){
            conjunction.addExpr(expr);    
        }
        return conjunction;
    }
    public Disjunction or(Expression ...expressions){
       Disjunction disjunction = new Disjunction();
        for(Expression expr:expressions){
            disjunction.addExpr(expr);    
        }
        return disjunction;
   }
   
   public SimpleExpression equals(String name,Object value){
       return new SimpleExpression(new Criterion(name),new Equals(),new Parameter(value));
   }
   
   public SimpleExpression startsWith(String name,Object value){
       return new SimpleExpression(new Criterion(name),new StartsWith(),new Parameter(value));
   }
   
   public QueryBuilder where(Expression expression){
       this.query.setExpression(expression);
       return this;
   }
   
   public QueryBuilder distinct(){
       this.query.setDistinct(true);
       return this;
   }

   QueryBuilder clazz(Class aClass) {
       this.query.setClazz(aClass);
       return this;
   }

   
   Query getQuery(){
       return this.query;
   }    
}
Now, the same Query but built using our DSL :
QueryBuilder qb = new QueryBuilder();
qb.clazz(People.class).where(
      qb.and(
               qb.startsWith("name","D"),
               qb.equals("place", "PARIS")
               
)).distinct();
Query query = qb.getQuery();
The DSL version is much more readable. It hides the process of created a query to focus on user need : to express easily a query.
A more complex sample :
QueryBuilder qb = new QueryBuilder();
qb.clazz(People.class).where(
      qb.and(
               qb.startsWith("name","D"),
               qb.equals("place", "PARIS"),
               qb.or(
                   qb.equals("role", "admin"),
                   qb.equals("role", "manager")
               )                
      )
).distinct()
Finally, i can keep my old API and offer an easy way to implement most common use cases. I can improve my builder : it can accept an existing query and act as a deluxe wrapper.
Your turn !!!




Contrat Creative Commons

the jee architect cookbook by Olivier SCHMITT est mis à disposition selon les termes de la licence Creative Commons Paternité - Pas d'Utilisation Commerciale - Pas de Modification 3.0 Unported.

A Maven archetype quick start for JSF JQuery Mobile dev !


I'm proud to announce the release of a Maven archetype for JSF JQuery Mobile dev !
It's a quick start (tested with Maven 2.1.0, 2.2.X, 3.X) and runs at least with Glassfish 3.1.1, Tomcat 7, Tomcat 6.
mvn archetype:generate -Dfilter=jqmobile -DarchetypeCatalog=http://oss.sonatype.org/content/repositories/releases/archetype-catalog.xml
This artefact should be available very soon from Maven Central repository, so the archetypeCatalog argument will be useless.
It's not intended to cover all needs but simply give a your project a quick start.
I will update this archetype with best practices time after time.
Don't forget to apply best practice (corporate POM, ...).
Hope you enjoy !





Contrat Creative Commons

the jee architect cookbook by Olivier SCHMITT est mis à disposition selon les termes de la licence Creative Commons Paternité - Pas d'Utilisation Commerciale - Pas de Modification 3.0 Unported.

samedi 17 septembre 2011

L'accessibilité est-elle l'amie du développeur ?


Depuis quelques années, le nombre de navigateurs se multiplient avec les plateformes (PC, Netbook, Smart Phone, Tablet, ....) et de plus en plus de personnes de tous âges et de toutes conditions ont accès à Internet.
Nous développeurs serons-nous capable de répondre aux attentes de tous nos utilisateurs ?
Les applications webs sont-elles réservées à une élite dotée des meilleures capacités physiques et cognitives ?
L'accessibilité peut nous aider à construire des applications ouvertes au plus grand nombre tout en ayant des effets de bords positifs sur les performances, la maintenance et la qualité des applications.
En effet, dans le contexte d'une refonte de notre cadriciel web maison, j'ai du mener une étude pour mesurer les impacts de l'application de règles d'accessibilité. Les résultats de mon étude montre que l'accessibilité doit être au coeur du processus de développement.

WCAG 2.0 : l'accessibilité appliquée au web


Le consortium W3C propose la norme WCAG pour l'accessibilité des contenus webs aux personnes en situation de handicap.
Un handicap est selon Wikipedia :
la limitation des possibilités d'interaction d'un individu avec son environnement, causée par une déficience qui provoque une incapacité, permanente ou non et qui mène à un stress et à des difficultés morales, intellectuelles, sociales ou (et) physiques.
Nous baserons nos réflexions sur cette norme qui définit 4 grands principes à respecter :
  • Perceptible : l'information et les composants de l'IHM doivent être présentés à l'utilisateur de façon à ce qu'il puisse les percevoir.
  • Utilisable : les composants de l'IHM et de navigation doivent être utilisables.
  • Compréhensible : rendre le contenu textuel lisible et compréhensible.
  • Robuste : optimiser la compatibilité avec les agents utilisateurs actuels et futurs, y compris les technologies d'assistance.
Chaque principe est décliné en plusieurs règles d'accessibilité à respecter. Chaque règle est associée à un niveau d'accessibilité : A, AA ou AAA.
Plus le niveau est élevé plus la règle est complexe et coûteuse à implémenter.
Evidemment, l'utilisation d'un cadriciel web supportant WCAG et un niveau d'accessibilité donné (AA par exemple) est un atout déterminant pour la mise en oeuvre du référentiel WCAG dans vos applications webs. Le cadriciel permet alors d'absorber une grande partie des coûts.

Mise en oeuvre du WCAG


Il est important de comprendre qu'il ne faut pas appliquer bêtement ce référentiel.
Tout d'abord, il convient de choisir un niveau d'accessibilité pour vos contenus webs. D'ailleurs, plusieurs niveaux d'accessibilité peuvent coexister au sein d'une application web qui regroupe des contenus différents.
En effet, il peut être plus judicieux de proposer un niveau AA pour les contenus les plus populaires, un AAA sur les quelques contenus critiques puis un niveau A sur la majorité des contenus , plutôt que de se fixer un niveau AA sur tous les contenus.
Le référentiel WCAG est accompagné d'un guide technique qui propose des solutions pour la mise en oeuvre de chaque règle.
Il est aussi crucial de comprendre que la mise en oeuvre du WCAG doit se faire dès la conception de l'application.
Quelque exemples de règle :
  • Règle 1.4.3 (AA) : la présentation visuelle du texte et du texte sous forme d'image a un rapport de contraste d'au moins 4,5:1
  • Règle 1.4.4 (AA) : à l'exception des sous-titres et du texte sous forme d'image, le texte peut être redimensionné jusqu'à 200 pour cent sans l'aide d'une technologie d'assistance et sans perte de contenu ou de fonctionnalité.
  • Règle 3.3.1 (A) : si une erreur de saisie est détectée automatiquement, l'élément en erreur est identifié et l'erreur est décrite à l'utilisateur sous forme de texte.
  • Règle 4.1.1 (A) : à moins que les spécifications ne le permettent, dans un contenu implémenté via un langage de balisage, les éléments ont des balises de début et de fin complètes, ils sont imbriqués conformément à leurs spécifications, ils ne contiennent pas d'attributs dupliqués et chaque ID est unique.
Si tous les développements sont faits quand vous essayez d'appliquer le référentiel alors vous serez contraints de revoir la totalité des contenus webs .
Ceci implique que l'équipe de développement, du chef de projet au développeur doivent connaître les règles à appliquer avant de commencer à développer l'application.
Comme on vient de le voir, l'accessibilité a un impact important sur l'équipe de développement.
Mais quels sont les bénéfices que vous pouvez en tirez ?

Les coûts de développement et de maintenance


Certaines règles (1.3.1, 1.4.5, ...) vous contraignent à séparer la présentation de l'information, de l'information elle même. Cela se traduit par une utilisation de feuilles CSS et de XHTML.
Très vite on en vient à envisager la mise en place de thèmes basés sur CSS car si l'on veut présenter de l'information pour des publics différents au moindre coût (daltonien, mal voyant, normal, smartphone, tablet, ...), c'est la bonne pratique à mettre en oeuvre.
Cette factorisation des éléments de présentation dans les CSS permet d'avoir un code XHTML plus clair et de cibler les changements sur quelques CSSs plutôt que de revoir chaque contenu HTML ou XHTML de l'application.
Certaines règles mettent en avant le respect de la syntaxe XHTML (4.1.1) ou l'ajout de méta données (4.1.2), ceci permet l'utilisation d'outils de validation ou transformation.
En effet, imaginez que votre application contient des composants de type "Calendrier" traduit en XHTML sous la forme d'un amas de DIV.
En utilisant l'attribut role vous allez indiquer que cette zone avant informe correspond à un composant graphique de type calendrier :
  <div id="cal1"  role="calendar" ...>
     <!Code XHTML >
  </div>
Ce faisant vous ouvrez la voie à des applications intéressantes comme la transformation de contenu XHTML.
Imaginez que votre client vous demande de revoir la charte graphique et ergonomique de l'application, vous pourrez ainsi utiliser une transformation des composants XHTML par une technologie quelconque qui supporte XHTML et XSLT.

Les performances


Certaines règles poussent à privilégier l'utilisation de texte plutôt que d'images ce qui réduit le nombre de requêtes HTTP et diminuent l'utilisation de la bande passante :
  • l'information véhiculée par du texte est nettement plus compressible que les images.
  • avec la diminution du nombre de requêtes HTTP, vos serveurs seront moins sollicités.
D'autres règles promeuvent une navigation claire ainsi que des mécanismes de navigation et d'interactivité maîtrisés par l'utilisateur. En effet, nombre de site web proposent des contenus qui multiplient les requêtes via des composants qu'IHM que l'utilisateur subit.
Quelques règles impliquées dans l'amélioration des performances : 1.4.5, 3.2.5, ....

Conclusion


L'accessibilité est un élément fondamental des applications webs. Pour être sans douleur, elle doit être prise en compte dès la conception et doit structurer la réalisation ou la maintenance de tous les éléments d'IHM.
Quelques références :



Contrat Creative Commons
the jee architect cookbook by Olivier SCHMITT est mis à disposition selon les termes de la licence Creative Commons Paternité - Pas d'Utilisation Commerciale - Pas de Modification 3.0 Unported.