> Une page d'erreur générique? Et pourquoi ne pas réafficher la même page > avec l'indication de l'erreur de saisie. Cocoon Forms est fait pour ça, > tout de même :-)
oui, c'est le comportement logique des CForms, mais j'ai voulu faire quelque chose qui à priori pose problème : j'ai une interface d'administration plutôt basique : un header avec quelques liens comme "logout" par ex., un menu à gauche pour sélectionner une section à administrer, un footer, et enfin un écran, qui affiche les CForms. plutôt qu'utiliser un map:aggregate qui regroupe les quatre morceaux, suivi d'une transfo xsl qui transforme tout, j'ai fait un squelette (JXTemplate), qui utilise des <cinclude> vers des patterns internes (comme cocoon:/menu.xml, cocoon:/header.xml, etc. mais surtout des choses comme cocoon:/forms/ajouterUnTruc.form) pour construire la page complète, le squelette reçoit ensuite une transformation cinclude, puis une transfo i18n à la fin. au 1er appel ça fonctionne, le flux issu de cocoon:/forms/ajouterUnTruc.form est bien inclu dans le JX, j'ai un joli formulaire :) mais quand une erreur de validation survient, showForm rappelle le pattern cocoon:/forms/ajouterUnTruc.form, et je me retrouve assez logiquement avec juste un formulaire et ses indicateurs de saisie, et pas le JX contenant les autres morceaux. ça ressemble à une erreur de design de ma part (pas taper), je voulais eviter de faire un pattern par CForm, qui aggrege toujours les trois mêmes morceaux, le quatrieme changeant à chaque fois (CForm différent), mais visiblement injecter les CForms avec un cinclude était pas une bonne idée. voilà, c'est un peu long, mais je le laisse pour les archives :) laurent --------------------------------------------------------------------- Liste francophone Apache Cocoon -- http://cocoon.apache.org/fr/ Pour vous desinscrire : mailto:[EMAIL PROTECTED] Autres commandes : mailto:[EMAIL PROTECTED]
