sdx-developers
[Top][All Lists]
Advanced

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

Re: RE : [sdx-developers] Synthèse


From: Pierrick Brihaye
Subject: Re: RE : [sdx-developers] Synthèse
Date: Sat, 18 Jan 2003 10:09:17 +0100

Salut,

>C'est juste que je pensais qu'on avait réglé cet aspect, mais je
>constate que ce n'est pas le cas...

Le test case est dans sdxworld :-)

>Ah bon, je vois. Dans ce cas, c'est possible de le mettre en
>configuration. Dans sdx.xconf, puisque c'est valable pour la JVM.

C'était la question : Framework ou Application ? Moi, je m'en fous du moment
que ça marche :-) Cependant, je n'ai pas vraiment cherché sur les proxy avec
authentification. Ca me tarabuste un peu car j'ai bien l'intention
d'utiliser des URL ftp:// et là, mon employeur, me demande une
authentification, sans mot de passe... pour l'instant (il est toujours
interdit de rire).

>> Autre chose. Est-ce que les "actions" Cocoon sont dispo dans SDX ? Je
>> voudrais utiliser un DirectoryGenerator

>Il faut le rajouter. A priori, tout est disponible, il suffit d'avoir le
>bon JAR.

OK. Vous pouvez faire ça ?

>>Ceci m'amène à la question suivante : est-ce que xsp propose des
>>structures de contrôle similaires à celles d'XSL ? Si non, est-il
>>concevable de les implémenter ? Un truc du genre :

>Ce n'est pas dans XSP. Ca pourrait être implanté, j'imagine, mais dans
>ce cas il faut voir du côté du développement de Cocoon.

Oui je pense.. gros intérêt : des tas de choses qui sont faites à l'heure
actuelle en 2 xsp (ou 2 requests avec paramètres différents) pourraient être
fait en une seule... si je reprends l'exemple de mon DirectoryGenerator, on
pourrait faire une itération dessus <xsp:for-each> et insérer un
<sdx:upload-document>. Mais bon, c'est le design le plus compliqué car il
faut un système de "variables" et de "select" (au sens XSLT). Dans un
premier temps, <xsp:if> et <xsp:choose> seraient pas mal... ça permettrait
de supprimer un peu de <xsp:logic>.

Autre point de synthèse :

Y a-t-il la possibilité de définir, dans application.xconf ou via un autre
mécanisme l'opérateur par défaut du QueryParser ? On a la possibilité de
définir sa classe, alors pourquoi pas son opérateur par défaut ?

A bientôt,

p.b.






reply via email to

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