[sdx-users] RE: sribzh

[Frédéric Glorieux]

Sur http://brea.culture.fr:8080/s1/sribzh/main.xsp
Ce message transfère une discussion qui pourrait intéresser
d'autres sdx:users.

 > Re,
 >
 > Frédéric Glorieux a écrit:
 > >    Je n'ai jamais pris le temps d'installer sribzh, c'est une
 > > erreur.
 > > J'aurais pu réfléchir un peu plus sur les applis SDX.
 >
 > :-)
 > Le gros intérêt de cette appli, c'est que les documents on
 > un système de
 > liens assez démentiel... qui n'est pas sans poser de
 > problèmes dans le
 > déploiement.... surtout en CI 2.1
 >
 > >    Au début j'étais un peu surpris, toute ta navigation
reposant
 > > sur une applet java, j'étais dans Opera, je ne voyais pas la
 > > barre. Personnellement, je n'oserais pas.
 >
 > Dans la prochaine version, y aura plus :-)
 >
 > >    Continuons sur les remarques type grand public (c'est la
place
 > > facile, genre devant sa télé), je verrais bien 2 ou 3
détails
 > > pour la version 2 qui faciliterait l'ergonomie. Exemple:
page
 > > suivante, page précédente, un peu méchant d'aller les faire
 > > chercher dans ta barre. D'autant que cela ne te permet pas
 > > d'aller à la page n (utile, je voulais rapidement voir le
 > > vocabulaire indexé, et 90 pages depuis brea, la pauvre
ramait).
 >
 > A priori, cette fonction devrait être désactivée en
production... ou
 > alors il faut que SDX puisse suivre. C'est ce genre
 > d'exemples qui m'a
 > fait réagir plus ou moins violement sur les results, le tri
 > et les termes.
 >
 > > L'appli tout en une page, la logique taglib2 le permet sans
une
 > > ligne de java, mais personnellement, je trouve sympa
d'ouvrir des
 > > url plus significatives (genre sribzh/search?q=...,
 > > sribzh/doc?id=...)
 >
 > Mmmh. J'aime pas trop exposer ce types d'URL. Peu importe,
 > j'avais pris
 > *volontairement* le parti de tout mettre dans la même XSP.
Rappelons
 > qu'à l'époque, la généricité de de SDX n'existait que sur le
papier.
 >
 > > Avec Cocoon2, tu peux toujours faire des URLs
 > > virtuelles.

Architecture d'appli

1 page = 1 action ?
1 appli = 1 page ?
1 tâche utilisateur = 1 url ?


 >
 > Plus maintenant, la proof of concept ayant été faite. Mais
 > bon, c'est à
 > voir...
 >
 > >    Sur la recherche, je suis complètement sidéré par le nombre
 > > d'index.
 >
 > Ce sont ceux de l'Inventaire.
 >
 >   >Dois-je le comprendre au sens de champ
 >
 > Oui, ce sont des champs (voir la config
 > http://brea.culture.fr:8080/s1/sribzh/conf/db_info.xml)
 >

 > > J'aurais plus tendance à travailler un formulaire de
recherche
 > > avancée adapté à mon public (voir ce qu'on peut vouloir
 > > chercher), et concevoir ma base en fonction. Ce n'est pas
une
 > > très belle démarche, elle ne part pas du document, mais
c'est un
 > > peu comme ça que j'ai fait mes applis.
 >
 > En fait, il devrait y avoir plusieurs niveaux de recherche,
 > selon les
 > utilisateurs. C'est pour ça que une page/une action, ça
 > risque de donner
 > une combinatoire diabolique...

A réfléchir.
Je ne parlerais pas de niveaux, mais en effet une bonne appli
doit pouvoir proposer plus d'un formulaire de recherche avancée.
Problème, cela veut dire pour chaque formulaire, une XSP qui
écoute les paramètres envoyés par l'XSL.
J'aimerais bien un petit toolkit qui me vérifie l'un et l'autre
avec le application xConf, mais c'est un rêve, parceque quand des
paramètres sont calculés par javascript...