Surveiller ce forum | Commencer une nouvelle discussion Commencer une nouvelle discussion
RE: XML & Acube [ Répondre ]
Par : Cyril Rocheteau on 2007-06-12 13:50		[forum:52742]
je vote également (c'est la période ;-) pour le layout et la version lecture/écriture.

A terme, il doit y avoir tous les types de composant, onglets compris

RE: XML & Acube [ Répondre ]
Par : Cyril Rocheteau on 2007-06-12 13:48		[forum:52741]
Je te rejoins sur l'intérêt de mettre en oeuvre la pattern validator.
Faudrait également prévoir des règles et/ou pour les validateurs de base.

RE: XML & Acube [ Répondre ]
Par : Benjamin Leperchey on 2007-06-11 12:32		[forum:52740]
Tout à fait d'accord sur le besoin d'intégrer le layout à cette description : ca sera utile pour minimiser la reprise du HTML généré et indispensable pour créer le formulaire "à la volée" en javascript

Pourquoi ne pas aller encore un peu plus loin, et intégrer les onglets au XML de description du formulaire ?

RE: XML & Acube [ Répondre ]
Par : Benjamin Leperchey on 2007-06-11 12:28		[forum:52739]
Tout à fait d'accord sur la séparation description/valeurs.

Il pourrait même être intéressant de proposer deux modes de génération à partir de la même description : un qui affiche le formulaire "éditable" avec des inputs et un mode "consultation" qui affiche simplement le valeurs de chaque champ (c'est à mon avis plus clair que des inputs désactivés).

Ca serait évidemment plus intéressant pour une génération "à la volée" : le même javascript et le même XML permettrait d'afficher une fiche en mode "consultation" et "edition"

RE: XML & Acube [ Répondre ]
Par : Benjamin Leperchey on 2007-06-11 12:22		[forum:52738]
Ce qui serait intéressant, c'est de joindre les règles de validation à la définition du formulaire lui-même, sur un système similaire au framework "Validator" de Struts (maintenant dans Apache-commons).

Ca permettrait
1) de centraliser la description d'un formulaire,
2) d'appliquer automatiquement les mêmes règles côté serveur et côté client.

A mon avis, la base de la validation, c'est le type des valeurs attendues : int, string, date etc. avec éventuellement des valeurs min et max ou une expression régulière.

Ca serait pas mal de prévoir un champ dans la DTD pour préciser ce type àau niveau de l'élément de formulaire, indépendamment des règles de validation plus complexes (interdépendance entre champs) qu'on pourrait repousser à une seconde version.

RE: XML & Acube [ Répondre ]
Par : Xavier PRINCE on 2007-02-19 23:03		[forum:52512]
Effectivement la version unaire semble une base plus probante que le version sans argument ... la majorité des composants possédant comme argument minimal leur identifiant qui se rapproche de l'identifiant de la zone de div dans laquelle sera affiché le composant.

RE: XML & Acube [ Répondre ]
Par : Xavier PRINCE on 2007-02-19 22:59		[forum:52511]
Le but n'est pas d'imposer un format mais de fournir un format et une DTD permettant de gérer les éléments existant et de se voir compléter à l'arrivée de nouveau composant.
Le principe de nommage des balises me semble très bon et nous allons balayer la DTD pour vérifier qu'il est bien respecté.

Pour la langue des balises, je me demande s’il ne serait pas bon de préparer le terrain à la bascule en langue anglaise du Framework ergonomique.

RE: XML & Acube [ Répondre ]
Par : Cyril Rocheteau on 2007-02-19 10:51		[forum:52509]
Pour XML & Acube,
Il faut clairement se mettre d'accord sur un format plutôt que chercher à l'imposer.

Voici une proposition , qu'en pensez-vous ?

Le format XML est défini selon la convention suivante :
• Nœud XML nommé comme le composant ACube avec attribut id pour l'identifiant
o Nœud properties composé d’un sous nœud par propriété
o Nœud childs composés d’un sous - nœud par composant enfant

Le nom d’un nœud propriété sera celui de la propriété (ie actuellement en Français)

RE: XML & Acube [ Répondre ]
Par : Cyril Rocheteau on 2007-02-19 10:43		[forum:52508]
L'uniformisation des composants est la voie à suivre.
A minima des composants constructeur zéro-aire et setters.
Pour nb de paramètres des constructeurs, la notion d'obligatoire ne doit pas intervenir (sinon on repart pour des constructeurs différenciés selon les composants).
Par exemple, l'identifiant est effectivement nécessaire pour tous les composants "avec données", il ne l'est plus pour les composants "de présentation"
C'est plus par rapport au modèle global des composants et leur cycle de vie.
par exemple, chaque composant est rattaché à un composant parent, peut-être que ce composant parent devrait être indiqué dans le constructeur.

Le plus simple est la normalisation des composants avec constructeur vide et setters

RE: XML & Acube [ Répondre ]
Par : Benjamin Leperchey on 2007-02-19 10:22		[forum:52507]
Nous utilisons avec JP Etienne des fonctions qui encapsulent les constructeurs avec des "dictionnaires". Par exemple, on écrit :

champChemin = creeElementFormText('CHEMIN', { libelle:'Chemin', maxLength:'255', size:'50' });

et ca appelle la fonction :

function creeElementFormText(id, parametres)
{
return new ElementFormText(
id,
parametres.xmlData,
parametres.value,
parametres.size,
parametres.maxLength,
parametres.libelle,
parametres.obligatoire,
parametres.statut,
parametres.tabIndex);
}

On en a 10 comme ça : rien de bien fantastique, mais ça évite les constructeurs avec 50 paramètres... Tant qu'à repenser les constructeurs, ça pourrait être une idée de proposer des utilitaires de ce genre. Ceci dit, avec des constructeurs zero-aires + des setters, on a quelque chose d'équivalent.



Juste une remarque : pour 90% (sinon 100%) des elements/composants, il faudrait préférer une version unaire du constructeur, car comme l'identifiant est la base de toute la gestion, il doit toujours être renseigné :

champChemin = new ElementFormText('CHEMIN');
champChemin.setLibelle('Chemin');
champChemin.setMaxLength('255');
champChemin.setSize('50');

RE: XML & Acube [ Répondre ]
Par : Xavier PRINCE on 2007-02-19 01:49		[forum:52498]
L'intérêt dans le cadre de GRaM sera effectivement de basculer le code pour générer le méta-xml ou le xml intermédiaire en fonction des besoins ce qui nous permettra de revenir sur une solution flux xml dans le cadre de la partir serveur (retrouvant ainsi les gains en terme de poids de flux).

RE: XML & Acube [ Répondre ]
Par : Xavier PRINCE on 2007-02-19 00:51		[forum:52495]
Comme je l'ai posté plus haut, suite aux différentes discussions vu ici, c'est effectivement sur ce double axe que nous partons avec comme coeur un metaxml permettant de définir : le structure du formulaire, les différents éléments le constituant, le lien vers le xml de data (suvant la même principe que pour le composant Tableau).

RE: XML & Acube [ Répondre ]
Par : Xavier PRINCE on 2007-02-19 00:44		[forum:52494]
Pour la langue, il est en effet visiblement nécessaire d'uniformisé celui-ci quand à la langue. Une des propositions en cours comme pour le Framework J2EE de passer l'ensemble des classe, méthodes et attributs en anglais en concervant des commentaires en francais.

Pour l'uniformisation des propriétés, elle passe pas ce renommage ainsi que certains complément sur certains éléments.
Mais aussi par la refonte des constructeurs
Une proposition pour cette refonte est de créer des constructeur sans argument et de compléter l'ensemble des classes avec les "setter" et "getter" nécessaires. En complément l'ensemble des fonctions EcrireBiend seraient compléter pour vérifier des les propriétés obligatoires ont bien été valorisé avec une valeur correcte.

RE: XML & Acube [ Répondre ]
Par : Xavier PRINCE on 2007-02-19 00:39		[forum:52493]
Pour le moment nous avons travailler à structurer un XML permettant déjà de géré l'ensemble des éléments de formulaires et d'en définir les différentes propriétés.
Ce premier format, ne permet pas de gérer de facon dissocié la définition des propriétés d'une éléments et sa (ou ses) valuer(s).

Le prochain format reprendra le même principe que le composant tableau afin de permettre de distinguer la défintion des éléments de formulaires et leur valorisation.

L'étape suivante consistera ensuite à définir la DTD du meta xml en prévoit deux modes de gestions :
- un mode basé sur une pré génération du code html/js/xml à partir d'une interface Ruby,
- un mode basé sur une génération à la volé en javascript.

Nous allons priviligiés dans un premier temps le premier mode ceux afin de mettre dans un premier temps en place une solution qui permettra de ne pas allourdir encore le code HTML généré à la volé coté client (surtout pour du code dans la dynamisme et pour le moment nul). Il est a noté que nous étudions aussi cette solution de prégénération pour le composant tableau afin d'aboutir là aussi à un volume de codes générés plus faible.

L'étape suivante comme prévue intialement sera pour nous la mise en place d'un outil Wysiwyg sous IDE Elcipse afin de permettre le création graphique de ce fichier meta xml et le déclenchement de la pré génération du code.

<i>PS:</i> je met à disposition la premiére version du fichier XML de gestion des éléments ainsi que l'ensemble du code permettant de gérer ce fichier et d'en faire la démonstration

RE: XML & Acube [ Répondre ]
Par : Cyril Rocheteau on 2007-02-05 18:00		[forum:52468]
1) Pour le bouton :
Les seuls composants gérés dans fw_groupe.js étaient les composants avec un libellé.
D'où le bug avec ElementFormButton.
C'est réglé dans la version postée ACube-XML-extended2.zip

2) Pour les colonnes, il faut rajouter des noeuds cells dans saisie-contenu-groupe.xml.
cf la version postée ACube-XML-extended2.zip

3) Sur le tableau HTML
c'est possible avec le code existant en enlevant le ComposantGroupe et avec le tableau dans la page HTML.
cf saisie-modele-html.html

4) l'idée est de préciser ce qu'est un formulaire Acube et sa déclinaison graphique.
Par exemple, la zone de validation du formulaire pourrait être en bas du formulaire et alignée à droite.
Les boutons seraient alors à placer systématiquement dans cette zone.

RE: XML & Acube [ Répondre ]
Par : Thierry RIGAL on 2007-02-03 23:29		[forum:52467]
Par souci de clarté je précise que mes deux post précédents ne sont relatifs qu'aux propositions de C.Rocheteau présentes dans la feature-request FRED et concernant XML-ACube.

Actuellement deux axes différents semblent se dessiner pour la génération de code client ACube :
- une approche dynamique liée à un fichier de méta-données XML embarqué dans le code applicatif (cf contributions de C.Rocheteau),
voire un formulaire dynamique utilisé dans un cadre très particulier (cf contribution de B. Leperchey),
- une approche "compilée" liée à un fichier de description (au format Excel) et interprété par du code java.
(cf contributions F.Bivaud).

Ces deux axes méritent à mon sens un examen attentif. L'approche dynamique semble assez ambitieuse, l'approche compilée semble être celle qui donnera e plus vite un résultat proche du code actuellement écrit dans les applications ACube.
Il y a peut-être une voie intermédiraire, à savoir un fichier xml de méta-données (ne décrivant que l'interface graphique) proche de celui utilisé pour l'approche dynamique qui pourrait ensuite être interprété pour produire les fichiers html, js et xml attendus.

TR

RE: XML & Acube [ Répondre ]
Par : Thierry RIGAL on 2007-02-03 23:11		[forum:52466]
le nouveau code se touve dans les features-request de FRED :
ACube-XML-extended.rar


TR

RE: XML & Acube [ Répondre ]
Par : Thierry RIGAL on 2007-02-03 23:10		[forum:52465]
J'ai ajouté le traitement des composants ElementFormTextArea et ElementFormCheckbox dans le fichier fw_loadXML.js à travers quelques méthodes supplémentaires et l'ajout de code dans la méthode loadFunctions...
La page saisie-tenue-groupe.html affiche bien l'ensemble des composants de façon dynamique.
Par contre je ne parviens pas à afficher le composant ElementFormButton.
J'ai écrit dans le javascript la méthode permettant de construire cet élément. Si quelqu'un parvient à l'affichage du bouton prière d'ajouter un post à ce thread!

J'ai une remarque de fond concernant les composants du fichier xml de métadonnées : la déclaration de la zone de groupe permettait dans le fichier html (associé au fichier js et xml) de construire un tableau html permettant d'organiser le "layout" des composants graphiques du formulaire. Il y avait la notion de lignes et de colonnes permettant d'agencer la présentation des composants du formulaire...
Actuellement le fichier xml de méta-données ne permet pas une telle disposition, les composant s'empilant dans une seule colonne.

Je pense qu'il sera nécessaire de revoir cette question et d'envisager le recours à un tableau html dans le fichier html pour disposer les composants à mois de trouver une autre solution.

TR

RE: XML & Acube [ Répondre ]
Par : Benjamin Leperchey on 2007-02-01 21:34		[forum:52464]
Une remarque : la page client de GRaM (consultation de rapports générés côté serveur) crée dynamiquement un formulaire à partir de la description des paramètres envoyée par le serveur.

L'implémentation gère aujourd'hui les SELECT à plusieurs niveaux et les TEXTBOX (non testé...) Voir le feature-request LISE pour le source. C'est très limité par ailleurs (pas de disposition avancée)

Si on garde l'optique d'une génération dynamique du formulaire (qui n'est pas nécessaire en règle générale, à mon avis la génération batch+customisation est préférable dans 99% des cas), il faudra reprendre la page de GRaM pour utiliser cette technologie.

RE: XML & Acube [ Répondre ]
Par : Cyril Rocheteau on 2007-01-17 15:02		[forum:52425]
voir le post dans 'outillage' pour la suite sur wysiwyg

RE: XML & Acube [ Répondre ]
Par : François BIVAUD on 2007-01-16 10:02		[forum:52422]
Les fichiers sont disponibles dans le feature request FRED.

RE: XML & Acube [ Répondre ]
Par : Steve PEGUET on 2007-01-15 19:05		[forum:52419]
L'approche est intéressante et un complèment d'information avec upload de fichiers dans l'outil de suivi correspondant est la bienvenue.

Merci d'avance pour cette contribution sur le sujet.

Steve.

RE: XML & Acube [ Répondre ]
Par : François BIVAUD on 2007-01-15 18:58		[forum:52418]
Bonjour,

Si nous pouvons apporter notre retour d'expérience sur ce sujet, voici quelques remarques :

1/ Normalisation JavaScript
Dans la version 2.1 du Framework Ergo, notre équipe de réalisation a parfois buttée sur certaine propriété des composants ACube. Par exemple l’ElementFormSelect correspond à l’élément Select et il semble intuitif de penser qu’il dispose de la propriété selectedIndex. Faire correspondre un maximum les composants du Framework à leur équivalent DOM améliore l’adaptation et la compréhension pour des développeurs ayant de bonne connaissance HTML.

2/ Normalisation XML
La normalisation XML facilite la génération de code et réduit le JavaScript mais à défaut obscurcie la compréhension et complique le code spécifique. Par exemple, si l’utilisateur souhaite une particularité spécifique à son besoin sur un tableau, le développeur doit intégrer le fonctionnement du ComposantTableau qu’il considérait comme une boite noir pour redéfinir les méthodes dont il a besoin de changer l’implémentation.
Si l’on fait disparaitre du JavaScript la construction du formulaire, composant, évènement, ect .. il faut aussi identifier ce qui peut être modifier dans le comportement du formulaire et permettre facilement au développeur de le redéfinir.

3/ Génération XML, JS et HTML
Pour le projet CEF nous avons utilisé un générateur de code au niveau client et serveur. Coté client ce générateur est développé en Java, il prend en entré des fichiers Excel enregistrés en XML et ressort un JS/XML/HTML et une Action Struts.
Nous utilisons un Excel par écran, la tâche complexe est de spécifier le fichier Excel composé de différents onglets correspondant aux propriétés de l’écran, tableau, formulaire, champs saisies, etc. ensuite il faut écrire le Template de génération mais ce travail n’est fait qu’une fois. Nous avons fait une approximation du pourcentage de code généré et cela correspond à nos attentes.
Cela à deux avantages, il y a moins de code à écrire donc moins d’erreur potentiel et notre équipe de réalisation commence à travailler sur un code JS/HTML/XML déjà bien structuré. L’inconvénient est que lors de besoin client spécifiques et hors périmètre du Framework, l’équipe de développement est désemparée car le Framework est une boite noire et une grosse partie du code est générée.

Si vous désirez plus d’informations, nous pouvons uploader un exemple de fichier Excel ainsi que nos templates client.

RE: XML & Acube [ Répondre ]
Par : Steve PEGUET on 2007-01-15 12:27		[forum:52414]
La roadmap est en cours de définition et est formalisée dans l'outil de gestion des Tâches sur l'Admisource dès qu'il y a des actions qui sont validées avec des acteurs identifiés dessus.

L'objectif dans un premier temps et justement d'en débattre par l'intermédiaire des forums pour dégager des concensus généraux et de partager l'ensemble des informations sur le sujet avant de clairement identifier la roadmap correspondante.

Il est donc important que chacun lance ses sujets en cours et partagent l'information pour qu'elle soit prise en compte par tous.

Après il y aura validation et affichage d'une roadmap claire.

Ce que contiendra la version 3.0 n'est pas encore définie et dépendera de ces discussions sur le forum et de l'état d'avancement des tâches correspondantes.
Il est donc préférable de communiquer sur des sujets et des tâches et pas sur des versions qui seront elles définies sous la forme de pallier sur cet ensemble et de package.

Steve.

RE: XML & Acube [ Répondre ]
Par : Cyril Rocheteau on 2007-01-15 11:23		[forum:52411]
Est-il possible d'inscrire cette v 3.0 dans la roadmap et les tâches à venir ?

par ex, :
la v3 intégre-t-elle autre chose que le XML ?
Y-a-t-il une normalisation des propriétés ?
Passe-t-on en Anglais ?

Ca permettrait d'y voir plus clair sur les évolutions A3,

Messages plus anciens
FEDER Powered By FusionForge Collaborative Development Environment Charte d'utilisation / Nous contacter / Mentions légales Haut de page