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

• Publié le 23 Mai 2010
• 0 commentaire(s)
• Catégorie : Technologies Web

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.

• Tags :
• eZ Conference
• eZ Find
• eZ Publish