cocoon-users-fr mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <sylv...@apache.org>
Subject Re: dictionnaire de données centralisé : interface de saisie
Date Thu, 27 Jan 2005 12:32:59 GMT
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


Mime
View raw message