Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
ekse
Basé sur le concept «model-driven architecture», le logiciel Leonardi automatise dans son intégralité le processus de réalisation des IHM.
Une version gratuite (incluant un plug'in Eclipse) est disponible sur : http://www.lyria.com
Exemples de réalisations (démos) disponibles sur le site http://www.lyria.com
Très intéressant.
Je travaille également avec le client RCP d'Eclipse. Quelles ont été les étapes de réalisations pour passer en client léger ? Avez-vous refait toutes les IHM ou existe-t-il des parties communes ?
Eric.
Basé sur le concept «model-driven architecture», le logiciel
Leonardi automatise dans son intégralité le processus de réalisation
des IHM.
Une version gratuite (incluant un plug'in Eclipse) est disponible sur :
http://www.lyria.com
Exemples de réalisations (démos) disponibles sur le site
http://www.lyria.com
Très intéressant.
Je travaille également avec le client RCP d'Eclipse. Quelles ont été les
étapes de réalisations pour passer en client léger ? Avez-vous refait
toutes les IHM ou existe-t-il des parties communes ?
Basé sur le concept «model-driven architecture», le logiciel Leonardi automatise dans son intégralité le processus de réalisation des IHM.
Une version gratuite (incluant un plug'in Eclipse) est disponible sur : http://www.lyria.com
Exemples de réalisations (démos) disponibles sur le site http://www.lyria.com
Très intéressant.
Je travaille également avec le client RCP d'Eclipse. Quelles ont été les étapes de réalisations pour passer en client léger ? Avez-vous refait toutes les IHM ou existe-t-il des parties communes ?
Eric.
Nbo
Bonjour, en fait le principe est le suivant: 1) description des données en XML (peut etre saisi dans une interface graphique appelée Studio ou par import d'un fichier XMI (UML) ou par découverte d'une base de données (Metadata).
2) A partir des données, une couche de persistance vers différent connecteurs (Sql, xml, etc...) permet de charger un modele objet des données en mémoire avec gestion de caches.
3) Ensuite une couche de controle exécute des actions (paramétrées en XML) sur les données. Il existe une trentaine d'action pré codées pour ne pas réinventer la roue (consulter/modifier/lister/filtrer/trier etc ...) Ces controleurs produisent des 'vues'
4) Les vues pourraient etres des bibliotheques AWT/SWING/SWT ou des JSP mais afin de rentre le code portable vers tous les afficheurs, les vues sont décrite dans des classes abstraites (Arbre DOM XML en mémoire). Le controleur produit alors une vue par exemple "action _consult sur l'objet User23)" produit une description de la vue : fenetre de dialogue, barre de tritre, liste des champs, des boutons OK/cancel etc...
5) un afficheur traduit l'abre DOM dans l'affichage adequat : AWT/SWING/SWT pour lee client lourt HTML/DHTML pour le client léger.
Il y a un white paper et des demos sur le site, sinon télécharger la version gratuite et regarder les exemples dans leoncontrib
cordialement. Nicolas BODIN
Bonjour,
en fait le principe est le suivant:
1) description des données en XML (peut etre saisi dans une interface
graphique appelée Studio ou par import d'un fichier XMI (UML) ou par
découverte d'une base de données (Metadata).
2) A partir des données, une couche de persistance vers différent
connecteurs (Sql, xml, etc...) permet de charger un modele objet des
données en mémoire avec gestion de caches.
3) Ensuite une couche de controle exécute des actions (paramétrées
en XML) sur les données. Il existe une trentaine d'action pré codées
pour ne pas réinventer la roue
(consulter/modifier/lister/filtrer/trier etc ...)
Ces controleurs produisent des 'vues'
4) Les vues pourraient etres des bibliotheques AWT/SWING/SWT ou des JSP
mais afin de rentre le code portable vers tous les afficheurs, les vues
sont décrite dans des classes abstraites (Arbre DOM XML en mémoire).
Le controleur produit alors une vue par exemple "action _consult sur
l'objet User23)" produit une description de la vue : fenetre de
dialogue, barre de tritre, liste des champs, des boutons OK/cancel
etc...
5) un afficheur traduit l'abre DOM dans l'affichage adequat :
AWT/SWING/SWT pour lee client lourt HTML/DHTML pour le client léger.
Il y a un white paper et des demos sur le site, sinon télécharger la
version gratuite et regarder les exemples dans leoncontrib
Bonjour, en fait le principe est le suivant: 1) description des données en XML (peut etre saisi dans une interface graphique appelée Studio ou par import d'un fichier XMI (UML) ou par découverte d'une base de données (Metadata).
2) A partir des données, une couche de persistance vers différent connecteurs (Sql, xml, etc...) permet de charger un modele objet des données en mémoire avec gestion de caches.
3) Ensuite une couche de controle exécute des actions (paramétrées en XML) sur les données. Il existe une trentaine d'action pré codées pour ne pas réinventer la roue (consulter/modifier/lister/filtrer/trier etc ...) Ces controleurs produisent des 'vues'
4) Les vues pourraient etres des bibliotheques AWT/SWING/SWT ou des JSP mais afin de rentre le code portable vers tous les afficheurs, les vues sont décrite dans des classes abstraites (Arbre DOM XML en mémoire). Le controleur produit alors une vue par exemple "action _consult sur l'objet User23)" produit une description de la vue : fenetre de dialogue, barre de tritre, liste des champs, des boutons OK/cancel etc...
5) un afficheur traduit l'abre DOM dans l'affichage adequat : AWT/SWING/SWT pour lee client lourt HTML/DHTML pour le client léger.
Il y a un white paper et des demos sur le site, sinon télécharger la version gratuite et regarder les exemples dans leoncontrib