Re: [sdx-developers] Migration

[Frédéric Glorieux]

| Toujours, et surtout nettement plus souple. En fait, il y a trois façons

4(,5) façons

| (systématiquement je crois) de passer des paramètres à SDX en XSP :

systématique, je confirme ou c'est un bug

| depuis un paramètre HTTP, depuis une variable Java, avec une valeur
| constante. De plus, il y a en général des valeurs par défaut.
|
| Supposons que tu veux passer une valeur pour le paramètre sdx "hpp".
| Alors, si tu fais :

ordre de priorité

    1) @hppString="ma_variable_java_declaree"
si on se fatigue à calculer une variable java, c'est elle qui gagne
    2) @hppSession="mon_objet_de_session"
Prenons justement le cas des résultats par page, si on n'a pas envie de
trimballer le paramètre de page en page pour donner 100 résultats comme dans
Google, l'attribut est stocké dans l'objet de session du nom choisi, l'objet
est modifié à chaque nouvelle valeur d'URL, mais s'il n'y a rien en URL,
c'est la session qui prend le relais (pratique pour la langue ou autres
persistances d'interface).
    3) @hppParam="mon_parametre_GET_ou_POST"
Unification systématique de ce que SDX1 proposait, sans compter les
paramètres par défaut (qui devrait peut-être être dépréciés pour encourager
à la clarté du code XSP).
    4) @hpp="16"
valeur par défaut. Exemple, avec cette requête <sdx:executeSimpleQuery
query="sdxall:1"/>, une page de résultats peut servir un aperçu d'une base,
même si l'utilisateur ne formule aucune requête.
      5)     //rien
par défaut hpp=20