cocoon-users-fr mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <sylv...@apache.org>
Subject Re: cforms / JX generator
Date Tue, 14 Jun 2005 10:44:34 GMT
Marc Salvetti wrote:

>
>>
>> Je ne comprends pas bien le "jx generator ne transmet pas directement 
>> les événements" (ce qu'il fait bien) et la relation avec l'attribut 
>> action.
>
>
> Ce qui me fait dire ca, c'est que si je fait un pipe test
> <map:match pattern="test">
>    <map:generate type="jx" src="template.xml"/>
>    <map:serialize type="xml"/>
>
> et que j'appelle ce pipe dans le navigateur, seul la racine du fichier 
> est affichee.
> mon fichier template commence comme ca. peut etre que j'ai oublié qq 
> chose.


Oui :-)

<ft:form-template> va chercher la form à afficher, et ne la trouve pas, 
puisqu'on ne vient pas d'un flowscript. Par contre, plutôt que d'ignorer 
ces tags, tu devrais avoir une jolie "NullPointerException: There hasn't 
been passed a form object to the template!"

> <form xmlns:ft="http://apache.org/cocoon/forms/1.0#template"
>        xmlns:fi="http://apache.org/cocoon/forms/1.0#instance"
>        xmlns:jx="http://apache.org/cocoon/templates/jx/1.0"
>        xmlns:i18n="http://apache.org/cocoon/i18n/2.1">
>
>    <jx:import 
> uri="resource://org/apache/cocoon/forms/generation/jx-macros.xml"/>
>
>    <ft:form-template 
> action="cart.continue?continuation=#{$cocoon/continuation/id}" 
> method="POST">
>
>
>> Pour info, mon approche sur cet attribut a évolué au cours du temps:
>>
>> - au début, je faisais un action="" (on renvoie à la même URL) avec 
>> un sélecteur sur la méthode http (get/post) pour choisir entre le 
>> call function ou le call continuation. Très pratique en apparence (on 
>> ne se soucie plus de l'url) cette méthode a montré ses limites le 
>> jour où l'URL appelée avait un paramètre qui existait aussi dans la 
>> form, aboutissant à avoir plusieurs valeurs pour ce champ.
>>
>> - maintenant, j'ai action="continue" ou action="continue.html". Ca 
>> résoud le problème précédent en conservant le fait de ne pas se 
>> préoccuper de l'URL où le formulaire est posté.
>>
> Jusqu'ici j'avais ca :
>
>    <ft:form-template action="#{$cocoon/continuation/id}" method="POST">
> et une template xsl apres le generateur :
>
>    <xsl:param name="action"/>
>    <xsl:template match="ft:form-template">
>        <xsl:copy>
>            <xsl:copy-of select="@enctype"/>
>            <xsl:attribute name="action"><xsl:value-of 
> select="$action"/>?continuation=<xsl:value-of 
> select="@action"/></xsl:attribute>
>            <xsl:copy-of select="./*"/>
>        </xsl:copy>
>    </xsl:template>
>
> et je passais le nom du form par la sitemap, mais apparement ca ne 
> marche pas avec jx


Compris!

Le point important à comprendre, c'est que jx-macros.xml est une 
*implémentation* du langage de templates CForms.

Il vient donc remplacer le forms-transformer, en ajoutant des 
fonctionnalités, principalement la création de variables JX "widget" au 
fur et à mesure qu'on parcourt les widgets du formulaire.

En sortie de ce générateur, on n'a donc plus aucun "ft:*", mais des 
"fi:*" (expansion du template en instances), ce qui explique que la XSL 
ne retrouve pas ses petits...

>> Bien sûr ! Les repeater-action et row-action, tout comme les actions 
>> normales, peuvent avoir des handler <on-action>. Voir par exemple 
>> exemples "dynamicrepater.xml". Et depuis un handler en javascript, tu 
>> peux appeler non seulement du code Java, mais aussi les fonctions du 
>> flowscript qui a affiché la form.
>>
>
> Ca y est, j'ai crée le handler, ca a l'air de fonctionner, par contre 
> je n'arrive pas a recuperer l'id de la ligne supprimée dans ma 
> fonction. je suppose que ca commence par event.getSource().... mais si 
> l'evenement est envoyé par le repeater, comment connaitre la ligne ?


Si c'est une "row-action", le "event.source.parent" n'est pas le 
repeater, mais une "row", le conteneur qui contient les widgets d'une 
ligne (classe org.apache.cocoon.forms.formmodel.Repeater$RepeaterRow)

Tu peux connaitre sa position (partant de 0) avec 
Repeater.indexOf(RepeaterRow) :
  var row = event.source.parent;
  var repeater = row.parent;
  var pos = repeater.indexOf(row);

> Et y a t'il une possibilité d'avoir un evenement après la suppression 
> ? le but de la fonction est de recalculer la facture a partir du 
> caddie, j'ai donc besoin de calculer ca apres que la ligne ai été 
> suprimée, .


Les event-listeners des row-actions sont appelés après l'action *sauf* 
dans le cas de la suppression d'une ligne ou l'appel est effectué avant 
la suppression pour qu'on puisse savoir ce qu'il y avait dans cette ligne...

> ou alors la supprimer manuellement dans le handler avant de lancer le 
> calcul, mais je me demande comment reagira le binding a la sortie de 
> l'evenement, quand il devra supprimer la ligne ?


Le binding est totalement déconnecté de tout ce qui peut se passer sur 
le repeater pendant l'interaction avec le formulaire. C'est pour ça que 
<fb:repeater> a une complexité certaine pour pouvoir faire du différentiel.

Sylvain

-- 
Sylvain Wallez                        Anyware Technologies
http://apache.org/~sylvain            http://anyware-tech.com
Apache Software Foundation Member     Research & Technology Director


---------------------------------------------------------------------
Liste francophone Apache Cocoon -- http://cocoon.apache.org/fr/
Pour vous desinscrire : mailto:users-fr-unsubscribe@cocoon.apache.org
Autres commandes : mailto:users-fr-help@cocoon.apache.org


Mime
View raw message