[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [sdx-developers] sdx:deleteDocument(s)
From: |
Frédéric Glorieux |
Subject: |
Re: [sdx-developers] sdx:deleteDocument(s) |
Date: |
Fri, 07 Nov 2003 21:53:51 +0100 |
User-agent: |
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20030916 |
Je remarque une grosse dyssymétrie entre le SAX généré par
<sdx:uploadDocument(s)> et celui généré par <sdx:deleteDocuments>.
Difficile de rédiger des XSL avec ça :-)
J'ai en mon temps souhaiter et contribuer à la congruence des noms (vu
du côté auteur d'appli),
> Les constantes de nommage :
Razik a bien installé la classe de nommage pour assurer la factorisation
des termes. On peut donc assurer que la batterie de filtres SAX continue
à fonctionner.
> String UPLOAD_DOCUMENT = "uploadDocument";
> String UPLOAD_DOCUMENTS = "uploadDocuments";
>
> J'aime bien :-)
Question de goût, difficile d'expliquer que l'underscore correspond ici
à du camelCase.
> String DELETION = "deletion";
> String DELETIONS = "deletions";
>
> J'aime moins :-(
Nom court, plus dans le goût Docbook que développeur. A mettre aux voix
? Malo, c'est quoi ton avis ? On connait celui de Martin, plus c'est
long, plus c'est bon (avec plein de lettres, au moins on sait de quoi on
parle). Je crois me souvenir que Razik n'aime pas trop choisir les noms.
J'ai mes goûts, mais je n'aurais qu'une opinion : "rester cohérent
partout". Je trouve très laid d'avoir des noms qui ne change pas de
style au gré des modes (j'ai 2, 3 mauvais exemples de XML à vous montrer
sur le sujet).
Mais attention, quel est le capital xsl sur ces noms ? Je rappelle par
exemple que j'ai laissé des attributs redondants sur les requêtes et les
termes par souci de compatibilité arrière.
<sdx:results qid="sdx_q1" [page="1" currentPage="1"] hpp="30" [pages="4"
nbPages="4"] nb="103" start="1" end="30" id="sdx_q1">
J'avais alors le soucis d'alléger ma mémoire, un nom=un attribut XML ou
http.
2) un upload renvoie des <sdx:summary> avec :
@additions
@failures
@duration
Une destruction ne renvoie pas de @duration. On pourrait continuer la
mutualisation en mettant @success ou similaire en lieu et place de
@additions/@deletions.
@success n'indique pas spontanément un nombre. Sur ce point j'ai eu
plusieurs opinions contradictoire, jusqu'à adopter un vieux souvenir
mathématique @card(inal) qui n'était pas vraiment partager par beaucoup.
Le problème, c'est de distinguer la quantité (nombre), et l'ordre
(numéro), selon un nombre de caractères raisonnables, et compréhensible
de plus d'une langue. @nb, @no ? Discutable, mais c'est dans les <results/>.
4) Sans détailler les autres subtilités de <sdx:deleteDocuments>, il y a
également un gros hack à mettre en place, au moins dans la doc :
Si le <sdx:deleteDocument> utilise une Query (très pratique !), il ne
faut pas oublier de fixer un @hpp à -1 sinon on ne détruira que les 20
premiers résultats.
Il faut se demander si on a intérêt (par défaut) à détruire des docs 20
par 20. A priori, je ne vois pas.
Qu'en pensez-vous ?
du bien, franchement, mais c'est un gros chantier s'il on prête
attention à conserver les cohérences.
- [sdx-developers] sdx:deleteDocument(s), Pierrick Brihaye, 2003/11/07
- Re: [sdx-developers] sdx:deleteDocument(s),
Frédéric Glorieux <=
- Re: [sdx-developers] sdx:deleteDocument(s), Pierrick Brihaye, 2003/11/08
- Re: [sdx-developers] sdx:deleteDocument(s), Malo Pichot, 2003/11/10
- Re: [sdx-developers] sdx:deleteDocument(s), Pierrick Brihaye, 2003/11/10
- Re: [sdx-developers] sdx:deleteDocument(s), Frédéric Glorieux, 2003/11/10
- Re: [sdx-developers] sdx:deleteDocument(s), Pierrick Brihaye, 2003/11/10
- [sdx-developers] RE : sdx:deleteDocument(s), Martin Sevigny, 2003/11/12
- Re: [sdx-developers] RE : sdx:deleteDocument(s), Pierrick Brihaye, 2003/11/12
- Re: [sdx-developers] RE : sdx:deleteDocument(s), Pierrick Brihaye, 2003/11/12
- RE : [sdx-developers] RE : sdx:deleteDocument(s), Rasik Pandey, 2003/11/12