Surveiller ce forum | Commencer une nouvelle discussion Commencer une nouvelle discussion
StrutsACube - lecture des fichiers de conf [ Répondre ]
Par : Benjamin Leperchey on 2007-02-27 10:59		[forum:52539]
Pour partager le résultat de la lecture des fichiers de config : aujourd'hui, les mapping sont mis dans un objet stocké dans StrutsAcubeServlet, il faudrait les mettre dans un endroit accessible par l'ensemble du projet. L'objectif est la réutilisation des "mappings" par le XmlWrapper pour effectuer une conversion XML->Objet Java.

Une question générale à ce sujet : est-il vraiment rédhibitoire de lire deux fois les fichiers de config ?

Si j'ai bien suivi, l'objectif est de brancher les applications ACube les unes aux autres, pas de relire des flux XML générés par la même application... Il me semble donc logique d'avoir deux jeux de définitions de mapping (qui peuvent se recouvrir en partie) : un jeu "API" qui décrit les XML générés par les autres applications, et un jeu "propriétaire" qui décrit comment générer les XML dans notre application. StrutsACube utiliserait le jeu "propriétaire" et le XMLWrapper le jeu "API".

On pourrait dans ce cas mettre la config dans des instances indépendantes stockées localement (dans StrutsACubeServlet, dans un cache XmlWrapper).

Il me semble plus généralement qu'utiliser un cache statique (c'est-à-dire gérer/utiliser la config à travers des méthodes statiques) est en général risqué à long terme : si je veux me connecter à plusieurs applications qui utilisent des mappings similaires pour des objets différents (par exemple, la balise "PERSONNE" représente un simple login/mdp pour l'une et une personne physique --avec nom, adresse, profession, email etc-- pour l'autre) on va avoir un problème.

En utilisant des instances différentes, on peut gérer différentes configurations en même temps, et donc éviter ce problème.

Dites moi si j'ai tout faux.



S'il faut effctivement utiliser un cache statique, il me semble intéressant d'utiliser quand même le digester, plutôt que de reprendre le fichier de config "à la main" en DOM. Je vois deux méthodes :

1) faire en sorte que le digester remplisse un objet qu'on copie à la main avec des méthodes statiques à la fin du traitement :
// l est l'objet qu'on va faire remplir par le digester
List<Mapping> l = new ArrayList<Mapping>();
digester.push(l);
/* ici, les règles */
digester.parse(inputStream);

// on copie le résultat dans la classe MappingCache
for (Mapping m : l)
MappingCache.addMapping(l)


2) définir une règle spécifique, et l'utiliser à la place de "setProperty" :
// on crée l'objet mapping
digester.addObjectCreate("mappings/mapping",Mapping.class);
digester.setProperties("mappings/mapping");
// AddMappingRule est ma règle "custom" qui appelle la méthode statique addMapping de MappingCache
Rule addMappingRule = new AddMappingRule();
digester.addRule("mappings/mapping", addMappingRule)


La première est sans doute la plus simple.
Qu'en pensez-vous ?

RE: StrutsACube, paramétrage & ActionForward [ Répondre ]
Par : Thierry RIGAL on 2007-02-22 18:17		[forum:52523]
La nouvelle compilation de StrutsACube (version 3.0 beta1) est disponible sur admisource, au niveau de Lise-feature-request. L'archive contient le projet complet (sources du jar et exemples). Sous eclipse ce projet est de type "wtp web dynamique".

Quelques changements par rapport à la précédente compilation :

AVANT :
- les propriétés extension, stylesheet sont des propriétés de l'Action. (cf struts-config.xml)
MAINTENANT :
- les propriétés extension, stylesheet et dataRoot sont des propriétés de l'ActionForward héritant de StrutsACubeForward (qui a en outre remplacé en partie StrutsACubeData mais qui ne contient plus les data).

Le contenu du package acube.framework.strutsacube.output a été révisé et un nouveau package a été créé : acube.framework.strutsacube.output.impl.
Les "outputs" sont de type SimpleOutput (sérialisation sans feuille de style) , FopOutput ou XsltOutput (sérialisation avec feuille de style) . Quelques simplifications dans la classe StrutsACubeServlet qui traite après initialisation deux objets placés dans la requête : strutsACubeData et strutsACubeConfig.

Le reste sans grand changement.

TR

RE: StrutsACube, paramétrage & ActionForward [ Répondre ]
Par : Benjamin Leperchey on 2007-02-21 17:23		[forum:52520]
Un point plus précis sur la gestion des erreurs : elle est complètement indépendante de l'output en cas de succès.

Plus concrètement, la BaseAction appelle les fonctions "utilisateurs", qui peuvent lever des exceptions. S'il n'y a pas d'exception, on utilise le forward "success" en passant les beans en paramètre. Sinon, on en extrait des ErrorVO, qu'on passe en paramètre au forward "error".

J'ai mis dans le struts-config exemple un "global-forward" error, qui est donc utilisé par toutes les actions dérivées de BaseAction en cas d'erreur :

<forward name="error" path="/StrutsACubeServlet"
className="acube.framework.strutsacube.output.impl.XsltOutputForward">
<set-property property="styleSheet" value="/WEB-INF/xsl/errors.xsl"/>
</forward>

on voit ici qu'on utilise une transformation XSLT (XsltOutputForward), et que la feuille de style est "/WEB-INF/xsl/errors.xsl" (c'est celle qui génère les erreurs pour FRED)

Chaque action est libre de définir indépendamment les forward "success" et "error". Par exemple, dans le cas d'un flux PDF :

<action path="/Sticker.pdf" type="acube.framework.strutsacube.action.Sticker">
<forward name="success" path="/StrutsACubeServlet"
className="acube.framework.strutsacube.output.impl.FopOutputForward">
<set-property property="styleSheet" value="/WEB-INF/xsl/sticker-pdf.xsl"/>
</forward>
<forward name="error" path="/StrutsACubeServlet"
className="acube.framework.strutsacube.output.impl.FopOutputForward">
<set-property property="styleSheet" value="/WEB-INF/xsl-fo/errors.xsl"/>
</forward>
</action>

On pourrait même générer des types de flux différents pour success et error (même si ce n'est sans doute pas une bonne idée...)


A creuser : utilisation de la propriété "extends", qui --pour ce que j'en comprends-- est censée permettre de réutiliser des forwards en ne rappelant que les propriétés modifiées. Je n'ai personnellement pas réussi à la faire marcher, mais ça permettrait de faire des gabarits généraux, et de les instancier pour les actions (typiquement, un gabarit FOP et des instances qui précisent la feuille de style)

RE: StrutsACube, paramétrage & ActionForward [ Répondre ]
Par : Benjamin Leperchey on 2007-02-19 00:21		[forum:52492]
J'ai posté sur le fetaure-request une évolution de StrutsACube pour prendre en compte les propositions que j'ai faites relatives aux ActionForward. Les fichiers fournis sont à mettre dans l'arborescence du projet StrutsACube :

- la BaseAction envoie deux objets à StrutsACube : un objet "data" et un objet "config"
- selon le type Java de "config", une "Output" est choisie. Elle se charge de relire "config" pour afficher correctement "data" (qui a été sérialisé en XML au préalable)

Pour utiliser le mécanisme Struts, les objets "config" sont encapsulés dans des classes qui héritent de ActionForward (qui agissent comme des délégués) : la BaseAction récupère le foward normalement, en extrait "config" et le passe à StrutsACube. On pourrait utiliser directement les ActionForward comme "config", mais ça lie très fortement à Struts.


Bonus par rapport à la version précédente : on peut utiliser la même classe action pour différents formats : par exemple, Sticker.java sert à produire du XML, du HTML et du PDF, simplement en changeant le "forward" dans struts-config.xml (et seulement dans struts-config.xml).


Par ailleurs, j'ai aussi sorti la gestion spécifique des erreurs de StrutsACube : en cas d'erreur, la BaseAction forwarde à "error" (au lieu de "success"), ce qui permet d'utiliser toute la souplesse de StrutsACube pour paramétrer indépendamment les erreurs des beans normaux.


Voir struts-config.xml pour la configuration : on voit que le type de sortie (sans XSLT, avec XSLT, ou FOP) est choisi en changeant le type du "forward". Les propriétés supplémentaires sont ajoutées par "<set-property>" sur le forward.

Le fichier strutsacube-config.xml n'a pas changé, à part que les clés des Output ne sont plus des extensions, mais le type des objet "config".



Il resterait quelques points à corriger avant une version finale -- désolé, pour comprendre ce qui suit, il faut avoir le code sous les yeux :

- gestion du debugxml, et de la sérialisation du modèle : StrutsACubeServlet teste la présence d'une feuille de style pour savoir s'il faut mettre la session et la requête, mais ne s'en sert pas par ailleurs. Ca serait sans doute mieux de pousser la sérialisation dans le Output. Le plus simple serait de passer le "SerializerFactory" à la fonction "init" des Output.

- gestion du cache des feuilles de style : il est désactivé d'office, c'est pratique mais catastrophique pour les performances (ça coûte cher de compiler une feuille de style), il faudrait trouver un moyen de le rendre paramétrable globalement -- nota : le problème était déjà présent dans la version 0.1

- il faudra recommenter/mettre à jour les commentaires -- je veux bien m'en charger, mais là il est un peu tard...

RE: StrutsACube, paramétrage des forwards [ Répondre ]
Par : Benjamin Leperchey on 2007-02-16 19:04		[forum:52491]
A creuser : utilisation des "global-forward" de Struts pour éviter de copier/coller des définitions complexes.

Autre proposition, pour rendre le traitement des erreurs plus générique : mettre tout le traitement spécifique des erreirs de StrutsACubeServlet dans une Output dédiée (ou plutôt des Output dédiées), et définir au niveau de chaque action deux forward : un "success" (cas normal) et un "error" (qui utiliserait les Output dédiés)

Ainsi, on simplifie encore StrutsACubeServlet, et on rend plus souple la gestion des erreurs : formatage spécial, type d'erreur différents etc.



Autre Output spécialisé qui pourrait être pratique : le FileVOOutput. Ainsi, la FileVOBaseAction n'aurait qu'à pousser une FileVO à StrutsACube, qui utiliserait une Output spécifique. Ca me semble coller de plus près au modèle MVC, et permet d'utiliser la souplesse de la configuration StrutsACube pour gérer les FileVO. Plus généralement, plus il y a de code "en dur" dans la BaseAction, plus il faudra revenir dessus, avec des risques de régression -- qui sont critiques pour la brique de base de toute une application.

RE: StrutsACube [ Répondre ]
Par : Benjamin Leperchey on 2007-02-12 00:18		[forum:52488]
A ce sujet, une suggestion, pas si lourde qu'elle n'en a l'air :

Pour rendre les Output paramétrables au delà de ce qu'on pourrait imaginer aujourd'hui, le plus simple serait de remplacer StrutsACubeData par un l'ActionForward (ou son équivalent) et de laisser le soin à l'Output de le relire : en le surchargeant, on pourrait ajouter des propriétés spécifiques à l'Output en question (nom du fichier où on voudrait écrire, infos pour les logs, ou autre)

StrutsACubeServlet ne lirait que le strict minimum de l'ActionForward (donnees, erreurs, et "extension")

Ca aurait l'avantage qu'on ne préjuge aujourd'hui rien sur ce qu'on voudrait faire dans StrutsACubeServlet dans le futur.



On pourrait même utiliser le *type* de l'ActionForward comme clé pour choisir la vue, au lieu de l'extension utilisée aujourd'hui.

Par exemple si je veux faire du FOP, je vais écrire dans struts-config.xml

<forward className="acube.strutsacube.forward.FOPOutput">
<set-property name="styleSheet" value="..." />
</forward>

Si je veux faire du XML "simple" :

<forward className="acube.strutsacube.forward.XmlOutput">
<set-property name="styleSheet" value="..." />
</forward>
(attribut styleSheet optionnel)

et dans struts-acube-config, j'écrirai :

<outputs debugMode="true">
<output inputType="acube.strutsacube.forward.XmlOutput"
className="acube.framework.strutsacube.output.PlainTextOutput"
errorsStyleSheet="/WEB-INF/xsl/errors.xsl" />

<output inputType="acube.strutsacube.forward.FOPOutput"
className="acube.framework.strutsacube.output.FopOutput"
errorsStyleSheet="/WEB-INF/xsl-fo/errors.xsl">
<set-property name="fopConfigFile"
value="/WEB-INF/userconfig.xml" />
</output>
</outputs>

C'est un poil plus lourd, mais à mon avis nettement plus souple et cohérent que le paramétrage de la vaersion alpha.

J'estime la charge à une grosse journée de travail : modification de la BaseAction, déplacement de code de StrutsACubeServlet dans les Output et modification cosmétiques de la gestion des extensions dans StrutsACubeServlet (on change simplement de clé).

Qu'en pensez-vous ?

RE: StrutsACube, découpage des fonctionalités [ Répondre ]
Par : Benjamin Leperchey on 2007-02-12 00:04		[forum:52487]
Plus généralement, à mon avis, StrutsACubeAction fait trop de choses dans le découpage actuel des fonctionalités.

Le principe retenu dans l'architecture de StrutsACube est de rendre le maximum de choses paramétrables : langues, sérialisation, formats de sorties etc. Le paramétrage se fait à deux niveaux :
1) les implémentations fournies sont paramétrables, mais surtout
2) on peut changer d'implémentation en ajoutant des classes et en changeant le fichier de configuration.

Le seul point qu'on ne pourra pas remplacer, c'est bien sûr le point d'entrée, c'est-à-dire StrutsACubeServlet.

Pour rendre la brique StrutsACube dans son ensemble la plus souple possible, il faut à mon avis sortir le maximum de fonctionalités de cette classe, et lui laisser le rôle de chef d'orchestre :
1) lecture des fichiers de configuration à l'initialisation
2) pour chaque requête, récupération des paramètres et des données, récupération des objets nécessaires à la transformation (en consultant la configuration) et appels de méthodes de haut niveau sur ces objets : sérialisation en XML et écriture sur le flux de sortie (avec transformation si besoin)

Pour être plus concret, je propose :
1) de sortir toute la transformation XSL de StrutsACubeServlet, et de la remettre dans les Output
2) pendant qu'on y est, comme je le disais, d'y mettre aussi la gestion des headers HTTP (type MIME en particulier)
3) de créer des Output pour les debugxml pour rester dans le moule général
4) de mettre ailleurs la gestion des extensions -- plutôt du côté de la BaseAction à mon avis, cf la discussion sur les ActionForward
5) remplacer les SpecificAction par des output spécialisés.

Nota : seul les points no 4,5 ont un impact sur la partie "visible" de StrutsACube (la configuration et l'utilisation), le reste tient plutôt de l'organisation interne du code.

RE: StrutsACube [ Répondre ]
Par : Thierry RIGAL on 2007-02-06 20:52		[forum:52470]
J'ai mis en ligne un guide de configuration de StrutsACube et d'installation de StrutsACubeDemo au niveau des features-request LISE-J2EE.

RE: StrutsACube - fichiers de propriétés mult [ Répondre ]
Par : Benjamin Leperchey on 2007-01-30 20:49		[forum:52463]
Les briques ajoutées au framework serveur (LISE, GRaM, Struts Validator etc.) utilisent des codes pour les messages d'erreur.

Ajourd'hui, toutes les ressources "localisées" de StrutsACube sont dans un unique fichier. Ca pose un problème de maintenance sur ces composants : si les messages d'erreur de GRaM changent d'une version à l'autre, il faudra modifier les fichier de propriétés *de l'application* pour chaque langue lors de l'upgrade.

Même en se limitant au périmètre de l'application (hors erreurs techniques du framework), ce n'est pas très pratique d'avoir dans le même fichier les messages d'erreur et le libellés divers.

Ca serait beaucoup plus pratique d'utiliser plusieurs fichiers de propriétés.

Je propose les définitions suivantes dans les fichiers de config StrutsACube :

<properties-file name="erreurs-gram" path="/WEB-INF/erreurs-gram.xml">
<version locale="en" path="/WEB-INF/erreurs-gram-en.xml"/>
<version locale="de" path="/WEB-INF/erreurs-gram-de.xml"/>
</properties-file>
<properties-file name="libelles" path="/WEB-INF/properties.xml"/>

Ici, le fichier de propriétés pour GRaM propose trois versions : une par défaut (typiquement en français), une en anglais et une en allemand. Le fichier de propriété de l'application a une seule version, qui sera utilisé pour toutes les langues.

Evidemment, plus de référence aux fichiers de propriétés dans la configuration des langues (il ne resterait plus que l'encodage)...




Dans le flux XML passé à la feuille de style, le contenu de chaque fichier de propriété serait encadré par <properties> et le nom donné au fichier. En anglais :

<root>
...
<properties>
<erreurs-gram> [contenu de /WEB-INF/erreurs-gram-en.xml] </erreurs-gram>
<libelles> [contenu de /WEB-INF/properties.xml] </libelles>
<properties>
...
</root>

En hongrois :

<root>
...
<properties>
<erreurs-gram> [contenu de /WEB-INF/erreurs-gram.xml] </erreurs-gram>
<libelles> [contenu de /WEB-INF/properties.xml] </libelles>
<properties>
...
</root>



Ca impacte la lecture des fichiers de config (règles à changer + factory à écrire sur le modèle des langues, des outputs etc), la gestion des langues (enlever la référence au fichier de config), et la servlet StrutsACube (dans le cas ou on met le fichier de propriétés). Il doit y en avoir pour quelques jours de travail au maximum.

Je trouve qua ça vaudrait le coup de le mettre directement dans la version 3.0. Qu'en pensez-vous ?

RE: StrutsACube - validator [ Répondre ]
Par : Benjamin Leperchey on 2007-01-30 20:25		[forum:52462]
Oui, c'est intéressant. Il y a à mon avis deux questions "cruciales" :
1) la gestion des erreurs en général
2) la gestion de messages d'erreur en particulier.

Le reste devrait marcher sans difficultés : il faut simplement (mais c'est une modification d'interface, donc à prévoir le plus tôt possible) passer l'objet ActionForm à la fonction abstraite qui effectue le traitement. Le prototype deviendrait :

protected abstract Object getBeans(ActionForm form, HttpServletRequest request, HttpServletResponse response);

Ensuite, au lieu d'utiliser les méthodes statiques de GetRequest, on utiliserait le formulaire. Au lieu de :

int id = GetRequest.getInt("id");

on écrirait :

int id = (Integer)form.get("id");

Ca serait bien de mettre les cast dans des méthodes statiques de getRequest, pour gérer propreent les cas d'erreur :

int id = GetRequest.getInt(form, "id");





Sur la gestion des erreurs : si je ne me trompe pas, Struts mets le ActionMessages renvoyé par la méthode .validate() du ActionBean dans un attribut de la requête. Il faudrait donc, au démarrage de la BaseAction, chercher les erreurs de validation, dans cet attribut et, s'il y en a, les mettre dans des ErrorVO puis forwarder le tout à StrutsACube sans appeler getBeans

Note: faire de cette gestion des erreurs dans méthode protected, pour que l'action puisse quand même faire quelque chose en cas d'erreur de validation des paramètre: erreurs non bloquantes, log particulier ou autre.

Sur les messages : j'ai l'impression que les ActionMessage qui contiennent les messages d'erreurs ressemblent pas mal aux ErrorVO. On devrait pouvoir configurer le validator en lui passant les codes d'erreurs que StrutsACube irait chercher comme un grand dans les fichiers properties-XX.xml



Il faudrait essayer pour de vrai, pour voir à quoi ça ressemble.

Plus généralement, si on en arrive là, il faudrait découper les fichiers de propriétés pour les messages, sinon ça va vite être le bazar. Je lance un autre thread sur le sujet.

RE: StrutsACube [ Répondre ]
Par : Steve PEGUET on 2007-01-30 19:00		[forum:52461]
Excellente idée pour la mécanique de validation côté serveur...

Cette idée a été identifiée de notre côté mais pas prioriser dans notre champs d'étude.

Si tu as le temps d'identifier les efforts (analyse d'impacts) nécessaires d'adaptation de StrutsACube pour intégrer cette demande, on pourrait alors mieux l'intégrer dans sa roadmap.

Merci d'avance pour cette petite étude si accord.

RE: StrutsACube [ Répondre ]
Par : Grégory Picavet on 2007-01-26 22:14		[forum:52457]
Effectivement je n'avais pas vu cette classe :)
Cela dit pourquoi ne pas proposer une classe "StrutsAcubeOptionList" par exemple, spécialisée dans la génération du flux xml du composant ElementFormSelect ? idem pour d'autres composants dont le flux est normalisé (s'il y en a ?)

Autre point qui n'a rien à voir : j'avais essayé il y a quelques temps d'utiliser des ActionForm (et DynaActionForm), en autre pour pouvoir utiliser le mécanisme de validation coté serveur. Cependant cela demandait une refonte de BaseAction et j'ai laissé tombé. Il y a un chantier pour permettre ca dans StrutsAcube?

RE: StrutsACube [ Répondre ]
Par : Benjamin Leperchey on 2007-01-26 19:52		[forum:52456]
Pour le même genre de fonctionalité, voir la classe StrutsACubeMap. C'est en fait juste un Map<String,Object>, mais la sérialisation en XML est spéciale :

Object getBeans(request,response) {

StrutsACubeMap data = new StrutsACubeMap();
data.put("ID","toto");
data.put("NUMERO",37);

StrutsACubeMap innerData = new StrutsACubeMap();
innerData.put("X",false);
innerData.put("Y",3.7);

data.put("IMBRIQUE",innerData);

return data;
}

renvoie

<DATA>
<ID>toto</ID>
<NUMERO>37</NUMERO>
<IMBRIQUE>
<X>false</X>
<Y>3.7</Y>
</IMBRIQUE>
</DATA>

(attention, c'est un Map, donc l'ordre n'est pas forcément respecté)
L'idée est d'éviter les VO de présentation, pas de descendre profondément dans l'arborescence : on ne peut pas choisir le nom des éléments d'une liste/tableau (c'est le nom de la classe, ou celui définit dans le dictionnaire)

Plus généralement, StrutsACube est extensible : on peut définir des classes qui créent un XML selon des règles différentes et les appliquer à certains types au lieu de la règle standard. De mémoire, il y en a pour HttpSession, HttpServletRequest, Map, StrutsACubeMap, en plus des cas "built-in" (java.lang.*, Array, Collection)

On pourrait en faire une pour GenericPresentationVO mais je pense qu'il serait plus simple et de faire un StrutsACubeArray qui contiendrait un tableau et un nom pour les éléments (idem avec StrutsACubeList) :

StrutsACubeMap data = new StrutsACubeMap();
StrutsACubeArray array = new StrutsACubeArray();
array.setItemTag("PROFIL");
array.setItems(new String[]{"admin","user"});
data.put("LISTE_PROFILS",array);

donnerait

<DATA><LISTE_PROFILS><PROFIL>admin</PROFIL><PROFIL>user</PROFIL><LISTE_PROFILS></DATA>

A mon avis, il ne faut pas pousser plus loin : au bout d'un moment, on va se retrouver avec toute la vue dans le contrôleur...

RE: StrutsACube [ Répondre ]
Par : Grégory Picavet on 2007-01-26 18:45		[forum:52455]
La possibilité de pouvoir générer des flux xml sans XSLT devenait vraiment indispensable !
nous avions développé un mécanisme similaire pour le framework serveur 2.3 sur un projet où nous avions commencé
de manière classique. On a vraiment constaté un gain en productivité et en maintenance.

Par contre nous avons pris une approche différente de celle de StrutsAcube :

StrutsAcube sérialise les javabeans vers un flux XML de la même façon que StrutsCX, mais les noms de balises sont codés avec une règle prédéfinie.
-il est donc nécessaire de créer des VO de présentation pour la mise en forme des données.

Dans notre approche, nous avons créé de VO génériques et d'une feuille XSLT générique.
-Les VO génériques proposent un formatage par défaut pour chaque type de donné, qu'il est possible de surcharger
-Pas de multiplication des classes de présentations.
-Pour le mapping, on spécifie le nom de balise dans le code, ce qui permet de réutiliser un flux XML bouchonné existant.
-Des VO génériques sont spécialisés dans la génération de flux XML pour les listes déroulantes (ce flux est normalisé dans le framework client)


EXEMPLE DE CODE DANS L'ACTION STRUTS :

GenericPresentationVO fluxVO = new GenericPresentationVO("FLUX");
GenericPresentationVO tableauVO = new GenericPresentationVO(fluxVO,"TABLEAU");
for(row : listRows) {
GenericPresentationVO ligneVO = new GenericPresentationVO(tableauVO,"LIGNE");
ligneVO.addAttribute("ID", row.getId());
ligneVO.addAttribute("COLONNE1", row.getColonne1());
ligneVO.addAttribute("COLONNE2", Formater.booleanOuiNonFormater().format(row.getBooleen()));
}

GenericOptionListPresentationVO listeVO = new GenericOptionListPresentationVO(fluxVO,"LISTE");
listeVO.setLibelle("mon libellé"); //utiliser i18n
listeVO.addOptions(new String[]{"id1","id2"}, new String[]{"libelle1","libelle2"});

beans.add(fluxVO);

FLUX XML

<FLUX>
<TABLEAU>
<LIGNE>
<ID>1</ID>
<COLONNE1>lffflzf</COLONNE1>
<COLONNE2>OUI</COLONNE2>
</LIGNE>
</TABLEAU>
<LISTE>
<LIBELLE>mon libellé</LIBELLE>
<OPTIONS>
<OPTION>
<VALUE>id1<VALUE>
<LIBELLE>libelle1<LIBELLE>
</OPTION>
<OPTION>
<VALUE>id2<VALUE>
<LIBELLE>libelle2<LIBELLE>
</OPTION>
</OPTIONS>
</LISTE
</FLUX>

RE: StrutsACube-utiliser ActionForward [ Répondre ]
Par : Benjamin Leperchey on 2007-01-24 11:54		[forum:52452]
On pourrait utiliser la "syntaxe" standard de Struts pour ne pas avoir à modifier la DTD :

<forward name="success" path="/StrutsACubeServlet"
className="org.apache.struts.action.MonActionForward">
<set-property name="extension" value="pdf"/>
<set-property name="styleSheet" value="/WEB-INF/xsl/sticker-pdf.xsl/>
</forward>

(de mémoire)

C'est un peu plus lourd, mais comme ça on est sûr que les nouvelles propriétés seront lues par Struts, parce que cette extension est documentée (on peut supposer que Struts utilise la méthode "setProperties" de Apache-Digester et donc que ton exemple marcherait aussi, mais on n'en est pas sûr).

RE: StrutsACube-utiliser ActionForward [ Répondre ]
Par : Thierry RIGAL on 2007-01-23 22:51		[forum:52451]
effectivement nous pourrions aussi ajouter les définitions (des feuilles de style) en ajoutant des attributs à la balise forward au niveau des actions configurées dans struts-config.xml. Ces attributs supplémentaires sont stylesheet et extension, ce qui donne par exemple :

<forward name="success" path="/StrutsACubeServlet" className="org.apache.struts.action.MonActionForward"
extension="pdf" styleSheet="/WEB-INF/xsl/sticker-pdf.xsl
/>

L'objet forward serait ensuite lu dans la classe BaseAction àpartir de l'objet ActionMapping au niveau de la méthode execute :
MonActionForward forward = mapping.findForward("success");

puis il suffirait de lire les valeurs des attributs styleSheet et extension utiles à la construction de la vue.

Cela nécessiterait quand même de revoir la DTD (au niveau de la balise forward) et de créer une nouvelle classe héritant d'ActionForward. Ce n'est pas neutre.

PS :
Je crois qu'il est nécessaire d'apporter la plus grande précision dans l'exposé de ses solutions dans ce forum pour éviter qu'il ne soit un dialogue entre experts.

RE: StrutsACube [ Répondre ]
Par : Benjamin Leperchey on 2007-01-23 19:37		[forum:52450]
Sans vouloir faire du forum un chat...

Nous sommes bien d'accord : le but est bien de récupérer les infos à la fin, pas question de copier Struts... mais c'est précisément ce que tu fais en reparsant le fichier !!!

Et parser le web.xml pour parser le struts-config.xml... ça me semble un peu tordu.

Avec ma proposition, seule la BaseAction (et *pas* la servlet StrutsACube) est liée à Struts -- et elle l'était déjà. Autre framework, autre BaseAction mais même servlet.

Ceci dit, vu le nom choisi pour le composant, le risque d'abandonner Struts est faible...

RE: StrutsACube [ Répondre ]
Par : Thierry RIGAL on 2007-01-23 16:01		[forum:52448]
sans rien changer au code existant on peut ajouter quelques lignes dans la classe StrutsACubeServlet pour tenir compte du fichier web.xml et en extraire le chemin vers le fichier de configuration de Struts c à d struts-config.xml.

La façon dont Struts lit son fichier de configuration ne nous intéresse pas à priori, nous n'avons pas à copier le code de Struts assurant cette fonction. Ce qui compte est de lire les valeurs qui nous intéressent.

RE: StrutsACube [ Répondre ]
Par : Thierry RIGAL on 2007-01-23 15:56		[forum:52447]
Le split de la classe BaseAction est en cours. Lors du traitement des objets de type FileVO il faudra prévoir une classe action héritant d'une classe abstraite héritant elle-même de BaseAction.

RE: StrutsACube [ Répondre ]
Par : Thierry RIGAL on 2007-01-23 15:52		[forum:52446]
Dans la classe Action la méthode getSuccesVO retourne un objet de type SuccesVO qui sera retourné vers le navigateur si une action spécifique est envisagée.

Dans la méthode getSource de la servlet StrutsACubeServlet on détermine un objet data à transmettre dans le flux de la manière suivante :

1. StrutsACubeData contient-il des erreurs ?
--> on transmet un flux d'erreurs de type ErrorVO

2. StrutsACubeData contient-il une liste d'objets de type SuccesVO ?
--> on transmet un flux d'objets de type SuccesVO

3. Si aucune des conditions précédentes n'est vérifiée (cas le plus général) on transmet un flux de données.

voici l'extrait du code associé à ce traitement :

Object data=null;
// serialisation des donnees
if(strutsACubeData.getErrors().size()>0){
data=strutsACubeData.getErrors();
}
else{
if(strutsACubeData.showSuccesVO){
ArrayList<SuccesVO> listSuccesVO=new ArrayList<SuccesVO>();
listSuccesVO.add(strutsACubeData.getSuccesVO());
data=listSuccesVO;
}
else{
data=strutsACubeData.getData();

}
}

RE: StrutsACube [ Répondre ]
Par : Benjamin Leperchey on 2007-01-22 23:04		[forum:52444]
Et d'ailleurs, à quoi sert "getSuccesVO" ?

Toutes ces méthodes annexes devraient proposer une implémentation par défaut, celles de BeanTest.java par exemple.

L'action ne devrait plus avoir qu'à produire des données, et surcharger les méthodes par défaut pour les cas spécifiques (getSpecificAction justement)

RE: StrutsACube [ Répondre ]
Par : Benjamin Leperchey on 2007-01-22 23:00		[forum:52443]
La BaseAction, reprise de la BaseAction StrutsCX, fait un peu trop de choses à mon avis :

1) comme je le proposais ailleurs, il faudrait différencier le cas d'une action qui renvoie un FileVO

2) dans le cas "StrutsACube pur", getTypeOfFlux est superflu, puisque le content-type est redéfini par la vue (ce qui est d'ailleurs parfaitement normal -- faute de goût de la part de StrutsCX)

J'irais même jusqu'à dire qu'il est nocif : comment faire pour renvoyer les mêmes données soit en XML pour un tableau, soit en PDF pour un état ?

RE: StrutsACube [ Répondre ]
Par : Benjamin Leperchey on 2007-01-22 22:52		[forum:52442]
C'est vrai mais il reste que :

1) les propriétés supplémentaires ne sont pas dans la DTD de Struts (ce qui n'est pas dramatique)

2) le chemin "/WEB-INF/struts-config.xml" est en dur dans le code, alors que c'est une simple convention : je pourrais le mettre dans "/images/toto.jpg". Et ça me semble un peu tordu de dire dans le fichier de configuration StrutsACube où est le fichier de configuration Struts...

3) si on veut utiliser des modules Struts, et donc plusieurs fichiers de config Struts, on est mal (même si je ne vois pas trop pourquoi on s'amuserait à ça en ACube, mieux vaut ne préjuger de rien)

Utiliser struts pour parser la config ad hoc, ça évite tous ces problèmes.

RE: StrutsACube [ Répondre ]
Par : Benjamin Leperchey on 2007-01-22 22:44		[forum:52441]
A part (toutes) mes remarques, chapeau, ça a vraiment une bonne tête.

RE: StrutsACube [ Répondre ]
Par : Benjamin Leperchey on 2007-01-22 22:40		[forum:52440]
le content-type est défini à partir de l'extension de la requête... je trouverais plus logique de le mettre dans le paramétrage du "Output" (d'ailleurs PlainTextOutput a bien une méthode getMimeType, qui sauf erreur n'est pas utilisée).

Une "Output" peut-elle renvoyer différents types MIME ?

si le content-type doit vraiment être construit à partir de l'extension, il faudrait au moins le rendre paramétrable (sur le modèle des autres composants de StrutsACube)

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