Flux RSS de gandbox.fr - eZ Publish

eZ Conference 2010 slides about eZ Find 2.2 customization & advanced development

Sun, 27 Jun 2010 15:34:50 +0000

On June 24th, at the 2010 eZ Conference developer track, I proposed a talk about eZ Find 2.2 customization & advanced development. This talk illustrate and summarize my eZ Find articles / tutorials you'll find below, with new schemas and real project exemples. Thanks to all the eZ Community for their interest and questions during the conference. I hope to have time to write one of these requested tutorials in coming month.

I'd like to thanks Nicolas Pastorino for the english translation of my articles on share.ez.no.

Download the PDF version, or browse the slideshare version.

Slideshare version

Articles / tutorials about eZ Find

French articles about eZ Find on gandbox.fr :

English articles about eZ Find (translation from French), on share.ez.no :

Advanced development with eZ Find - part 1 : Datatypes in Solr and eZ Find
Advanced development with eZ Find - part 2 : Indexing additional fields in Solr
Advanced development with eZ Find - part 3 : Not yet publish... coming soon

Développement avancé avec eZ Find (partie 3 : Tirer profit de la syntaxe Solr)

Sun, 23 May 2010 17:17:36 +0000

Le billet précédent décrit comment ajouter des champs supplémentaires dans Solr, afin de pouvoir les exploiter avec la syntaxe native d'eZ Find sous la forme 'mycontentclass/mycontentattribute/mycontentsubattribute'.

Cette syntaxe spécifique à eZ Find est certes confortable mais non exclusive, à savoir qu'il est possible de mixer des éléments de syntaxes eZ Find et des éléments de syntaxes Solr, comme par exemple les noms des champs ('attr_myfield_type') ou encore des opérateurs logiques (AND, NOT, etc.).

“
- OUI c'est une mauvaise pratique. Une syntaxe 'interface' n'est pas faites pour être outrepasser, au risque de compromettre l'évolutivité de la couche basse, à savoir Solr
- OUI cela peut faciliter les développements, voir même sauver la vie du développeur sur certaines situations complexes
”

Ce billet montre quelques exemples d'exploitation de la syntaxe Solr, volontairement simplifiés pour en faciliter la compréhension.

Faire un tri sur un attribut commun à plusieurs classes

Il s'agit d'un grand classique des problématiques d'eZ Publish, à savoir :

On crée 2 classes différentes pour X raisons "Post" et "Article"
On ajoute dans chacune des classes des attributs communs, parceque utile dans les 2 cas, par exemple un attribut "Date"

Résultat : Impossible de mélanger les "Post" et "Article" en les triant par dates décroissante (sauf à développer un terrifiant opérateur de template). Généralement, les développeurs font en sorte d'utiliser une seule classe plus générique afin de contourner ou plutôt déplacer le problème (la mutualisation d'une classe peut avoir d'autres inconvénients).

La solution des attributs communs entre les classes avec eZ Find :

Le premier billet de cette série consacré à eZ Find décrit la logique de nommage des champs dans Solr. Une effet secondaire positif de cette convention (lié au concept de dynamicfields de Solr) est l'absence bienheureuse de l'identifiant de la classe dans le nom de chaque champs. Il est ainsi possible d'exploiter les champs homonymes comme bon nous semble, au travers de recherche, filtres ou tris en fonction du besoin.

Exemple de code de template eZ Publish sur la seule classe "Post" :

{def $search_result = fetch( 'content', 'list', hash( 'parent_node_id', 2,
    'class_filter_type',  'include',
    'class_filter_array', array(24),
    'sort_by', array( array( 'attribute', false(), 'post/date' ) ),
    'limit', 10,
    'depth', 3
))}

Exemple équivalent de code de template eZ Find pour notre problématique de tri inter-classes "Post" et "Article" :

{def $search=fetch( ezfind, search,
     hash( query , '',
           'class_id', array('post', 'article'),
           'limit', 10,
           'sort_by', hash('attr_date_dt', 'desc')
))}

A noter : une évolution souhaitable d'eZ Find serait de pouvoir exploiter une syntaxe du type '//date', afin de rendre facultatif l'ajout de la classe dans le filtre Solr généré.

Travailler avec les keywords

Contrairement à l'exemple précédent sur les dates, les keywords disposent dans eZ Publish d'une table externe au contenu (ezkeyword_attribute_link), permettant de lier chaque keyword à divers contenus de diverses classes. Cependant le fetch par keyword ne dispose pas de tous les filtres possibles d'un fetch par list par exemple (class_filter_type, class_filter_array, extended_attribute_filter, etc.). Cette limitation se comprend puisque permettre un filtre inter-classes engendre forcement une limitation sur les fonctionnalités liées aux attributs spécifiques à chaque classes.

Sur le même logique que le traitement par date, on peut donc exploiter eZ Find pour effectuer toutes les opérations nécessaires autour des keywords. Voici un exemple de code :

'filter', array('attr_tags_lk:"ez publish"', 'NOT attr_title_t:"RSS"')

Résultat : Retourne uniquement les résultats associés au keyword "eZ Publish" ou "ez publish" (notez l'utilisation du _lk pour lowercase), ne contenant pas "RSS" dans le titre

'filter', array('attr_tags_lk:"ez publish"', 'attr_tags_lk:"mootools"')

Résultat : Retourne uniquement les résultats associés à la fois au keyword "eZ Publish" ou "ez publish", et au keyword "Mootools" ou "mootools"

Faire des filtres complexes

Voici quelques exemples de filtres, qui n'ont rien d'exhaustif puisqu'il est possible d'exploiter l'ensemble des opérateurs Lucene en fonction de la version de Solr déployée (version de Solr 1.4, disponible dans eZ Find 2.2 lors de la rédaction de ce billet).

'filter', array('NOT ( attr_title_t:(ez+find) OR attr_intro_t:(ez+find) )')

Résultat : Retourne uniquement les résultats qui possèdent l'expression 'ez find' ou 'eZ Find', dans l'attribut 'title' ou l'attribut 'Intro'. Il faut noter l'utilisation de la version 'text' (_t) sur l'attribut 'title' permettant de profiter du non respect de la casse (contrairement au type 'string').

'filter', array('attr_title_s:[A TO G] AND ezf_df_text:google~0.7')

Résultat : Retourne uniquement les résultats dont le 'title' commence par A,B,C,D, E ou F (G exclu), et dont le contenu possède approximativement l'expression 'google' (Google, iGoogle, etc.).

A noter : Le ratio '0.7' peut être ajuster au besoin
A noter : le champs 'ezf_df_text' est un champs constitué dynamiquement et par recopie de tous les autres champs de types 'string', 'text' ou 'keyword'. On peut aussi utiliser le champs 'ezf_sp_words' si la fonctionnalité de spellcheck est exploitable. Voir le fichier schema.xml et la définition de ces champs par copyField pour plus de détail.

Développement avancé avec eZ Find (partie 2 : Indexer des champs supplémentaires dans Solr)

Sun, 16 May 2010 13:30:10 +0000

Le billet précédent décrit les mécanismes bas niveaux d'eZ Find, et la façon dont les correspondances entre les attributs eZ Publish (noms, types de champs) et les champs Solr sont gérés. Ce billet décrit comment eZ Find peut considérablement faciliter le développement de certaines fonctionnalités (en évitant de complexes opérateurs de templates aux multiples requêtes SQL...), en ajoutant automatiquement des champs dans Solr lors de l'indexation d'un contenu, ré-exploitables par la suite pour la construction d'une facette par exemple ou pour profiter d'un filtre supplémentaire.

Etude de cas : un filtre par années, et par mois-années

L'exemple étudié a surtout une valeur pédagogique, puisqu'il s'agit d'un besoin générique et relativement simple à implémenter. Les listes d'actualités, ou les listes de billets sur les Blogs proposent généralement des filtres par années (2010) ou par mois / année (Janvier 2010) (comme sur ce blog par exemple dans la colonne de droite). Habituellement, pour ce genre de filtre on développe un opérateur de template permettant d'effectuer la requête SQL nécessaire, ce qui peut rapidement devenir très complexe. Il suffit de lire le code de l'opérateur de template eZArchive pour en comprendre les limites.

Il est relativement fréquent que ces manipulations SQL souffrent de carences fonctionnelles, comme la propagation des droits, la gestion des langues, la gestion de certaines subtilités entre MySql ou PostGreSql. Ce sont des problématiques à la charge du développeur, puisque l'on contourne les API pour exploiter directement du SQL. Par ailleurs, l'opérateur eZArchive montre une autre limite importante, puisqu'il se contente de travailler sur la date de publication 'publication_date' (par facilité), et ne permet donc pas d'exploiter un attribut de date spécifique à la classe.

Développer le filtre par années, et par mois-années avec eZ Find

Etape 1 : Indexer les années, mois / année vers Solr

Les settings d'eZ Find (ezfind.ini, à surcharger dans le ezfind.ini.append.php de votre extension) permettent de déléguer le traitement de l'indexation d'un datatype eZ Publish vers une classe PHP :

[SolrFieldMapSettings]
CustomMap[ezdate]=ezfSolrDocumentFieldDate

Notre classe PHP, nommée arbitrairement ezfSolrDocumentFieldDate hérite de la classe ezfSolrDocumentFieldBase et doit être ajoutée dans le dossier /extension/myextension/classes/ezfsolrdocumentfielddate.php avec le squelette suivante :

<?php
class ezfSolrDocumentFieldDate extends ezfSolrDocumentFieldBase
{
 public static function getFieldName( eZContentClassAttribute $classAttribute, $subAttribute = null, $context = 'search' )
 {
 // return the fieldname like : attr_mydate_d
 }
 
 public function getData()
 {
 // return the array keys (fieldname => value), like : array('attr_mydate_dt' => '2010-04-30T00:00:00Z')
 }
}
?>

Le rôle de la méthode getFieldName

Cette méthode est invoquée pour transformer les noms des attributs eZ Find vers les noms de champs Solr. Ainsi lorsqu'on construit une facette avec la syntaxe 'mycontentclass/mydateattribute', cette méthode reçoit 'mydateattribute' et doit retourner 'attr_mydateattribute_dt'. Nous allons donc implémenter cette fonction de la façon suivante :

Si un sous attribut est spécifié (par exemple 'mycontentclass/mydateattribute/year'), alors retourne le nom composé du sous attribut
Si aucun sous attribut n'est spécifié, alors exécute le code de la classe parent
Important : Pour profiter d'une certaine généricité, et éviter de nommer 'en dur' les champs Solr, nous utilisons les méthodes parents generateSubattributeFieldName et generateAttributeFieldName

const DEFAULT_SUBATTRIBUTE_TYPE = 'date';
 
public static function getFieldName( eZContentClassAttribute $classAttribute, $subAttribute = null, $context = 'search' )
{ 
  switch ( $classAttribute->attribute( 'data_type_string' ) )
  {
    case 'ezdate' :
    {
     if ( $subAttribute and $subAttribute !== '' )
     {
      // A subattribute was passed
      return parent::generateSubattributeFieldName( $classAttribute,
       $subAttribute,
       self::DEFAULT_SUBATTRIBUTE_TYPE );
     }
     else
     {
      // return the default field name here.
      return parent::generateAttributeFieldName( $classAttribute, self::getClassAttributeType( $classAttribute, null, $context ) );
     }
  } break;
    
    default:
    {} break;
  }
}

Le rôle de la méthode getData

Cette méthode est invoquée pour extraire les données d'eZ Publish, et les préparer pour leur indexation vers Solr. C'est donc dans cette méthode que l'on peut ajouter nos champs supplémentaires 'year' et 'yearmonth'. Pour faciliter la future exploitation de ces champs avec eZ Find, je souhaite pouvoir construire des facettes ou des filtres selon la syntaxe classique :

'mycontentclass/mydateattribute/year', dont la transposition Solr serait 'subattr_date-year_dt'
'mycontentclass/mydateattribute/yearmonth', dont la transposition Solr serait 'subattr_date-yearmonth_dt'

public function getData()
 {
  $contentClassAttribute = $this->ContentObjectAttribute->attribute( 'contentclass_attribute' );
 
  switch ( $contentClassAttribute->attribute( 'data_type_string' ) )
  {   
  case 'ezdate' :
  {
  $returnArray = array();
   
  // Get timestamp attribute value
  $value = $this->ContentObjectAttribute->metaData();
   
  // Generate the main filedName attr_XXX_dt 
  $fieldName = parent::generateAttributeFieldName( $contentClassAttribute,
  self::DEFAULT_ATTRIBUTE_TYPE );
 
  $returnArray[$fieldName] = parent::convertTimestampToDate( $value );
 
  // Generate the yearmonth subattribute filedName subattr_year_dt
  $fieldName = parent::generateSubattributeFieldName( $contentClassAttribute,
  'year',
  self::DEFAULT_SUBATTRIBUTE_TYPE );
 
  $year = date("Y", $value); // Get Year value : 2010
  $returnArray[$fieldName] = parent::convertTimestampToDate( strtotime($year.'-01-01') );
 
  // Generate the yearmonth subattribute filedName subattr_yearmonth_dt
  $fieldName = parent::generateSubattributeFieldName( $contentClassAttribute,
  'yearmonth',
  self::DEFAULT_SUBATTRIBUTE_TYPE );
 
  $month = date("n", $value); // Get Month value : 3
  $returnArray[$fieldName] = parent::convertTimestampToDate( strtotime($year.'-'.$month.'-01') );
   
  return $returnArray;
   
  } break;
 
  default:
  {} break;
  }
 }
}

A noter : $returnArray contient un tableau à clés, dont voici un exemple de sortie (effectuer avec var_dump) :

array(3) {
 ["attr_date_dt"]=>
 string(24) "2008-12-28T00:00:00.000Z"
 ["subattr_date-year_dt"]=>
 string(24) "2008-01-01T00:00:00.000Z"
 ["subattr_date-yearmonth_dt"]=>
 string(24) "2008-12-01T00:00:00.000Z"
}

A noter : Solr utilise le format de date ISO 8601, du type '2010-04-30T00:00:00Z'. La classe parent ezfSolrDocumentFieldBase propose la méthode convertTimestampToDate() pour convertir un format timestamp vers un format ISO 8601.

Le template de construction des facettes

Nos données par années et par mois-année sont maintenant disponibles. Il ne reste plus qu'à construire nos facettes avec la syntaxe habituelle :

{def $search_yearmonth=fetch( ezfind, search,
 hash( query , '',
 'facet', array( 
 hash('field', 'billet/date/year', 'sort', 'alpha', 'limit', 20 ),
 hash('field', 'billet/date/yearmonth', 'sort', 'alpha', 'limit', 20 )
 ),
 'class_id', array('billet'),
 'subtree_array', array(2)
 ))}
 
 {def $search_extras_year=$search_yearmonth['SearchExtras'].facet_fields[0].nameList|reverse}
 {def $search_extras_yearmonth=$search_yearmonth['SearchExtras'].facet_fields[1].nameList|reverse}
 {def $date_count = 0
 $date_ts = 0}
 
<li id="blog_block_10" class="colonne_block">
 <h1>Archives par années :</h1>
 <ul class="{$current_css} list">
 {foreach $search_extras_year as $facetID =&gt; $datevalue}
  {set $date_count = $search_yearmonth['SearchExtras'].facet_fields[0].countList[$facetID]}
  {set $date_ts = $datevalue|strtotime}
 <li><a href={concat('/Blogs/(year)/',$date_ts|datetime( 'custom', '%Y' ))|ezurl} title="Archives : {$date_ts|datetime( 'custom', '%Y' )} // {$date_count} Billet(s)">{$date_ts|datetime( 'custom', '%Y' )}</a></li>
 {/foreach}
 </ul>
</li>
<li id="blog_block_11" class="colonne_block">
 <h1>Archives par mois / années :</h1>
 <ul class="{$current_css} list">
 {foreach $search_extras_yearmonth as $facetID =&gt; $datevalue}
  {set $date_count = $search_yearmonth['SearchExtras'].facet_fields[1].countList[$facetID]}
  {set $date_ts = $datevalue|strtotime}
 <li><a href={concat('/Blogs/(year)/',$date_ts|datetime( 'custom', '%Y' ),'/(month)/',$date_ts|datetime( 'custom', '%n' ))|ezurl} title="Archives : {$date_ts|datetime( 'custom', '%F %Y' )} // {$date_count} Billet(s)">{$date_ts|datetime( 'custom', '%F %Y' )|upfirst}</a></li>
 {/foreach}
 </ul>
 
</li>
{undef $date_ts $date_count $search_yearmonth $search_extras_yearmonth}

A noter : Le fetch proposé est relativement basique, afin de faciliter la compréhension du mécanisme. Il faut bien sur faire évoluer le code pour obtenir le fonctionnel attendu (utiliser les filtres par exemple), mais ce n'est pas l'objet de ce billet puisque la documentation officielle détaille déjà la façon de procéder.

A noter : le 'sort', 'alpha' ne permet pas réellement de spécifier que l'on souhaite un tri alphabétique. Il s'agit surtout de spécifier que l'on ne souhaite pas un tri par 'count' (nombre d'items associés à la facette). Dans ce cas Solr applique un tri automatique 'croissant' en fonction de son index et du type de donnée (ce qui explique l'utilisation de l'opérateur reverse pour obtenir une liste décroissante).

Développement avancé avec eZ Find (partie 1 : La gestion des datatypes entre eZ Find & Solr)

Sun, 09 May 2010 13:07:06 +0000

Après 2 billets un peu "rapides" sur eZ Find et la gestion des datatypes, ainsi que l'utilisation des facettes pour construire un nuage de tags, voici le premier billet d'une série de tutoriels à propos d'eZ Find, qui décrivent plus en détail son fonctionnement et son utilisation avancée dans divers contextes. Cette série de tutoriels introduit quelques nouveautés de la version 2.2, sera traduite progressivement sur le share.ez.no, et servira de base pour une conférence de la eZ Conference 2010, ainsi qu'aux Recontres Mondiales du Logiciel Libre 2010

Cet article décrit comment eZ Find transforme et adapte les contenus eZ Publish, et leurs datatypes respectifs pour les indexer dans Solr. La compréhension de ces mécanismes bas niveaux d'eZ Find sont des prérequis indispensables lors des phases de développement et de debug, ne serait ce que pour savoir ou chercher et lire les portions de codes permettant de comprendre le rôle exact d'un settings, d'un paramètre ou d'un filtre.

Etape 1 : Prérequis avant de démarrer

Cet article n'a pas vocation à expliquer à nouveau comment installer et indexer son contenu avec eZ Find. La documentation décrit avec précision les opérations à effectuer. Cependant voici quelques astuces permettant de développer dans de bonnes conditions :

Relancer l'indexation du contenu après une modification

Il est parfois laborieux de relancer une indexation complète juste pour tester l'impact d'une modification mineure. Alors il existe pour cela quelques paramètres cachés dans le script /bin/php/updatesearchindexsolr.php, qui permettent de désigner un noeud parent de départ, ainsi q'une limite (attention les 3 paramètres combinés sont nécessaires) :

php extension/ezfind/bin/php/updatesearchindexsolr.php --siteaccess=monsiteaccess --topNodeID=2546 --offset=0 --limit=10

Vérifier ce que Solr a réellement indexé

Pour savoir si vos contenus et vos attributs sont correctement indexés, il suffit d'effectuer une recherche dans l'interface Web d'administration de Solr : http://localhost:8983/solr/admin/. Cette interface est également utile pour vérifier comment les champs Solr ont été nommés, par exemple sur la version d'eZ Find 2.2, on peut observer 2 champs qui semblent des doublons concernent les titres des articles : attr_title_s et attr_title_t. La suite du billet détaille le comment et le pourquoi de ce comportement.

Debug direct avec Solr

En laissant une console active, pour pourrez observer les messages envoyés vers Solr de la forme :

INFO: [] webapp=/solr path=/select params={ ... MESSAGE ... } status=400 QTime=5

Ce message peut être copier / coller à partir de la console, vers la fin de l'URL dans l'interfaçe d'administration de Solr : http://localhost:8983/solr/select/?MESSAGE. On obtient ainsi une sortie exacte de ce que Solr envois à eZ Find avant transformation. Cette manipulation est utile lors des phases de Debug, par exemple en manipulant directement le message pour obtenir exactement le résultat attendu.

Etape 2 : Comment eZ Find pousse le contenu eZ Publish vers Solr

Voici le parcours d'exécution du code lors de l'ajout / modification d'un contenu eZ Publish :

Exécution de la méthode registerSearchObject, de la classe eZContentOperationCollection
Si DelayedIndexing activé (voir détail ci dessous) : ajout d'objectID à la table 'ezpending_actions' pour un traitement ultérieur
Si DelayedIndexing désactivé, fetch de l'objet et transmission de l'objet à la méthode eZSearch::addObject( $object, $needCommit )
Si eZ Find installé et activé, appel de la méthode eZSolr::addObject( $contentObject, $commit = true )
Au final, une fois les contenus préparés, appel de la méthode addDocs de la classe /extension/ezfind/classes/ezsolrbase.php, qui POST ensuite les données via HTTP à l'aide de cURL

eZ Find, un plug-in de recherche

eZ Find est construit comme un plug-in de recherche, c'est à dire que le module /content/search a été nativement construit pour être déporté sous forme de plug-in. Ainsi dans l'extension /ezfind/settings/site.ini.append.php on trouve la déclaration du plug-in :

[SearchSettings]
SearchEngine=ezsolr

C'est ensuite la méthode getEngine() (kernel/classes/ezsearch.php) qui s'occupe d'affecter la bonne classe PHP pour interfacer le plug-in de recherche, à savoir : /search/plugins/ezsolr/ezsolr.php

eZ Find et le mécanisme natif du DelayedIndexing

Lors des différentes opérations de mises à jours de contenus, la méthode addObject de la classe eZSolr sera invoqué. Ce mode de fonctionnement en plug-in permet également d'hériter des autres mécanismes natifs de la recherche eZ Publish, comme par exemple le DelayedIndexing, qui permet de déporter l'indexation (complète ou par classes) vers une tache planifiée : indexcontent.php :

[SearchSettings]
DelayedIndexing=disabled|enabled|classbased
DelayedIndexingClassList[]
DelayedIndexingClassList[]=mycontentclass

A noter : Cette technique est relativement efficace pour optimiser les temps de réponses Back Office, ou les imports de contenus régulier. Cependant, le DelayedIndexing souffre de quelques limites, puisqu'il est générique (et non optimisé spécifiquement pour eZ Find) et qu'il se contente donc de boucler sur la table 'ezpending_actions' afin d'indexer les objets un par un sans se préoccuper des autres finesses de Solr, comme par exemple l'ajout massif de contenus à indexer, suivi d'un unique 'commit'.

Etape 3 : Le fonctionnement de la méthode addObject

La méthode addObject (/search/plugins/ezsolr/ezsolr.php) reçoit :

un unique objet de contenu en paramètre
un paramètre optionnel indiquant s'il faut 'commiter' ou non le contenu ajouté (une très bonne façon d'optimiser les indexations massives de contenus)

Cette méthode agit de la façon suivante, dans les grandes lignes :

Vérification s'il faut indexer ou non le contenu, en fonction des classes exclues (settings : [IndexExclude])
Récupération des méta données de l'objet, et création des noms et valeurs des champs pour Solr
Récupération des méta données des noeuds, et création des noms et valeurs des champs pour Solr
Récupération des données des attributs de l'objet, dans chacune des langues, et création des noms et valeurs des champs pour Solr
Insertion dans l'index de Solr de l'ensemble des données collectées, en mono ou multicore selon les settings
Commit final, en fonction du paramètre optionnel de la méthode addObject

A noter : Depuis eZ Find 2.2, il est possible d'utiliser des 'cores' spécifiques à chaque langues (/extension/ezfind/java/solr.multicore), ce qui permet de dédier des index et des fichiers de configurations spécifiques à chaque langue (spellings.txt, synonmys.txt, stopwords.txt, etc.)

Etape 4 : Les nommage des champs côté Solr

Il est nécessaire de revenir sur la façon dont eZ Find nomme les champs transmis à Solr. Les principales techniques d'exploitations avancées d'eZ Find pour eZ Publish nécessitent de bien comprendre la sémantique et le mécanisme de nommage des champs.
C'est la classe /ezfind/classes/ezfsolrdocumentfieldbase.php, ou d'éventuelles classes héritées pour certains datatypes complexes (voir ma contribution ezfsolrdocumentfieldobjectrelation par exemple) qui a vocation à créer les noms des champs pour Solr, en respectant une sémantique très précise. On obtient ainsi la sémantique suivante :

Le nom des attributs :

Nom Solr : attr_[contentattributename]_[contentattributetype], exemple : 'attr_title_s'. Il faut noter l'absence de l'identifiant de la classe, ce qui ouvre des perspectives d'exploitation des attributs Solr pour filtrer plusieurs classes sur des attributs homonymes (l'objet d'un prochain billet).
Mapping dans un Fetch eZ Find (filtre par exemple) : [contentclassname]/[contentattributename]/[contentsubattributename], par exemple 'article/title'.
Le nom de la classe 'article' est utilisé comme un filtre supplémentaire lors de la construction de la requête
Le 'title' est tranformé en 'attr_title_s', le _s étant déduit de settings eZ Find (voir ci-dessous)

Le nom des métadonnées :

Nom Solr : meta_[metadataname]_[metadatatype], exemple : meta_class_identifier_s
Mapping dans un Fetch eZ Find (tri par exemple) : usage interne, par exemple pour un tri par 'class_identifier'

Le nom des sous-attributs (inexploité par défaut) :

Nom Solr : subattr_[contentattributename]-[contentsubattributename]_[contentsubattributetype], example : subattr_relatedimage-alttext_s

Nativement, les sous attributs sont peu ou pas exploités. C'est par contre un formidable outil pour étendre le fonctionnement d'eZ Find et indexer des champs supplémentaire. Voir par exemple ma contribution : ezfsolrdocumentfieldobjectrelation, qui indexe tous les attributs des objets en relations, en les stockant dans des sous attributs, ce qui permet ensuite d'effectuer toutes les opérations nécessaires sur ces sous attributs (recherche, filtre, facettes), selon la syntaxe 'myclass/myattribute/mysubattribute'. Les prochains billets détailleront comment exploiter ce mécanisme pour bien d'autres usages.

Etape 5 : La gestion des types de champs côté eZ Find

Dans les noms de champs Solr, la dernière information désigne le type de champs, et donc comment Solr va devoir considérer l'information (entre un string, un texte, une date, un tableau, etc.)
Coté eZ Find, cette définition se fait comme toujours dans les settings. Depuis eZ Find 2.2, il est maintenant possible de définir un type de champs spécifique à chaque contexte d'utilisation :

DatatypeMap[] : le setting global, s'appliquant à tous les contextes par défaut
DatatypeMapSort[] : settings spécifique pour les tris
DatatypeMapFacet[] : settings spécifique pour les facettes
DatatypeMapFilter[] : settings spécifique pour les filtres

Par exemple, par défaut, dans la version actuelle d'eZ Find 2.2, les attributs de type 'textline' sont définis différemment pour les tris :

DatatypeMap[ezstring]=text
DatatypeMapSort[ezstring]=string

L'impact au niveau de Solr, c'est que tous les attributs de type 'textline' auront systématiquement 2 champs de correspondance :

attr_title_t (utilisé pour la recherche, les facettes et les filtres)
attr_title_s (utilisé pour les tris)

A noter : il est conseillé d'utiliser également le type 'string' pour les facettes, afin de considérer le caractère espace comme un caractère lambda, et ainsi obtenir des facettes de type 'ma facette', plutôt que 'ma' et 'facette'.

Etape 6 : La gestion des types de champs côté Solr

Solr possède un fichier de configuration permettant à eZ Find de lui spécifier que le '_s' signifie un string, le '_t' un texte, etc. Il s'agit du fichier /ezfind/java/solr/conf/schema.xml
Ce fichier de configuration contient la définition d'un certain nombre de noms de champs en dur (pour les meta-données par exemple), mais définie également les correspondances pour tous les noms de champs dynamiques (nos fameux attributs de classes eZ Publish) :

<dynamicField name="*_i" type="int" indexed="true" stored="true" multiValued="true"/>
<dynamicField name="*_f" type="float" indexed="true" stored="true" multiValued="true"/>
<dynamicField name="*_d" type="double" indexed="true" stored="true" multiValued="true"/>
<dynamicField name="*_si" type="sint" indexed="true" stored="true" multiValued="true"/>
<dynamicField name="*_sf" type="sfloat" indexed="true" stored="true" multiValued="true"/>
<dynamicField name="*_sd" type="sdouble" indexed="true" stored="true" multiValued="true"/>
<dynamicField name="*_s" type="string" indexed="true" stored="true" multiValued="true" termVectors="true"/>
<dynamicField name="*_sl" type="slong" indexed="true" stored="true" multiValued="true"/>
<dynamicField name="*_l" type="long" indexed="true" stored="true" multiValued="true"/>
<dynamicField name="*_t" type="text" indexed="true" stored="true" multiValued="true" termVectors="true"/>
<dynamicField name="*_b" type="boolean" indexed="true" stored="true" multiValued="true"/>
<dynamicField name="*_dt" type="date" indexed="true" stored="true" multiValued="true"/>
<dynamicField name="*_random" type="random" indexed="true" stored="true" multiValued="true"/>
<dynamicField name="*_k" type="keyword" indexed="true" stored="true" multiValued="true"/>
<dynamicField name="*_lk" type="lckeyword" indexed="true" stored="true" multiValued="true"/>
<!-- some trie-coded dynamic fields for faster range queries -->
<dynamicField name="*_ti" type="tint" indexed="true" stored="true"/>
<dynamicField name="*_tl" type="tlong" indexed="true" stored="true"/>
<dynamicField name="*_tf" type="tfloat" indexed="true" stored="true"/>
<dynamicField name="*_td" type="tdouble" indexed="true" stored="true"/>
<dynamicField name="*_tdt" type="tdate" indexed="true" stored="true"/>
<!-- geopoint for geospatial/location searches, boosting, ... -->
<dynamicField name="*_gpt" type="geopoint" indexed="true" stored="true"/>

Ce fichier permet aussi de définir des comportements plus complexes sur certains datatypes eZ Publish, comme par exemple les mots clés (keyword). On y trouve par exemple 2 types de champs différents pour la gestion des keywords ('keyword' pour un respect de la casse et 'lckeyword' pour une casse en lowercase), qui peuvent etre exploité indifféremment au niveau d'eZ Find (DatatypeMap).

<fieldtype name="lckeyword" class="solr.TextField" positionIncrementGap="100">
 <analyzer type="index">
 <tokenizer class="solr.PatternTokenizerFactory" pattern=", *" />
 <filter class="solr.TrimFilterFactory" />
 <filter class="solr.StopFilterFactory" ignoreCase="true" words="stopwords.txt"/>
 <filter class="solr.LowerCaseFilterFactory"/>
 <filter class="solr.RemoveDuplicatesTokenFilterFactory"/>
 </analyzer>
 <analyzer type="query">
 <tokenizer class="solr.PatternTokenizerFactory" pattern=", *" />
 <filter class="solr.TrimFilterFactory" />
 <filter class="solr.SynonymFilterFactory" synonyms="synonyms.txt" ignoreCase="true" expand="true"/>
 <filter class="solr.StopFilterFactory" ignoreCase="true" words="stopwords.txt"/>
 <filter class="solr.LowerCaseFilterFactory"/>
 <filter class="solr.RemoveDuplicatesTokenFilterFactory"/>
 </analyzer>
</fieldtype>

La définition des keywords est riche d'enseignement sur la configuration de Solr. On peut observer le fonctionnement des appels des filtres Solr, et comment sont traités les séparations de mots par des virgules (PatternTokenizerFactory), la gestion de la casse (LowerCaseFilterFactory), ou encore la suppression des doublons (RemoveDuplicatesTokenFilterFactory), etc.

eZ Find et ses utilisations alternatives : Faire un nuage de tags

Mon, 22 Feb 2010 23:11:18 +0000

eZ Find est une extension native d'eZ Publish, maintenant disponible dans les diverses installations du CMS. Mon précédent billet donne une courte définition du fonctionnement d'eZ Find, de son couplage avec Solr, et de sa relation avec les datatypes.

eZ Find est généralement présenté et vendu comme un moteur de recherche, et les utilisateurs (et développeurs) peuvent donc s'attendre à un mécanisme du type :

Je saisie une expression libre
J'envoie ma recherche
J'obtiens une liste de résultat, et j'applique quelques tris (alphabétique, dates, pertinence) et quelques filtres disponibles (par rubriques, par facettes, etc.)

Cependant, le cadre d'exploitation d'eZ Find est plus vaste que ce schéma fonctionnel. Ce billet décrit un cas d'utilisation certes relativement inutile mais signification d'une utilisation alternative d'eZ Find : construire un nuage de tags.

A partir d'un exemple simple, on peut facilement en déduire d'autres cas d'utilisation qui facilitent énormément le développement de certains projets, comme par exemple les agrégateurs de contenus, les portails et autres mécanismes de navigations complexes dans un catalogue.

Comment construire un nuage de tags sur eZ Publish ?

La seule méthode un peu optimisée et fonctionnelle de procéder actuellement est l'utilisation d'un opérateur de template qui explore la base de données, et notamment la table ezkeyword. Le package ezwebin propose l'opérateur eztagcloud, qui est facile à déployer et à utiliser.

Voici un exemple d'appel de l'opérateur dans un template

<div>
   {eztagcloud( hash( 'class_identifier', 'billet', 'parent_node_id', 2 ) )}
</div>

Voici le code de l'opérateur eztagcloud
Voici le code du template tagcloud.tpl associé à l'opérateur (que l'on peut donc surcharger)

Avantages de l'opérateur

Les fonctions fetch natives ne permettent pas de lister un ensemble de keywords en fonction des paramètres utiles (subtree, classes, etc.), c'est donc la seule façon "économique" et "optimisée" de procéder. Les opérateurs permettent souvent aux développeurs eZ Publish avancés d'optimiser certains traitements, en économisant le nombre de requêtes SQL par exemple, ou en facilitant certains algorithmes laborieux à transposer avec le langage de template (par exemple le calcul des pourcentages des styles CSS inline dans cet opérateur)

Inconvénients de l'opérateur

L'écriture de ce type d'opérateur est peu accessible aux développeurs occasionnels, et la manipulation du SQL est une pratique dangereuse si le modèle de données eZ Publish est mal maîtrisé (prise en compte des versions, des visibilités, des langues, des droits...). Par ailleurs cet opérateur encapsule la logique algorithmique du calcul des pourcentages transmis au "font-size" en style inline. Les amoureux du CSS full externe, ou de l'accessibilité devront donc adapter cet opérateur à leur besoin.

Comment construire un nuage de tags avec eZ Find ?

Comprendre le concept de facettes

Derrière ce terme "géométrique" se cache un concept finalement assez simple et naturel, que l'on pourrait appeler : "groupement des résultats pour un champs", à savoir :

Supposons qu'un résultat de recherche contienne 100 billets
Sur ces 100 billets, on peut lister 20 mots clés distincts associés
Parmi ces 20 mots clés, le mot clés A est associé à 10 billets, le mot clés B est associé à 5 billets, et ainsi dessuite

On peut transposer cet exemple sur tous les attributs et meta données d'une classe (name, dates, auteur, attribut quelconque), et même obtenir N listes de facettes sur N attributs et méta différents

Construite le nuage de mots clés avec des facettes

Cet exemple de code montre comment construire sa requête eZ Find, récupérer les facettes résultantes sur l'attribut "tags" de type "keywords", et gérer le poids des keywords en fonction d'un algorithme simplifié (j'ai un peu triché sur cet aspect, puisque ce n'est pas l'objet de la démonstration).

{def $search_keywords=fetch( ezfind , search,
      hash( query , '',
        'facet', array( 
            hash('field', 'billet/tags', 'sort', 'alpha', 'limit', 100 )),
        'class_id', array('billet'),
        'filter', array('not', 'billet/tags:""'),
        'subtree_array', array(2)
        ))}
    
{def $search_extras_keywords=$search_keywords['SearchExtras']}
{def $search_count_keywords=$search_keywords['SearchCount']}
 
<li id="blog_block_{$bloc_count}" class="colonne_block">
   <h1>Tags ezfind :</h1>
    
    <div class="tagclouds {$current_css}">
    {foreach $search_extras_keywords.facet_fields[0].nameList as $facetID =&gt; $name}
                
        {def $keyword_count = $search_extras_keywords.facet_fields[0].countList[$facetID]}
        {def $percent = $keyword_count|div( $search_count_keywords )|mul( 200 )|floor|sum( 100 ) }
            <a href={concat( $root_blog_node.url_alias, '/(tag)/', $name )|ezurl()} style="font-size: {$percent}%" title="{$keyword_count} billets taggés '{$name}' // ">{$name|wash()}</a>, 
        {undef $percent}
 
    {/foreach}
 
    </div>
</li>
{undef $search_extras_keywords $search_keywords $search_count_keywords}

Quelques astuces & clés de compréhensions

La recherche sur une chaine vide (query , '') est une technique permettant d'explorer l'ensemble des contenus indexés, en appliquant uniquement les filtres et limitations utiles (class_id, subtree_array par exemple)
L'opérateur 'NOT' n'est pas natif et nécessite un petit 'hack' proposé par Bruce Morrison, qui sera sans doute disponible dans les futures versions d'eZ Find
Par défaut les facettes sur des datatypes 'keywords' sont présentés en minuscule. Ce n'est pas un bug, mais une fonctionnalité visant à homogénéiser la casse sur les syntaxes similaires (eZ Publish, ez Publish, Ez Publish, etc.). Cependant lorsqu'on est confiant dans la qualité de sa saisie (puisqu'on utilise une extension d'autocomplétion par exemple), il peut être souhaitable de ne pas forcer l'utilisation du minuscule. Pour cela il faut désactiver le filtre solr.LowerCaseFilterFactory dans le fichier /extension/ezfind/java/solr/conf/schema.xml

<!-- eZ Find: This field type is dedicated to ez publish keywords.  --> 
<fieldtype name="keyword" class="solr.TextField" positionIncrementGap="100"> 
     <analyzer type="index"> 
       <tokenizer class="solr.PatternTokenizerFactory" pattern=", *" /> 
       <filter class="solr.TrimFilterFactory" />               
       <filter class="solr.StopFilterFactory" ignoreCase="true" words="stopwords.txt"/> 
       <!--<filter class="solr.LowerCaseFilterFactory"/>--> 
       <filter class="solr.RemoveDuplicatesTokenFilterFactory"/> 
     </analyzer> 
     <analyzer type="query"> 
       <tokenizer class="solr.PatternTokenizerFactory" pattern=", *" /> 
       <filter class="solr.TrimFilterFactory" /> 
       <filter class="solr.SynonymFilterFactory" synonyms="synonyms.txt" ignoreCase="true" expand="true"/> 
       <filter class="solr.StopFilterFactory" ignoreCase="true" words="stopwords.txt"/> 
       <filter class="solr.LowerCaseFilterFactory"/> 
       <filter class="solr.RemoveDuplicatesTokenFilterFactory"/> 
     </analyzer> 
</fieldtype>

My gandbox.fr's slides talk from the 2010 eZ Community Day in Geneva

Sun, 24 Jan 2010 21:08:13 +0000

On 2010 January 21, for the eZ Community Day in Geneva, i tried to tanslate in english language some of my "french" blog posts i write on http://www.gandbox.fr. There is my "english" slides from this talk :

List of the french blog post i used for my talk

Working with Google Maps :

Ma cave sur eZ Publish : Google Maps (Partie 3)

Building an UWA Widget (Netvibes / iGoogle) :

Building a custom RSS :

Un flux RSS par Keyword (ou autre) sur eZ Publish

Slideshare presentation

eZ Find et la gestion des datatypes

Wed, 13 Jan 2010 21:33:06 +0000

J'ai publié une "mini" contribution sur la gestion des relations d'objet(s) dans eZ Find. Cette contribution est relativement confidentielle (exploitation marginale), mais constitue une bonne occasion pour présenter le fonctionnement d'eZ Find et sa relation avec les datatypes. eZ Find est une extension encore sous exploitée, alors qu'elle constitue une avancée majeure d'eZ Publish sur la cible "système d'information professionnel", au côté des extensions EZSI ou encore CMIS.

Voir la page du projet ezfsolrdocumentfieldobjectrelation

eZ Find en quelques mots "faciles à comprendre"

eZ Find est une "interface" entre eZ Publish (le CMS) et Solr (le moteur de recherche)
Solr est un moteur de recherche autonome, qui s'exécute comme un service JAVA, et qui fonctionne en mode REST, à savoir :
- Lors d'une publication, eZ Find prépare le contenu dans une URL et le "pousse" vers Solr (HTTP)
- Lors d'une recherche (full text, filtres, facettes), eZ Find prépare la question dans une URL et demande à eZ Find la réponse

Toutes ces opérations complexes sont "masquées" pour le développeur, qui doit uniquement se soucier de bien formuler ses requêtes dans son habituel langage de template : fecth( ezfind, search, params...). La puissance d'eZ Find réside dans cette simplicité d'exploitation, au profit de le puissance fonctionnelle de Solr et des "questions" que l'on peut formuler, notamment sur la pertinence (façon google) ou sur les classifications à facettes.

eZ Find est les datatypes

eZ Publish fonctionne sur le concept de "datatype", à savoir des types de données "riches" permettant de représenter des lignes de textes, des numériques, des dates, mais aussi des types de données plus complexes ou exotiques comme des images, des vidéos, des relations d'objet(s) ou de la géolocalisation. eZ Publish permet également de définir ses propres datatypes, on peut donc comprendre que les correspondances entre les types de données eZ Publish et les types de données Solr nécessite quelques paramétrages, selon 2 cas de figures :

Les correspondances de données parfaitement symétriques : ligne de texte = string
Les correspondances de données "sur mesure" : relations d'objets (et gestion des sous attributs)

Pour définir ces correspondances eZ Find propose un fichier de paramétrage extension/ezfind/settings/ezfind.ini

Fonctionnement de la classe ezfSolrDocumentFieldObjectRelation

L'aspect "sur mesure" de la correspondance entre les datatypes eZ Publish et les types de données eZ Find implique un "point de vue" de développement dans la façon de gérer les cas particuliers et complexes. L'indexation des relations d'objets multiples est une bonne illustration de l'éternel dilemme du développeur : "jusqu'où faut-il aller ?"

Comportement natif de ezfSolrDocumentFieldObjectRelation

Tous les objets en relation permettent de générer un unique champs "text" par concaténation de tous les attributs de tous les objets. On obtient ainsi un contenu indexé de type "objet1/attribut1 objet1/attribut2 objet2/attribut1 objet2/attribut2". Cette logique est tout à fait adaptée à la recherche "full text", mais inadaptée à l'exploitation de facette. Pour un objet en relation dont le "name" est "mon objet en relation", on obtient les facettes suivantes sur "myclass/myattribute" :

"mon" (10 résultats)
"objet" (3 résultats)
"en" (30 résultats)
"relation" (5 résultats)

Comportement de l'évolution ezfSolrDocumentFieldObjectRelation

La gestion des facettes devient possible, en spécifiant un attribut en particulier ou alors en invoquant le "name". La page du projet montre quelques exemples de codes basiques. En exploitant l'exemple précédent, on obtient alors l'unique facette suivante :

"mon objet en relation" (3 résultats)

Gestion des filtres de type string

Un fois les facettes générées, il est nécessaire de construire le lien permettant de filtrer les résultats par "mon objet en relation". eZ Find (ou plutôt Solr) exige logiquement que les chaînes de caractères (string) soient encapsulées par des "doubles côtes".

Cet extrait de code (un peu complexe) montre comment étendre le search.tpl pour générer des filtres pour les chaînes de caractères : filtres par "text line", "keywords" ou "relation d'objet(s)"

{foreach $search_extras.facet_fields[$index].nameList as $facetID =&gt; $name}
  {if $name|trim|count_chars|gt(0)}
    <li>
      {if $search_extras.facet_fields[$index].field|compare('facet_fields')}
       {def $url_link = concat($search_extras.facet_fields[$index].queryLimit[$facetID]|explode(':').0,':"',$name|urlencode,'"')}
      {else}
       {def $url_link = $search_extras.facet_fields[$index].queryLimit[$facetID]|wash}
      {/if}
      <a title="{$search_extras.facet_fields[$index].countList[$facetID]} Réponse(s) trouvée(s) dans les '{$name|wash}' // " href={concat( $baseURI, '&facet_field=', $facetField|wash, '&filter[]=', $url_link )|ezurl}>{$name|wash}</a> ({$search_extras.facet_fields[$index].countList[$facetID]})
      {undef $url_link}
    </li>
  {/if}
{/foreach}

A noter : L'opérateur urlencode n'est pas natif (fonction PHP) et doit être déclaré dans template.ini.append.php :

PHPOperatorList[urlencode]=urlencode

Faire de l'édition frontale AJAX avec eZ Publish & Mootools (Partie 3)

Wed, 07 Oct 2009 21:23:50 +0000

Pour terminer cette série de billet (voir la partie 1 et la partie 2) concernant l'édition frontal AJAX sur eZ Publish, voici des extraits de code et quelques détails de fonctionnement concernant ce qui n'est pas encore décrit à ce stade, à savoir :

La génération de masques de saisie en mootools (mes fameux custom captions)
La couche eZ Publish et la mise à jour des données

Les custom captions en Mootools

Comme vue dans le précédent billet, la déclaration de la classe ajaxwebin nécessite de renseigner la propriété caption par l'instance d'une classe spécifique permettant de générer le masque de saisie attendu sur clic d'une zone éditable, comme par exemple :

Instance d'une classe pour une liste déroulante

new ajaxcaptionsSelect({  
 'minValue': 0,
 'maxValue': 12,
 'setStyles': {margin: '0 -10px', border: '1px dotted #000', background: '#ffffdd'}
}))

Instance d'une classe pour un champs de saisie

new ajaxcaptionsInput({  
 'setStyles': {border: '1px dotted #000', background: '#ffffdd'}
})

Définition de la superclasse et des classes hérités

J'aurais pu exploiter diverses techniques pour définir une superclasse ajaxcaptions et ses classes dérivées ajaxcaptionSelect et ajaxcaptionsInput, comme par exemple l'utilisation du mécanisme de prototype du langage JavaScript. J'ai opté pour le plus scolaire implement, qui reste le plus facile à manipuler dans l'esprit de mootools.

Le principe est trivial, il s'agit de déclarer une classe, en spécifiant que l'ensemble des propriétés et des méthodes d'une autre classe sont à dupliquer. Rien n'empêche par la suite d'exploiter ou de mixer dans l'exécution du code des évolutions du prototype des objets, ou encore d'invoquer à nouveau la méthode implement dynamiquement.

Ce formalisme a pour avantage d'être facilement compréhensible (assez scolaire), et facilement extensible :

// Classe abstraite de génération d'éléments xHTML
var ajaxcaptions = new Class({
    
    Implements: [Options],
 
    options: {
     minValue: 0,
     maxValue: 0,
     setStyles: null,
     myElement: null
    },
    
    // Constructeur de la classe
    initialize: function(options) {
     this.setOptions(options);
     this.process();
    },
    
    // Retourne le caption
    getElement: function() {
      return this.options.myElement;
    }
        
});
 
// Classe de génération xHTML d'un 'select-one', contenant des valeurs de minValue à maxValue
var ajaxcaptionsSelect = new Class({
    
    Implements: ajaxcaptions,
    
    process: function() {
 
      var myElement;
      myElement = new Element('select');
      myElement.setStyles(this.options.setStyles);
      
      for (i=this.options.minValue; i<=this.options.maxValue; i++)
      {
 myElement.adopt(new Element('option').set('text', i));
      }
      
      this.options.myElement = myElement;
    },
    
    getValue: function() {
      return this.options.myElement.selectedIndex;
    },
    
    setValue: function(value) {
      this.options.myElement.selectedIndex = value;
    }
     
});
 
// Classe de génération xHTML d'un 'input'
var ajaxcaptionsInput = new Class({
    
    Implements: ajaxcaptions,
    
    process: function() {
 
      var myElement;
      myElement = new Element('input');
      myElement.setStyles(this.options.setStyles);
 
      this.options.myElement = myElement;
    },
    
    getValue: function() {
      return this.options.myElement.value;
    },
    
    setValue: function(value) {
      this.options.myElement.value = value;
    }
     
});

La couche eZ Publish de mise à jour des données

Comme décrit dans le précédent billet, l'appel des URL eZ Publish correspond au motif suivant : /ajaxwebin/action/[attribute_id]/[object_id]/[value] :

var url = this.options.ajaxmodule + '/' + this.options.attributeID + '/' + object_id + '/' + value;

ajaxmodule est spécifié en dur dans l'instance des classes mootools, et correspond à la racine du module, par exemple : /ajaxwebin/action
attributeID est spécifié en dur dans l'instance des classes mootools, et correspond à l'identifiant eZ Publish du champ à modifier, par exemple stock ou title
object_id est fixé dynamiquement dans les classes CSS, et permet de transmettre l'identifiant (objet_id) de l'objet eZ Publish à modifier
value correspond à la valeur à appliquer lors de la modification

L'implémentation du module eZ Publish

Je ne reviendrai pas sur l'implémentation du module qui est déjà abordé en détail sur plusieurs articles, comme par exemple le tutoriel de module d'eZPedia.

Quelques précisions concernant le code

La méthode de modification est la plus classique, mais il aurait été possible d'utiliser la méthode fromString (voir le billet de Mox), ou encore l'expérimental kernelwrapper et sa classe ezpObject (mais ce sera pour un prochain billet)
A noter : L'utilisation de la méthode clearObjectViewCache, qui permet de forcer le rafraîchissement de tous les caches impactés par la modification de l'objet (selon les différentes directives, dont le Smartviewcache)

Code du module eZ Publish de modification de l'objet

<?php
$Module = $Params["Module"];
 
if ( isset( $Params['action'] ) ) {
 $action = $Params['action'];
} else {
 $action = '';
}
 
if ( isset( $Params['object'] ) ) {
 $object_id = $Params['object'];
} else {
 $object_id = null;
}
 
if ( isset( $Params['value'] ) ) {
 $value = $Params['value'];
} else {
 $value = null;
}
 
$Result = array();
$Result['path'] = array();
$Result['pagelayout'] = array();
$Result['content'] = '';
 
if ($action != '') {
 
  if ( (!is_null($object_id)) && (!is_null($value)) ) {
 
    $object = eZContentObject::fetch( $object_id );
 
    if ($object) {
      $data_map = $object->attribute( 'data_map' );
 
      if (isset($data_map[$action])) {
       $attribute = $data_map[$action];
 
       switch ($data_map[$action]->DataTypeString) {
        case 'ezinteger':
          $attribute->setAttribute('data_int', $value);
  
          break;
        case 'ezstring':
          $attribute->setAttribute('data_text', $value);
  
          break;
       }
   
       $attribute->sync();
       eZContentCacheManager::clearObjectViewCache( $object_id );
       
       echo $value;
      }
      else {
       echo '';
      }
 
    }
    else {
      echo '';
    }
 
  }
 
  eZDB::checkTransactionCounter();
  eZExecution::cleanExit();
 
} 
else {
  echo '';
}
 
?>

Faire de l'édition frontale AJAX avec eZ Publish & Mootools (Partie 2)

Sun, 27 Sep 2009 20:12:15 +0000

Ce billet décrit pas à pas le développement de l'édition frontale dont le fonctionnement est visible sur la vidéo du précédent billet (principe du cliquer / éditer). Le framework JavaScript utilisé est Mootools, dont le fonctionnement est tout à fait similaire à ses principaux concurrents, à savoir : jQuery, Prototype & Script.aculo.us, YUI, Dojo, etc.

Pour ceux qui n'ont jamais utilisés un framework JavaScript, j'en profite pour introduire les objectifs et les fonctionnalités de base que l'on peut trouver dans tous ces frameworks, sans pour autant vous aider à faire un choix... Les critères de choix d'un framework dépendent de bien d'autres critères que leur simple capacités individuelles, comme par exemple :

Eviter la multiplication des frameworks sur un même site (ce que l'on constate malheureusement un peu partout)
Rester dans la logique de dépendance d'un framework et de son environnement de développement (YUI pour eZ Publish, Dojo pour Zend, Prototype pour Symfony, etc.)
Maîtriser un framework correctement, plutôt que 3 frameworks passablement

Introduction aux FrameWorks JavaScript

Un framework JavaScript est écrit en JavaScript, et n'est donc pas plus puissant que le langage lui même. Il s'agit seulement d'un ensemble de librairies et d'extensions du modèle objet qui facilitent l'écriture du code, notamment pour :

Manipuler le DOM (atteindre, ajouter, modifier ou supprimer des balises et des attributs dans la page)
Manipuler les évènements (évènements de la souris, du clavier)
Automatiser des effets complexes (effets de fondus, de Drag & Drop, etc.)
Faciliter les appels et traitements AJAX
Faciliter la POO, en proposant une syntaxe plus familière (classes, héritage)
Masquer certaines incompatibilités de navigateurs

La popularisation de ces frameworks a permis de démocratiser un modèle objet de manipulation du DOM, ainsi qu'une syntaxe grammaticale de sélection de noeuds déclinée du CSS3 Selector (dont voici une liste d'exemple en forme de benchmark pro-Mootools) bien plus lisible et compréhensible que l'API DOM & XPATH du W3C, ce qui génère d'ailleurs des initiatives de portage hors JavaScript comme par exemple : http://code.google.com/p/phpquery/

Spécification de la classe Mootools ajaxwebin

Cette classe a pour vocation de déclarer et d'exécuter le comportement de type "cliquer / éditer" sur un ensemble d'éléments similaires dans la page, comme par exemple :

Cas 1 : Remplacer sur clic toutes les balises A contenant une classe CSS 'cuvee_invert', par un champs de saisie
Cas 2 : Remplacer sur clic toutes les balises A, positionnées sous une balise TD et contenant une classe CSS commençant par 'stock_', par une liste de déroulante de 1 à 10

Prérequis dans le xHTML :

Les xHTML propulsés doivent être préparés pour faciliter l'identification des éléments éditables, et des correspondances entre les objets et les attributs cibles. Le motif xHTML est la suivante :

<HTMLElement id="rootID_ContentObjectID" class="MatchName" />

Par exemple concernant le cas 1 :

<a class="cuvee_invert" id="cuveename_2224"></a>

Par exemple concernant le cas 2 :

<td class="td80 stock_3" id="stock_2254"><a href="#">3</a></td>

Voici la liste des paramètres et leurs rôles respectifs :

ajaxmodule (obligatoire) : Racine du module eZ Publish : ajaxmodule/attributeID/objectID/value
parentMatch (obligatoire) : Syntaxe CSS3 (transmise en l'état à Mootools dans un sélecteur) qui permet d'atteindre tous les éléments impactés par l'édition frontale
targetMatch (optionnel) : Balise optionnelle à atteindre, comme enfant des éléments résultat du parentMatch (permet par exemple d'atteindre les balises A, enfants des balises TD)
styleMatch (optionnel) : Permet de définir un style CSS pour faciliter l'identification des éléments éditables dans la page (bordures, couleurs)
rootID (obligatoire) : <HTMLElement id="rootID_ContentObjectID" class="MatchName" />
attributeID (obligatoire) : Permet de transmettre le paramètre dans l'URL ajaxmodule/attributeID/objectID/value
caption (obligatoire) : Permet d'affecter le masque de saisie personnalisé sur clic, détaillé dans le prochain billet

Instanciation des objets de la classe Mootools ajaxwebin

A noter : les objets instanciés dans la propriété 'caption' seront décrits dans le prochain billet

window.addEvent('domready', function() {
 
    var myajaxwebin = new Array();
    
    // Ajout de la gestion des stocks
    myajaxwebin.push( new ajaxwebin({  
     ajaxmodule: '/ajaxwebin/action',
     parentMatch: 'td[class*="stock_"]',
     targetMatch: 'a',
     styleMatch: {border: '1px dotted #ff0000', background: '#ffffdd'},
     rootID: 'stock_',
     attributeID: 'stock',
     caption: (
        new ajaxcaptionsSelect({  
            'minValue': 0,
            'maxValue': 12,
            'setStyles': {margin: '0 -10px', border: '1px dotted #000', background: '#ffffdd'}
        }))
    }));
    
    // Ajout de la gestion des title des cuvées
    myajaxwebin.push( new ajaxwebin({  
     ajaxmodule: '/ajaxwebin/action',
     parentMatch: 'a[class="cuvee_invert"]',
     styleMatch: {border: '1px dotted #ff0000', background: '#ffffdd'},
     rootID: 'cuveename_',
     attributeID: 'title',
     caption: (
        new ajaxcaptionsInput({  
            'setStyles': {border: '1px dotted #000', background: '#ffffdd'}
        }))
    }));
 
});

Code commenté de la classe Mootools ajaxwebin

Il est difficile d'expliquer et de décrire l'ensemble du code. Les commentaires devraient être suffisants quant à la compréhension des mécanismes. Cependant voici quelques éléments clés de compréhension :

Voir la documentation des classes sur Mootools, et notamment l'utilisation du setOptions
Voir la documentation sur bind qui est essentielle à la construction des mécanismes qui mixent la construction dynamique du DOM et l'ajout dynamique d'évènements. Cette méthode permet de modifier la portée du this, pour définir quelle est la valeur du this dans l'exécution des évènements (clics ou autres)

var ajaxwebin = new Class({
    
    Implements: [Options],
 
    options: {
       ajaxmodule: null,
       parentMatch: null,
       targetMatch: null,
       styleMatch: null,
       rootID: null,
       attributeID:null,
       caption:null,
       currentselected:null,                
       currentID:null,
       targetElement:null
    },
    
    initialize: function(options) {
       this.setOptions(options);
       this.process();
    },
    
    // Appel AJAX au module eZ Publish, et Mise à jour de l'élément en fonction de la valeur retournée
    updateAJAX: function(value) {
      var object_id = this.options.currentID;
      
      // Définition de l'URL du module eZ Publish
      var url = this.options.ajaxmodule + '/' + this.options.attributeID + '/' + object_id + '/' + value;
      
      new Request({
       method: 'get',
       url: url,
       
       onSuccess: function(responseText, responseXML) {    
        this.options.targetElement.set('html', responseText);
       }.bind(this)
      }).send();
    },
    
    // Supprime le caption généré
    disposeCaption: function() {
       this.options.targetElement.setStyle('display', '');
       this.options.currentselected = null;
       this.options.caption.getElement().dispose();
    },
    
    //Remplace la zone cible par le caption attendu
    setCaption: function(element) {
       var currentselected = this.options.currentselected;
       
       this.options.currentID = element.getProperty('id').replace(this.options.rootID, '');
       this.options.attributeID = this.options.attributeID;
  
 if (currentselected != element) 
 {
 
   //Vérfie si une balise cible enfant a été définie, sinon exploite la balise courante
   this.options.targetElement = (this.options.targetMatch) ? element.getElement(this.options.targetMatch) : element;
   
   // On restore l'élément précent, si 'change' ou 'blur' non provoqué 
   if (currentselected) {
      var restore_selected = (this.options.targetMatch) ? currentselected.getElement(this.options.targetMatch) : currentselected;
    restore_selected.setStyle('display', '');
   }
   
   //On rend invisible l'élement cible, pour pouvoir le remplacer  
   this.options.targetElement.setStyle('display', 'none');
   
   //On affecte le caption xHTML généré avec la valeur de la page
   this.options.caption.setValue( this.options.targetElement.get('text') );
   
   //On supprime les évènements, par sécurité
   this.options.caption.getElement().removeEvents();
   
   //On affecte les évènements génériques à tous les captions xHTML
   this.options.caption.getElement().addEvents({
   'change': function() { //Sur changement, on update les données 
    var value = this.options.caption.getValue();
    this.updateAJAX(value);
    
    this.disposeCaption()
    
   }.bind(this),
   'blur': function() { //Sur perte du focus 
      this.disposeCaption()
   }.bind(this)
  });
   
   //On injecte le caption après l'élément cible
   this.options.caption.getElement().inject(this.options.targetElement, 'after');
   
   this.options.currentselected = element;
 
 }
 
    },
    
    process: function() {
      //Recherche tous les éléments selon le motif parentMatch, et boucle sur les résultats
      $$(this.options.parentMatch).each(function(element, index) {
   
     var elementID = element.getProperty('id');
     //Teste si les éléments possèdents des ID
     if (elementID && (elementID.indexOf(this.options.rootID)) == 0) {
     
     //Neutralise les liens <a>, pour faciliter l'insertion des captions
     if (element.getProperty('href')) element.setProperty('href', 'javascript:void(0)');;
     
     element.getElements('a').each(function(element_a) {
     element_a.setProperty('href', 'javascript:void(0)');
     });
     
     //Ajoute l'évènement de clic sur tous les éléments matché
     element.addEvents({
   'click': function() {
    this.setCaption(element);
    
   }.bind(this)
  });
     element.setStyles(this.options.styleMatch);
   }
   
      }.bind(this));
 
    }
});

Faire de l'édition frontale AJAX avec eZ Publish & Mootools (Partie 1)

Sun, 20 Sep 2009 20:05:30 +0000

La rubrique ma cave est certes un bon prétexte à la rédaction d'articles techniques sur eZ Publish, mais il s'agit également de la seule information numérique à jour concernant mes stocks de vins. Le volume des entrées / sorties est relativement important (si si !) et cette mise à jour des stocks est rapidement devenue un calvaire. La recherche d'une bonne solution de feignant m'a permis de tester l'édition frontale sur eZ Publish, et surtout d'expérimenter un mécanisme de mise à jour plus immédiat en AJAX du type : "cliquer / éditer".

J'en profite pour rédiger une série de billets détaillant :

Le fonctionnement et les limites de l'édition frontale standard
La programmation orientée objet en JavaScript avec Mootools
La mise à jour de contenus eZ Publish via AJAX

La classique édition frontale eZ Publish et ses limites

L'édition frontale est le mécanisme le plus exploité pour promouvoir les CMS (eZ Publish, Drupal ou autres), ce qui est relativement paradoxal, puisqu'au final il s'agit du mécanisme le moins exploité par les Webmasters sur les sites en productions. Ce constat s'explique assez bien, pour plusieurs raisons que je détaille par la suite.

Pourquoi si peu de sites exploitent l'édition frontale ?

La logique ergonomique de l'édition frontale est des plus simple : je navigue sur mon site, et une barre d'édition me permet :

d'éditer l'objet que je suis en train de visionner (sa vue 'full')
d'ajouter un objet de contenu positionné "en dessous" de l'objet que je suis en train de visionner
quelques autres actions classiques comme 'déplacer', 'ajouter des emplacements', 'supprimer', etc.

Donc la capacité d'éditer (ou non) un contenu dépend de la capacité d'atteindre une page dont le contenu principal est le contenu à éditer (vue full), ce qui se complique fortement dès qu'il s'agit d'une liste de commentaires (généralement empilés, sans affichage individuel), d'un utilisateur, d'un contenu associé à partir de la médiathèque (image), d'un contenu non représenté dans l'arborescence de l'internaute (divers dossiers de rangement), d'un contenu masqué ou supprimé, etc..

Les Webmasters vont donc devoir naviguer entre l'édition frontale et le Back Office, ce qui finalement se résume assez vite à l'utilisation exclusive du Back Office.

Il faut aussi ajouter que les front-end des sites sont très variés dans leur logique de navigation, et parfois graphiquement inadaptés à l'inclusion de formulaires d'édition. Pour pouvoir profiter d'une édition frontale efficace, il faut en quelque sorte organiser le contenu en conséquence, ce qui cependant fonctionne positivement sur certains types de publications, comme les Blogs ou les contenus arborescences (catalogues, référentiels).

Pourquoi vendre un CMS à l'aide de l'édition frontale ?

Les acheteurs des solutions Web sont rarement les utilisateurs finaux, et il faut donc les séduire avec des mécanismes percutants et rassurants tels que l'édition frontale, l'upload massif (voir ezmultiupload), ou l'importation directe à partir de Word (voir ezwordtoolbar) ou Open Office (extension native ezodf). Généralement un CMS succède à du DreamWeaver (fabrication HTML frontale) ou du PHP maison (bricolé, insécure, mais libre d'action), il faut donc insister sur des mécanismes qui ne suppriment pas définitivement des conforts de fabrication durement acquis au fil du temps...

Installation d'une édition frontale sur eZ Publish

De nombreux articles détaillent déjà l'installation de l'édition frontale (que l'on trouve par défaut lors de l'installation des packages ezwebin ou ezflow), comme par exemple :

L'article sur ezpedia
L'article sur pwet

Il est à noter qu'une nouvelle extension ezwebsitetoolbar (code extrait de ezwebin) permet d'intégrer une barre d'édition frontale sans transporter l'ensemble de l'extension ezwebin.

L'interface de mise à jour des stocks ?

En posant le problème, l'idéal ergonomique pour cette mise à jour fréquente est finalement de pouvoir cliquer et éditer le stock directement dans la page quel que soit la page affichée (les listes de cuvées résumées, les tableaux de stocks, les fiches détaillées, etc.). Ce mécanisme est particulièrement efficace pour des mises à jour multiples sur des affichages en tableaux (vue d'ensemble).

Voici un exemple en vidéo, qui montre en image :

Un exemple de boite de connexion frontale
Un exemple de mise à jour du stock par l'édition frontale standard
Un exemple de mise à jour du stock par un développement spécifique, permettant le "cliquer / éditer" en AJAX avec Mootools
Ce même mécanisme décliné pour mettre à jour les noms des cuvées (je modifie souvent l'année dans le nom des cuvées)

Les prochains billets détailleront pas à pas le développement d'une telle extension.