Suite au problème exposé plus bas, disons rapidement, une séquence de
pages à ordonner (toc) et à éditer une à une (page), je note ici pour
mémoire une approche non cforms, au cas où cela puisse intéresser.
J'ai été réellement impressionné par tout ce que CForms peut faire, il
fait ce qu'il dit (une bibliothèque énorme), mais mon problème est
peut-être d'un autre ordre, et je n'arrête pas de frapper des limites
avec des courbes d'apprentissage trop importantes.
Il ne s'agit pas d'un process
submit > (fail ou success)
mais plutôt un genre d'édition XML en ligne
modify|validate|view|save (en continu)
où les "widgets" servent à attaquer quelques noeuds d'un document riche.
Pour l'exemple, voici le tuyau qui permet de
insérer,supprimer,renommer,ordonner
les feuilles
<map:match pattern="toc">
<!--
En entrée, l'instance telle qu'on peut la récupérer
(soit d'un fichier, soit de la session),
C'est une xsp qui génère et gère les sauvegardes
-->
<map:generate src="cocoon:/instance"/>
<!--
cette transformation prends l'état actuel du document
et les paramètres de requêtes obtenu par un request generator
Elle interprète des choses comme supprimer, monter d'un niveau, etc
-->
<map:transform src="structure.xsl">
<map:parameter name="mode" value="bind"/>
</map:transform>
<!--
Une transformation maison pour sauvegarder cette étape de tuyau
dans un document DOM en session
c'est une réécriture de WriteSessionTransformer qui ne conservait
pas les commentaires et stockait un Node, et non un Document
(= perdre les commentaires ou les PI en racine avant l'élément root)
-->
<map:transform type="DOMSave">
<map:parameter name="session-force" value="true"/>
<map:parameter name="session-attribute" value="document"/>
</map:transform>
<!--
Là, la source est transformée en un "formulaire" qui délivre en même
temps les alertes, les conseils, les confirmations de suppression...
Le "bind" et le "form" sont dans une même XSL,
afin de s'assurer que s'il on veut faire quelque chose avec un
<h:parameter name="delete"/>, il y a bien un <button name="delete"/>
quelque part.
-->
<map:transform src="structure.xsl">
<map:parameter name="mode" value="form"/>
</map:transform>
<!--
Et ici, cela peut rentre dans une agrégation
globale au site, avec maquette ou i18n,
par cocoon:/toc
-->
<map:serialize type="xhtml"/>
</map:match>
Une logique comparable fonctionne pour quelque chose comme
<map:match pattern="page">, afin d'éditer les feuilles.
Ces tuyaux sont insérables dans une logique de frame (toc à gauche, page
en cours d'édition à droite).
Mon "formulaire" tient en
* un sitemap qui fait la logique
* une xsp qui gère le document (entre session et persistance)
* une xsl par "formulaire" pour afficher les contrôles (form) et
savoir les traiter (bind), contre le document source.
Les xsl à écrire, il faut en convenir, sont plutôt compliquées. Mais
pour ce qui me concerne, c'est le langage le plus commode pour
intervenir sur un document XML en étant sûr de ne rien casser.
Comme on est toujours sur nos problèmes documentaires...
Autant que je demande à l'expert.
Je fais actuellement un formulaire pour générer l'équivalent de cela
http://dublincore.org/2003/03/24/dces
un modèle pas vraiment compliqué
rdf:RDF(rdf:Description,rdf:Property)
rdf:Property(rdfs:label,dc:title ...)
Quelle serait la meilleur approche ?
Déjà je constate que les repeater veulent un élément dans lequel être
seuls, je suppose que que les rdf:Property seront plus à l'aise dans un
truc genre rdf:Seq (séquence).
Ensuite l'édition d'une propriété demande bien un écran. Je pensais
partir sur 2 formulaires, l'un qui gère la répétition et l'ordre des
propriétés (genre frame de gauche) et l'autre qui sache prendre une
seule propriété sans perturber les autres. Est-ce jouable ?
--
Frédéric Glorieux (AJLSM, http://ajlsm.com)
---------------------------------------------------------------------
Liste francophone Apache Cocoon -- http://cocoon.apache.org/fr/
Pour vous desinscrire : mailto:[EMAIL PROTECTED]
Autres commandes : mailto:[EMAIL PROTECTED]
