sdx-users
[Top][All Lists]
Advanced

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

RE: [sdx-users] tests de paramètres


From: Frédéric Glorieux
Subject: RE: [sdx-users] tests de paramètres
Date: Tue, 11 Feb 2003 16:02:28 +0100

 >
 > Et juste pour info (mais ça n'est pas très important) est-il
 > possible de le "maxer" tout en le laissant libre? Du genre
 >      si hpp>50 => hpp=50
 > ou   hppMax ="50"
 >
 > ce qui permettrait d'allier confort et sécurité.

Il n'y a pas de mécanismes de ce genre, nous n'y avons pas
réfléchi. Dans l'esprit on a essayé que tous les paramètres
d'actions SDX partagent une même logique. Ici un max ne vaudrait
que pour des paramètres nombre, ce qui reste un détail mineur.
Par contre, cela devient un vrai casse-tête de syntaxe pour
passer cette info.

<sdx:executeSimpleQuery hppMax="50" hppMaxParam="hppMax"/> ???

Est-ce que la syntaxe SDX n'est pas déjà assez compliquée ?

Rendu là, on peut vouloir aussi une expression régulière pour les
paramètres texte. Et dans quelle syntaxe ? On en aura toujours
trop ou pas assez.

Je pense qu'il vaut mieux bien soigner le java généré pour qu'un
développeur d'applications puisse accéder aux variables qui
courent.

Dernièrement on avait besoin d'un truc comme ça, pour tester les
thesauri

        <sdx:thesaurus th="dico"/>
        <sdx:terms field="fterm" hpp="-1" hppSession="hpp">
            <sdx:locations>
                <sdx:logic>
            // JAVA
            //adding another index to the search locations-rbp

sdx_locations.addIndex(((LuceneThesaurus)sdx_thesaurus).getIndex(
));
                </sdx:logic>
            </sdx:locations>
        </sdx:terms>

Le tag <sdx:locations/>  construit une variable sdx_locations du
même nom avec les paramètres SDX que l'on voudra. Pour connaître
la classe etc, voir tomcat/work ... L'idée c'était que la taglib
interprète le <sdx:logic/> pour le mettre à la bonne place dans
le java généré (avant ? après ? au milieu ? Beaucoup de choses
peuvent se passer).

Cela ne marche pas sur tous les objets SDX, mais l'idée est
posée, avec ce contrat
        un <sdx:logic/> imbriqué promet que du java compilable n'abîme
rien.
        Dedans est disponible une variable du même nom que l'élément
conteneur.

Qu'en pensent les autres utilisateurs ?

Dans le même genre de tag contextuel, on avait pensé à
<sdx:debug/>

Sur le même exemple

            <sdx:locations>
                <sdx:logic>
            // JAVA
            //adding another index to the search locations-rbp

sdx_locations.addIndex(((LuceneThesaurus)sdx_thesaurus).getIndex(
));
                </sdx:logic>
                <sdx:debug/>
            </sdx:locations>

Output
<sdx:debug>
Sortie de ce qu'un développeur de la taglib a trouvé utile pour
debugger une appli. Pas de contrat défini à l'avance ou
d'informations génériques jamais adaptées. Un effet magic tag, au
bon vouloir des contributions.
</sdx:debug>


Sur hpp (qui était l'origine de la discussion) on pourrait
implanter facilement un truc du genre

<sdx:executeSimpleQuery>
        <sdx:parameter name="hpp">
                <sdx:logic>
/*
à savoir, String sdx_parameter est dans le contrat. Dans le cas
d'un paramètre, on calcule aussi Integer sdx_i, Boolean sdx_bool
et autres pour les actions.
*/
if (sdx_i &gt; 100) sdx_i=100;
                </sdx:logic>
        <sdx:parameter name="hpp">
<sdx:executeSimpleQuery>

Est-ce que cela intéresse d'autres gens ? On peut implanter mais
on a pas le temps de tester.





reply via email to

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