sdx-developers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE : RE : [sdx-developers] SearchTransformer..un peu d'aide


From: Frédéric Glorieux
Subject: RE : RE : [sdx-developers] SearchTransformer..un peu d'aide
Date: Sun, 14 Sep 2003 00:17:29 +0200

> [snip] [snip] [snip] [snip] [snip] [snip] [snip] [snip] [snip] [snip] 
> [snip] [snip] [snip] [snip] [snip] [snip] [snip] [snip] [snip] [snip] 
> [snip] [snip] [snip] [snip] [snip] [snip] [snip] [snip] [snip] [snip] 
> [snip] [snip] [snip] [snip] [snip] [snip] [snip] [snip] [snip] [snip] 
> [snip] [snip] [snip] [snip] [snip] [snip] [snip] [snip] [snip] [snip] 
> [snip] [snip] [snip] [snip] [snip] [snip] [snip] [snip] [snip] [snip] 
> [snip] [snip] [snip] [snip] [snip] [snip] [snip] [snip] [snip] [snip] 
> [snip] [snip] [snip] [snip] [snip] [snip] [snip] [snip] [snip] [snip] 
> [snip] [snip] [snip] [snip] [snip] [snip] [snip] [snip] [snip] [snip]

> donc votre idée c'est : on met des balises vides qui se 
> rempliront ..quel est l'interet ? Cette pratique dans les 
> transformer n'est pas spécialement connue ..mais bon peut 
> être y'a til un intêret qui m'echappe ?

Peu importe votre syntaxe d'entrée, c'était juste une proposition. Faire
marcher est généralement possible, faire utiliser (comprendre et
documenter) est un autre problème. La proposition que j'émettais tenait
juste ce cette intention, ne pas multiplier les vocabulaires.

Nous sommes plusieurs à vouloir faire passer plus de fonctionnalités de
SDX en composants cocoon. L'intérêt que j'y vois serait d'attirer une
communauté qui pense son application en termes de sitemap. Ce public est
probablement plus rare que les développeurs comprenant la logique d'une
page serveur. Mais cela ne fait pas de mal de réfléchir avec des
concepts plus avancés.

        Cependant, je me demande ce qu'apporte un générateur sitemap de
résultats par rapport à une page xsp du type de celles qui sont mises
dans la dite "api-url". En réalité, chacun gagne à concevoir ses
applications avec cette sorte de requêtes un peu génériques qu'il
interroge via une xsl, ou avec du xinclude, pour s'agréger son xml avant
transoformation finale.
        L'apport pourrait venir d'un transformeur. J'imaginais (rêvais
?), que le résultat d'une URL puisse se composer en séparant mieux les
étapes. L'API-XSP de SDX souffre d'une inflation de syntaxe, de
paramètres de toute sorte, tant et si bien que parfois (du moins cela
m'est arrivé), il est parfois plus facile de contrôler soi-même ses
paramètres en java. Il arrive ainsi (mauvais design?) que l'on aboutisse
à ce qu'une même url (= une même page xsp), fasse parfois une requête
parsée, une requête champ, ou une requête complexe, selon des valeurs de
paramètres. C'est rendu là que je me demande, si ce ne serait pas plus
simple de composer une requête en XML (à transformer), que de multiplier
les accès à la syntaxe pour passer des paramètres.
        Cependant, il y a des problèmes beaucoup plus difficiles à
surmonter que posait Razik.

> A)La requête avec les tris, filtres, etc. (pas très 
> difficile, mais il faut inventer une nouvelle syntaxe à parer 
> (en SAX) et créer des objet en java :( ) 

Ici, une classe sax qui intercepte ce qu'elle peut pour donner des
résultats. Avantage par rapport à la taglib, on ne s'embête plus à aller
chercher des choses en http, en session ou je ne sais où ailleurs, on ne
prends que ce qu'on nous donne, et on l'execute.

> B)Tirer des documents pour chaque résultat (c'est déjà un 
> filtre SAX, donc c'est encore facile) 

Inclusion des docs dans les résultats, un attribut ne suffira plus, le
développeur devra déclaré le transformeur en sitemap.

> C)Surligner des mots 
> (pas facile, il faut avoir l'objet Lucene de la
> requête)

Le surlignage a besoin de la requête effectuée pour savoir quels mots
surligner. Certes, c'est un transformeur (un de plus à déclarer en
sitemap), mais il faut lui trouver une manière de lui passer la requête
(sans la rééxecuter), uniquement en événements SAX (XML). On peut
imaginer passer un id d'objet java (fiable ?), pourvu que cela soit
caché correctement.

> D)etc.

Thesaurus ? Déclaration du parseur de requête ?


En conclusion, je n'ai pas de temps à mettre là-dessus ces mois ci, et
pour l'instant, je ne suis pas encore convaincu que cela apporte un
service qui justifie l'effort de développement. Mais si quelqu'un a le
temps, et voit plus clair, je suis franchement intéressé de voir
tourner, si on gagne en performances, en simplicité de conception.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]