Surveiller ce forum | Commencer une nouvelle discussion

Hiérarchisé À plat Fils de discussion Ultime

Montrer 25 Montrer 50 Montrer 75 Montrer 100

RE: Lise 3.0.0 (Release Candidate) [ Répondre ] Par : Gilles PASQUEREAU on 2008-09-01 18:06

[forum:90300]

Quelques remarques sur le guide du développeur (version postée le 20/08/2008) : * Dans la partie Client, pour une fonctionnalité donné, il est intéressant que les fichiers html, js et xml porte le même nom. * pour la partie view de Struts, ne pas rendre obligatoire la génération des flux XML par un template JSP. Le terme préférable semble plus approprié. * Il faut préciser des règles d'écritures pour les JSP (utilisation de taglibs obligatoire ou pas, lesquels (JSTL, OGNL, autres), ...) * Il reste quelques références à des templates FTL. A supprimer.

RE: Lise 3.0.0 (Release Candidate) [ Répondre ] Par : Thierry RIGAL on 2008-08-20 16:36

[forum:87902]

Une archive rar publiée dans les features-request contient un document Word présentant des remarques sur la livraison du framework LISE 3.0.0 RC1 basé sur Struts2, Spring MVC et DAO et Ibatis ainsi que les 3 sous-projets structurant de LISE (fwacubej2ee, fwserveurj2ee et gabaritprojetacubej2ee). La livraison de LISE 3.0.0-rc1 comprend les sources et livrables de : · fwacubej2ee-3.0.0-rc1 (les jars librairies du framework ACube · fwserveurj2ee-3.0.0-rc1 (les jars librairies standards) · un projet Sample des propositions d'enrichissement de : -fwacubej2ee-3.0.0-rc1 (les jars librairies du framework ACube) -fwserveurj2ee-3.0.0-rc1 (les jars librairies standards) et un projet de gabarit (GabaritProjetACubeJ2EE-3.0.0-rc1) sont inclus dans l'archive.

RE: Lise 3.0.0 (Release Candidate) [ Répondre ] Par : Grégory Picavet on 2008-07-23 14:00

[forum:56827]

l'outil ibator sert à générer la couche dao uniquement, selon le modèle de transformation simplifié "une table génère une classe DAO et une classe VO". Normalement aucune logique métier ne réside dans cette couche, du moins au départ, car pour optimiser les recherches, de la logique métier apparaitra en partie dans les requetes SQL. C'est la couche service qui représente la logique métier et contient les règles de gestion. Elle peut être découpée indépendamment du modèle de la base (meme si généralement, on s'en rapproche). Et de plus plusieurs dao peuvent intervenir dans un service.

RE: Lise 3.0.0 (Release Candidate) [ Répondre ] Par : Marck Fraudeau on 2008-07-22 16:03	[forum:56362]
Le projet sample décrit dans la documentation correspond au Gabarit fournit dans la livraision [livrable-gabarit-lisej2ee-3.0.0-rc0.zip]

RE: Lise 3.0.0 (Release Candidate) [ Répondre ] Par : Thierry RIGAL on 2008-07-22 10:23	[forum:56207]
Dans le document "Guide du développeur" il est question du projet EDS/Indus/A3/MAEE/sample. celui-ci est décrit dans le document mais ne figure pas dans les livraisons. Peut-on le publier?

RE: Lise 3.0.0 (Release Candidate) [ Répondre ] Par : Thierry RIGAL on 2008-07-21 15:11	[forum:55775]
l'outil Ibator utilisé pour générer les classes de la couche intégration et vo ne peut-il pas permettre de générer la couche métier ? Dans le projet présenté par EDS comme étant un exemple de projet minimal la couche métier semble avoir été codée manuellement.

RE: Lise 3.0.0 (Release Candidate) [ Répondre ] Par : Thierry RIGAL on 2008-07-10 16:57	[forum:53370]
je reste favorable à une modularité des composants ACube et à l'indépendance du gabarit par rapport aux librairies.

RE: Lise 3.0.0 (Release Candidate) [ Répondre ] Par : Steve PEGUET on 2008-07-10 10:33

[forum:53369]

Aujourd'hui ce qui permettait de garantir la cohérence entre les frameworks (.jar) et le gabarit était le plugin Eclipse ACube. Je ne vois donc pas l'utilité de s'orienter vers freemaker. L'utilisation du plugin Eclipse come garant de la cohérence d'ensemble ACube est une nécessité sinon il risque de ne plus qu'avoir des divergences. Ainsi, notre orientation de notre côté vers Spring MVC permettera d'avoir un gabarit dédié à Spring MVC choisi à l'aide du plugin Eclipse ACube. Si le choix par ce plugin est Struts2 alors c'est l'autre gabarit de projet qui sera instancié. Donc intégrer le gabarit dans les .jar doit être complètement exclue. Si nous allons vers cette orientation nous enlevons toute la modularité d'ACube pour s'orienter vers une fermeture non souhaitable. Donc merci de prévenir si poursuite vers freemaker car révision complète alors de la stratégie.

RE: Lise 3.0.0 (Release Candidate) [ Répondre ] Par : Kadvaël COIFFET on 2008-07-09 15:02	[forum:53367]
L'intérêt de freemarker est de pouvoir incorporer les pages dans les jars du framework et non pas dans un gabarit avec risques de modifications par les projets. Les pages freemarker sont rechercher dans tout le classpath et aussi dans les jars. Cela peut permettre d'avoir un framework composé uniquement d'un jar et non pas d'un framework composé d'un jar et d'un gabarit fortement couplé.

RE: Lise 3.0.0 (Release Candidate) [ Répondre ] Par : Gilles PASQUEREAU on 2008-07-09 14:53

[forum:53366]

Quelques remarques ou pistes de travail : - Il pourrait être intéressant de séparer les packages de core LISE 3.0 et les packages de compatiblité LISE 2.x en 2 jars distincts. Les éléments de compatibilité pourraient être considérés comme deprecated. - Il ne me semble pas très opportun d'intégrer JDBCWrapper avec Spring/Ibatis. Les anciennes fonctionnalités des applications 2.x migrées en 3.0 continuent de fonctionner avec JDBCWrapper. Les nouvelles fonctionnalités utilisent Spring/Ibatis. En cas de nécessité d'imbrication (transactionnelle en particulier) de nouveaux et d'anciens services, il semble plus simple et pragmatique de réecrire les anciens services. - Dans le gabarit, on trouve des templates freemarker. Il y est aussi fait allusion dans le guide du développeur. Il ne me semble pas opportun d'ajouter un xième composant permettant de générer des flux XML (XSL et JSP suffiront à couvrir tous les cas

RE: Lise 3.0.0 (Release Candidate) [ Répondre ] Par : Marck Fraudeau on 2008-07-03 18:30

[forum:53361]

Le fichier de configuration variable_xx.xml contenait avant les classes Menu, Entête, les autorisations et les libelles des messages d'erreur. Désormais, les autorisations ont été déplacées dans le strut.xml, les messages d'erreurs ont été déplacés dans des fichiers de properties. Il reste dans ce fichier uniquement la configuration des classes Menu et Entête. Peut-être pourront nous penser à une nouvelle solution technique pour le Menu et l' Entête, j'invite la communauté à participer à cette discussion, ici: https://admisource.gouv.fr/tracker/index.php?func=detail&aid=647&group_id=8&atid=217

RE: Lise 3.0.0 (Release Candidate) [ Répondre ] Par : Thierry RIGAL on 2008-07-02 10:05

[forum:53358]

L'intérêt d'un gabarit ACube Projet J2EE est de proposer un canevas de projet minimal et pouvant servir d'exemple initial...Nous souhaiterions que les classes Menu et Entete figurent dans le gabarit, elles montrent en outre comment utiliser les données du fichier de configuration variable_xx.xml.... Cela permettrait d'avoir aussi un premier exemple d'action générant un flux xml... Merci d'y penser dans la prochaine proposition de livraison du gabarit. Par ailleurs le gabarit porte le nom de Gabarit ACube J2EE (LISE est plus générique, cela désigne l'ensemble du code serveur qui pourrait être dans certains cas en php ou en C# ou autre langage...

RE: Lise 3.0.0 (Release Candidate) [ Répondre ] Par : Kadvaël COIFFET on 2008-06-30 16:19	[forum:53349]
Pour la transformation des classes il n'y aucune modification à apporter aux classes existantes. Sinon les classes menu et entête font parties du reste à faire sur la nouvelle pile.

RE: Lise 3.0.0 (Release Candidate) [ Répondre ] Par : Kadvaël COIFFET on 2008-06-30 16:16	[forum:53348]
Effectivement la classe acube.framework.compatibilityLiseV2.strutscx.StrutsCXConstants à été renommée en acube.framework.webcomp.technical.StrutsCXConstants. Cette classe est deprecated car elle n'est utile que pour les migrations d'application. Les nouvelles applications basées sur LISEv3 ne doivent plus utiliser cette classe.

RE: Lise 3.0.0 (Release Candidate) [ Répondre ] Par : Thierry RIGAL on 2008-06-30 16:10	[forum:53347]
autre problème : je ne trouve pas de package acube.framework.compatibilityLiseV2.strutscx.StrutsCXConstants dans les sources livrées du framework LISE 3.0.0 par contre il y a un package acube.framework.webcomp.technical.StrutsCXConstants dont l'unique classe est deprecated... comment remplacer les imports de StrutsCXConstants ?

RE: Lise 3.0.0 (Release Candidate) [ Répondre ] Par : Thierry RIGAL on 2008-06-30 16:06	[forum:53346]
La transformation des classes Actions décrite dans le document de migration n'est pas claire et n'est assortie d'aucun exemple. Il n'existe qu'une seule classe Action dans le gabarit projet LISE J2EE 3.0.0, où sont passées les classes Menu et Entete qui permettaient de se faire uen idée de la mécanique de l'action?

Lise 3.0.0 (Release Candidate) [ Répondre ] Par : Kadvaël COIFFET on 2008-06-26 17:19

[forum:53345]

Comme prévu (et avec un peu de retard), La version 3.0 de LISE en "release candidate" est disponible dans les feature requests. Cette version est basée sur Struts2/Spring/IBatis et correspond au packaging des différents prototypes postés sur le sujet. Un des points forts de cette version est de permettre une migration rapide des applications LISE 2.x vers LISE 3.0. Un guide de migration explique les étapes de la migration et un petit outil de migration permet de la faciliter en migrant les fichiers de configuration. La migration d'un projet LISE v2.x en LISE v3.x ne nécessite aucune modification de code pour les actions classiques (cad qui surchargent le BaseAction). Les seuls impacts sont pour les actions qui effectuent des redirections ou des traitements particuliers qui doivent maintenant utiliser Struts2 en remplacement de Struts1. La migration ne nécessite pas non plus de modification des feuilles de style XSLT. (Attention toutefois pour les PDF, FOP est passé en version 0.94 au lieu de 0.20) Le zip contient aussi un guide de développement et un gabarit pour les nouveaux projets. Le gabarit intègre des exemples pour toutes les couches d'une application (Action, Service, DAO). A noter que le gabarit intègre des classes communes qui seront probablement intégrer au framework. Voici les élements que nous avons repéré comme à faire, à compléter ou à valider : - BaseActionFile (non testé & à priori inutile dans la version 3.0) - Présence de Fop 0.9x à la place de fop 0.25 - Intégration d'un jdbcwrapper fonctionnant avec iBatis et Spring DAO (cf. https://admisource.gouv.fr/tracker/index.php?func=detail&aid=587&group_id=8&atid=217 pour un exemple) - absence du gabarit projet sous forme de plugin eclipse … - Exports Excel/CSV à migrer vers Struts2 (Ils fonctionnent quand même sur cette version) En vue d'obtenir la 3.0 définitive, Merci de faire vos remarques et de poster vos modifications au plus tôt dans ce thread.