sdx-developers
[Top][All Lists]
Advanced

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

Re: [sdx-developers] sdx:deleteDocument(s)


From: Pierrick Brihaye
Subject: Re: [sdx-developers] sdx:deleteDocument(s)
Date: Sat, 8 Nov 2003 11:48:40 +0100

Salut,

>  > 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.

Pas très gênant à vrai dire : mon problème est plutôt dans la gestion des
exceptions. Dans uploadDocuments, celles-ci sont bien encapsulées dans des
<sdx:uploadDocument>et sont donc facile à parser avec un <xsl:for-each> afin
de faire un beau tableau HTML. Ce n'estpas le cas pour les deleteDocuments
:-(

Autre chose sur ce sujet, on a l'id, le repo et la base (pas dans
<sdx:deletion> : autre dyssymétrie) : pourrait-on également avoir un flag
qui donnerait la nature du document (i.e. document, sub-document,
attached-document...) ? J'aimerais bien pouvoir trier sur ce flag en plus de
l'id (qui n'est pas très significative).

> > 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.

Peu importe : la dyssymétrie concerne surtout l'absence de @duration...

> > 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.

Moi non plus :-) Que faire : forcer le HPP à -1 dans la logicsheet ?

Tout ça n'est pas très important du point de vue fonctionnel mais gêne pas
mal de design d'applis robustes.

A+

p.b.








reply via email to

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