Re: [sdx-developers] 2.1

[Pierrick Brihaye]

Re,

Frédéric Glorieux a écrit:

> ??? j'ai lu, mais on en a qui fonctionne ???
> Est-ce que cela ne tient pas au fait que le mail posté tentait de
> faire une requête date avec une simpleQuery ?

Il semble qu'il soit passé à une FieldQuery ensuite... problème dans les 
locations ?

>  > - upload URL en text/html par défaut
>
> Fait (pas commité, je bosse sur d'autres trucs).
>         ('sdx-actions.xsl')//xsl:address@hidden"sdx:document"].
> Pierrick, je serais content que tu regardes là-dedans. Il y a des
> chaines de priorités qui n'ont pas été fortement pensées.
> (ailleurs aussi, tu me diras). Je serais très heureux que la
> logique taglib soit frottée à plus de logiques différentes.

On est d'accord. En fait, je le fais... quand j'ai le temps.

>  > - problème d'upload de DOM
>
> ??? Cocoon ???

Mmmh. Apparemment, le code SDX n'y est pas pour rien (v. mon commentaire 
sur XMLDocument.java).

>  > - mise à jour de la doc
>
> sdx-actions, je sais, mais le temps... Les uploads, et les
> droits.

Et, peut-être, une explication plus poussée sur les paramètres.

>  > Accessoirement :
>  > - créer un alias pour la SimpleQuery (ParsedQuery ?)
>
> Facile à faire, mais je ne suis pas d'accord. Je pense que pour
> la majorité des utilisateurs, la simpleQuery sera utilisée comme
> un "simple" champ texte.

Les goûts et les couleurs :-) J'apporte un autre argument : Parsed indique :

- une analyse
- que l'on peut utiliser les "|" pour faire des recherches de valeurs 
(c'est d'ailleurs ce que cherchait à faire la parsedQuery que j'avais 
mise dans SDX 1). Très bon ! (à propos : peut-on escaper ce caratère ? 
je ne me souvient pas l'avoir dans les séquences)

> Les autres (qui veulent du complexe
> comme Emmanuel Bégué), ils sauront de comprendre que ce n'est pas
> si simple (la doc est elle assez rédigée dans ce sens ?).

Elle laisse pas mal de points en suspens (notamment la gestion des 
opérateurs). BTW, ne pourrait-on pas concevoir une injection XML des 
complexQuery plutôt que de se prendre la tête sur un formalisme qui me 
paraît insoluble ? L'OGC a désormais pris ce parti : on injecte (en 
POST) une request multipartite avec une requête XML dedans... ce qui a 
considérablement accéléré les développements.

>  > - upload URLDIR (ou test isDirectory sur un paramètre URL ?)
>
> URLDIR apporterais beaucoup de confusion.

Certes :-)

> urldir=http://www.google.com/ , pourquoi ça ne m'indexe pas tout
> Google ?

Canonique : le slash de fin arrête ma requête à ce répertoire. Mais bon, 
si tu veux, tu nous fais www.google.com/** :-)

> Je me suis pourtant demandé s'il ne fallait pas marcher au
> maximum en url, et toujours leur donner la priorité.

Eh, eh :-)

>  > - être moins permissif dans la taglib (paramètres interdits) ?
>
> ???

On ne devrait pas pouvoir passé un paramètres non prévu. V. l'exemple de 
la fieldQuery avec un opérateur.

>  > Par ailleurs, est-il possible de faire "simplement" un outil
>  > de débogage
>  > qui afficherait la transformation résultant du passage d'une
>  > XSP dans la
>  > taglib ? Ca devrait aider à tracer pas mal de bugs... si le
>  > code peut
>  > être "mis en forme" (Chaperon ?), ça serait encore mieux...
>
> Tu t'appliques sdx.xsl direct, je teste beaucoup comme ça.

-> sitemap ?

> Tu
> veux xsp2java dans sdxtest ?

Oui, c'est ça, mais le Java *avant* passage de la taglib Cocoon.

A+

--
Pierrick Brihaye, informaticien
Service régional de l'Inventaire
DRAC Bretagne
mailto:address@hidden