cocoon-users-fr mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Frédéric Glorieux <frederic.glori...@ajlsm.com>
Subject éditer un rdfs simple (Re: Question existentielle sur CForms, les dates et i18n)
Date Mon, 07 Nov 2005 11:34:09 GMT

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:users-fr-unsubscribe@cocoon.apache.org
Autres commandes : mailto:users-fr-help@cocoon.apache.org


Mime
View raw message