You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users-fr@cocoon.apache.org by Frédéric Glorieux <fr...@ajlsm.com> on 2005/11/04 14:09:26 UTC
Re: Question existentielle sur CForms, les dates et i18n
Déjà merci sur cette explication qui permet de mieux comprendre cette
distinction fd/fb
A tout hasard, si je veux un contrôle avec des inputs séparés, genre
[jj]/[mm]/[aaaa]
c'est à la main ? Genre xsl/javascript client qui reprends jj+mm+aaaa et
le renvoit proprement ? Ou bien il y a du déjà fait quelque part ?
> Dans le fd, tu déclares ce que tu veux voir au niveau de ton client,
> c'est à dire le browser :
>
> <fd:field id="dtstart">
> <fd:datatype base="date">
> <fd:convertor>
> <fd:patterns>
> <fd:pattern>dd/MM/yyyy HH:mm:ss</fd:pattern>
> </fd:patterns>
> </fd:convertor>
> </fd:datatype>
> </fd:field>
>
> Au niveau du fb, tu déclares le format de stockage de la date :
>
> <fb:value id="dtstart" path="dtstart">
> <fd:convertor datatype="date" type="formatting" variant="datetime">
> <fd:patterns>
> <fd:pattern>yyyy-MM-dd'T'HH:mm:ss.SSSZ</fd:pattern>
> </fd:patterns>
> </fd:convertor>
> </fb:value>
>
> Dans le cas ci-dessus, tu as une date à un format standardisé (par
> exemple: 2005-10-24T20:23:00.000+0100)
>
> De plus, tu peux ajouter un attribut locale dans le premier cas qui te
> permettra d'adapter ta présentation selon la langue de ton client :
> <fd:pattern locale="fr_FR">dd/MM/yyyy HH:mm:ss</fd:pattern>
>
> Jean-Christophe
>
> Sylvain Wallez a écrit :
>> Aurélien DEHAY wrote:
>>
>>> Bonjour à tous.
>>>
>>> Une question, forcément existentielle donc, histoire de faire les choses
>>> le plus proprement possible.
>>>
>>> J'ai un formulaire, dans lequel l'utilisateur rentre une date. J'aimerai
>>> que cette date soit stockée de la même manière quelque soit la locale de
>>> l'utilisateur, pour ensuite être rendue correctement dans la locale du
>>> navigateur.
>>>
>>> J'utilise cocoon 2.1.7, j'avais déjà posé la question sur la lidie
>>> anglaise, on m'avait renvoyé sur
>>> http://www.mail-archive.com/dev@cocoon.apache.org/msg33411.html mais je
>>> n'utilise pas Javaflow, et je me vois mal patcher tout ça.
>>>
>>> Si quelqu'un avait déjà réfléchi à ça, je suis preneur (en 2.1.7 ou
>>> 2.1.8).
>>
>>
>> Un élément essentiel de Cocoon Forms est que l'appli n'a pas à se
>> préoccuper des formats de saisie. Si un field est de type "date", sa
>> valeur (renvoyée par getValue()) sera une java.util.Date, et pas une
>> String.
>>
>> Les formats sont spécifiés dans le <fd:convertor> et on peut indiquer
>> des formats dépendant de la locale [1]. Si le formulaire est ensuite
>> stocké dans un document XML, et puisque XML est du texte, on peut
>> aussi spécifier dans le binding <fb:value> le format de stockage de la
>> date dans le document [2].
>>
>> Sylvain
>>
>> [1]
>> http://cocoon.zones.apache.org/daisy/documentation/forms/concepts/487.html
>>
>> [2]
>> http://cocoon.zones.apache.org/daisy/documentation/forms/binding/488.html
>>
>
>
--
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
éditer un rdfs simple (Re: Question existentielle sur CForms, les dates et i18n)
Posted by Frédéric Glorieux <fr...@ajlsm.com>.
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
Re: Question existentielle sur CForms, les dates et i18n
Posted by Frédéric Glorieux <fr...@ajlsm.com>.
> Tu n'as pas trempé dans xdepo, qui utilise plein de CForms??
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
Re: Question existentielle sur CForms, les dates et i18n
Posted by Frédéric Glorieux <fr...@ajlsm.com>.
> Tu n'as pas trempé dans xdepo, qui utilise plein de CForms??
Pas moi, mais justement, je m'y mets.
--
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
Re: Question existentielle sur CForms, les dates et i18n
Posted by Sylvain Wallez <sy...@apache.org>.
Frédéric Glorieux wrote:
>
>> <fd:aggregatefield> fait ça très bien :-)
>
> vu dans la demo, même en cocoon 2.1.5
> Désolé, si la page date de 2004/04/05, ma lente et dure conversion
> date d'hier.
Tu n'as pas trempé dans xdepo, qui utilise plein de CForms??
Sylvain
--
Sylvain Wallez Anyware Technologies
http://people.apache.org/~sylvain http://www.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
Re: Question existentielle sur CForms, les dates et i18n
Posted by Frédéric Glorieux <fr...@ajlsm.com>.
> <fd:aggregatefield> fait ça très bien :-)
vu dans la demo, même en cocoon 2.1.5
Désolé, si la page date de 2004/04/05, ma lente et dure conversion date
d'hier.
--
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
Re: Question existentielle sur CForms, les dates et i18n
Posted by Sylvain Wallez <sy...@apache.org>.
Frédéric Glorieux wrote:
> Déjà merci sur cette explication qui permet de mieux comprendre cette
> distinction fd/fb
>
> A tout hasard, si je veux un contrôle avec des inputs séparés, genre
> [jj]/[mm]/[aaaa]
> c'est à la main ? Genre xsl/javascript client qui reprends jj+mm+aaaa
> et le renvoit proprement ? Ou bien il y a du déjà fait quelque part ?
<fd:aggregatefield> fait ça très bien :-)
Sylvain
--
Sylvain Wallez Anyware Technologies
http://people.apache.org/~sylvain http://www.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