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 Sylvain Wallez <sy...@apache.org> on 2005/01/27 11:59:55 UTC
Re: Bonjour, je me présente... : dictionnaire de données centralisé
Lucas Arnaud wrote:
>Je vais essayer d'être plus clair :
>
>Pour gérer un satellite, on a plusieurs centres de traitement :
> - un qui est chargé de piloter le satellite
> - un ou plusieurs chargés de programmer les instruments à bord
> - un ou plusieurs "clients" qui reçoivent les résultats
> - un pour planifier tout ça
>Tous ces centres s'envoient mutuellement des fichiers (dans mon projet,
>c'est du XML). Ces fichiers sont décrits en XML Schema. L'idée, c'est donc
>d'avoir un serveur regroupant tous les types Schema utilisés dans tous
>les systèmes pour garantir la cohérence. La description des fichiers se
>fait alors simplement en utilisant l'ordre xs:import du Schema.
>Donc mon serveur est vu comme un "dictionnaire" de types XML Schema.
>En plus, on récupèrera les informations dans xs:annotation pour pouvoir
>générer des "documents d'interface" décrivant la structure des fichiers
>échangés. Ainsi, ceux qui ne lisent pas le Schema, pourront quand même y
>comprendre quelque chose.
>
>Voilà ce que je veux faire, le tout avec cocoon...
>
>
C'est un bon choix :-)
Plus sérieusement, un XMLSchema étant écrit en XML, il peut parfaitement
entrer dans une chaîne de transformation pour en faire... un peu ce
qu'on veut (même si ça serait plus facile avec RelaxNG) : écrans de
saisie, docs lisibles, etc.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
---------------------------------------------------------------------
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: dictionnaire de données centralisé : interface de saisie
Posted by Sylvain Wallez <sy...@apache.org>.
Arnaud Blancher wrote:
> Sylvain Wallez wrote:
>
>> Lucas Arnaud wrote:
>>
>>> Je vais essayer d'être plus clair :
>>>
>>> Pour gérer un satellite, on a plusieurs centres de traitement :
>>> - un qui est chargé de piloter le satellite
>>> - un ou plusieurs chargés de programmer les instruments à bord
>>> - un ou plusieurs "clients" qui reçoivent les résultats - un
>>> pour planifier tout ça
>>> Tous ces centres s'envoient mutuellement des fichiers (dans mon projet,
>>> c'est du XML). Ces fichiers sont décrits en XML Schema. L'idée,
>>> c'est donc
>>> d'avoir un serveur regroupant tous les types Schema utilisés dans
>>> tous les systèmes pour garantir la cohérence. La description des
>>> fichiers se
>>> fait alors simplement en utilisant l'ordre xs:import du Schema.
>>> Donc mon serveur est vu comme un "dictionnaire" de types XML Schema.
>>> En plus, on récupèrera les informations dans xs:annotation pour pouvoir
>>> générer des "documents d'interface" décrivant la structure des fichiers
>>> échangés. Ainsi, ceux qui ne lisent pas le Schema, pourront quand
>>> même y
>>> comprendre quelque chose.
>>>
>>> Voilà ce que je veux faire, le tout avec cocoon...
>>>
>>>
>>
>> C'est un bon choix :-)
>>
>> Plus sérieusement, un XMLSchema étant écrit en XML, il peut
>> parfaitement entrer dans une chaîne de transformation pour en
>> faire... un peu ce qu'on veut (même si ça serait plus facile avec
>> RelaxNG) : écrans de saisie, docs lisibles, etc.
>>
>
> D'un point de vu strictement théorique, je veux bien. on peut faire
> une interface de saisie a partir d'un schemas
> maintenant en passant du côté pratique, il y a pas mal de chose qui me
> dérange.
>
> exemple avec deux champs.
>
> 1 type de document
> 2 sous type.
>
> disons qu'il y a 4 type de documents:
> ta1,ta2,tb3,tb4
> supossons que le sous type est liée au type:
> ta1 permet ta1st1, ta2st2,
> ta2 permet ta2st1,ta2st2,
> ta3 permet tb3st1,tb3st2,
> ta4 permet tb4st1,tb4st2
>
> en xslt je dois men sortir (avec un peut de javascript dans
> l'interface client)
>
> mais ,
> si je veux introduire une condition classique du style
> les possibilités du type de document sont en fonction du login
> ca se complique tres fortement, non ?
>
> vous traitrez toujours cela à partir du schemas ?
Ca dépend. A ce niveau de complexité encore faible, on peut utiliser le
schéma pour produire un formulaire CocoonForms (définition + template)
utilisant les "union" (sous-formulaires variants selon la valeur d'un
champ).
Avec des schemas plus complexes, je me méfie des IHM entièrement
autogénérées, qui sont souvent peu ergonomiques. Arnaud a mentionné
l'utilisation des xs:annotation, qui sont un bon support pour mettre des
indications de mise en forme des IHM pour produire des interfaces moins
"mécaniques".
Et sur des schemas encore plus complexes, on fait ses CocoonForms à la
main (on a fait ça pour un schéma se décomposant en plus de 50 écrans).
> avec des xslt ?
Oui, mais pour produire les CocoonForms qui font ensuite tout le boulot.
Pour ce qui est du filtrage par rapport au login, CocoonForms (encore
lui) permet de donner un état au champ de saisie, le rendant soit non
saisissable, soit carrément invisible. On a ainsi un unique formulaire
qui peut facilement s'adapter aux permissions d'un utilisateur donné.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
---------------------------------------------------------------------
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
dictionnaire de données centralisé : interface de saisie
Posted by Arnaud Blancher <Ar...@ungi.net>.
Sylvain Wallez wrote:
> Lucas Arnaud wrote:
>
>> Je vais essayer d'être plus clair :
>>
>> Pour gérer un satellite, on a plusieurs centres de traitement :
>> - un qui est chargé de piloter le satellite
>> - un ou plusieurs chargés de programmer les instruments à bord
>> - un ou plusieurs "clients" qui reçoivent les résultats - un
>> pour planifier tout ça
>> Tous ces centres s'envoient mutuellement des fichiers (dans mon projet,
>> c'est du XML). Ces fichiers sont décrits en XML Schema. L'idée, c'est
>> donc
>> d'avoir un serveur regroupant tous les types Schema utilisés dans
>> tous les systèmes pour garantir la cohérence. La description des
>> fichiers se
>> fait alors simplement en utilisant l'ordre xs:import du Schema.
>> Donc mon serveur est vu comme un "dictionnaire" de types XML Schema.
>> En plus, on récupèrera les informations dans xs:annotation pour pouvoir
>> générer des "documents d'interface" décrivant la structure des fichiers
>> échangés. Ainsi, ceux qui ne lisent pas le Schema, pourront quand même y
>> comprendre quelque chose.
>>
>> Voilà ce que je veux faire, le tout avec cocoon...
>>
>>
>
> C'est un bon choix :-)
>
> Plus sérieusement, un XMLSchema étant écrit en XML, il peut
> parfaitement entrer dans une chaîne de transformation pour en faire...
> un peu ce qu'on veut (même si ça serait plus facile avec RelaxNG) :
> écrans de saisie, docs lisibles, etc.
>
D'un point de vu strictement théorique, je veux bien. on peut faire une
interface de saisie a partir d'un schemas
maintenant en passant du côté pratique, il y a pas mal de chose qui me
dérange.
exemple avec deux champs.
1 type de document
2 sous type.
disons qu'il y a 4 type de documents:
ta1,ta2,tb3,tb4
supossons que le sous type est liée au type:
ta1 permet ta1st1, ta2st2,
ta2 permet ta2st1,ta2st2,
ta3 permet tb3st1,tb3st2,
ta4 permet tb4st1,tb4st2
en xslt je dois men sortir (avec un peut de javascript dans l'interface
client)
mais ,
si je veux introduire une condition classique du style
les possibilités du type de document sont en fonction du login
ca se complique tres fortement, non ?
vous traitrez toujours cela à partir du schemas ?
avec des xslt ?
Arnaud
---------------------------------------------------------------------
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