Surveiller ce forum | 
Commencer une nouvelle discussion
| RE: traitement d'erreurs des classes Action [ Répondre ] Par : Xavier PRINCE on 2007-02-19 23:11 | [forum:52514] |
| Je reste peux convaincu d'un rapprochement fort avec les solutions Strust et le Framework ACube, surtout en ce moment alors qu'à priori la future version 2.0 de Strust semble annoncé de nombreux changement (j'avoue ne pas avoir encore regarder en détail). | |
| RE: traitement d'erreurs des classes Action [ Répondre ] Par : Xavier PRINCE on 2007-02-19 23:09 | [forum:52513] |
| L'intérêt second de ce gabarit est de la description XML des règles et que la pourrait créer dans le cadre d'ACube un du Framework Ergonomique une équivalent à ce gabarit se basant sur les mêmes fichiers XML de déclaration ... reste à voir la faisabilité et le coût des cette mise en oeuvre. | |
| RE: traitement d'erreurs des classes Action [ Répondre ] Par : Grégory Picavet on 2007-02-19 16:08 | [forum:52510] |
|
Vaut-il mieux avoir un modèle déclaratif plutot que programmatif des règles de validations? Dans les deux modèles, la réutilisation des règles entre différentes actions et form est possible. Cependant un intérêt du modèle déclaratif dans le framework Struts est de pouvoir être réutilisé sans effort dans les contrôles de surfaces coté client . Il y aurait un gain de productivité si Acube pouvait faire de même, au runtime ou compile-time (via un générateur de code). D'habitude le runtime est préférable en phase de développement. |
|
| RE: traitement d'erreurs des classes Action [ Répondre ] Par : Xavier PRINCE on 2007-02-19 03:45 | [forum:52505] |
|
Le danger de ce genre de bibliothéque et de voir les nombres de contrôles : - soit exploser au fur et à mesure des besoins (car particulier 2 du cas particulier 1) - soit donner lieu à des contrôles si génériques et paramétrables que personne ne les utlisera Je reste attiré par l'idée d'une norme de développement avec une ensemble de fonction génériques qui pourront être utilisé pour créer des fonctions moins génériques et adapté au contexte d'un client. j'en profite pour rappeler ici que ce type de méthode permettant de faire des contrôles de types et de gérer la remontée d'un ErreurVO est déjà en place mais uniquement pour gérer la lecture des data de la requête. |
|
| RE: traitement d'erreurs des classes Action [ Répondre ] Par : Steve PEGUET on 2007-02-13 15:31 | [forum:52490] |
|
Attention, je ne faisais pas ici référence au validator de struts mais celui générique de Jakarta (voir url précisée). L'idée est d'intégrer ce framework dans le gabarit J2EE d'ACube, déjà pour fournir l'ensemble des routines de second niveau permettant d'effectuer des contrôles de format : http://jakarta.apache.org/commons/validator/apidocs/org/apache/commons/validator/routines/package-summary.html#package_description Rien que l'intégration de ceci permetterait de mieux normaliser le code et on pourrait l'intégrer dans nos normes de développement en sachant que l'appel de toutes ces routines sera effectué dans la fonction validate décrite par thierry et pourrons donner lieu à des erreurs VO. L'autre façon de faire est d'utiliser le framework validator : http://jakarta.apache.org/commons/validator/apidocs/org/apache/commons/validator/package-summary.html#package_description Avec cette fois-ci une description XML des règles de format pour mutualisation à travers plusieurs actions. Ce n'est pas ceux obligatoires associés à Struts mais des fichiers complètement neutres avec le risque tout de même que tu as identifié. Le principal avantage est dans sa mutualisation sur plusieurs actions. Dans les 2 cas, l'intégration de ce paquage dans le gabarit avec une documentation dessus dans le cas d'ACube me semble vraiement intéressant. Mais, bon à creuser et quel est votre avis? |
|
| RE: traitement d'erreurs des classes Action [ Répondre ] Par : Benjamin Leperchey on 2007-02-10 14:30 | [forum:52486] |
|
D'accord avec Steve. Tant qu'à utiliser la validation des requêtes, autant utiliser les mécanismes standard de Struts. L'intérêt d'une méthode validate dans la BaseAction ne me semble pas clair : dans ce cas, pourquoi ne pas renvoyer directement des ErrorVO au lieu des des ActionMessages ? Au contraire, utiliser le mécanisme de Struts (en amont de l'appel de l'action) permet de réutiliser les mêmes vérifications entre plusieurs actions. Ceci dit, le risque est quand même d'éparpiller les règles de gestion : les définitions de formulaires et les règles associées sont dans (encore) un autre fichier de propriétés. A la fin, on se retrouverait avec : - le mapping dans struts-config.xml, qui fait référence à des formulaires, - la définition des formulaires dans struts-validator-config.xml - les actions proprement dites dans les classes Java. Autrement dit, pour retrouver les paramètres d'une action en lisant le code Java, il faudrait chercher dans le struts-config le nom du formulaire, puis dans struts-validator-config sa définition... |
|
| RE: traitement d'erreurs des classes Action [ Répondre ] Par : Steve PEGUET on 2007-02-09 15:23 | [forum:52481] |
|
Il serait vraiement utile d'étudier l'intagration du composant Validator présent dans Jakarta Commons : http://jakarta.apache.org/commons/validator/. L'avantage est qu'il renvoie une Map avec ValidatorResults.getResultValueMap() que l'on pourrait envoyer en entrée d'une sortie générique sous la forme d'un XML type ErrorVO. Cette fonctionnalité serait bien sûre une option de validate. Qu'est ce que vous en pensez? |
|
| traitement d'erreurs des classes Action [ Répondre ] Par : Thierry RIGAL on 2007-02-07 16:07 | [forum:52477] |
|
Pour traiter les erreurs liées au contrôle de surface d'un formulaire ou de cohérence des données une modification de la classe BaseAction peut être envisagée : - ajout d'une méthode abstraite validate retournant un objet ActionErrors (cette méthode est à surcharger dans la classe Action pour récupérer des erreurs liées à la cohérence des données). Au niveau de la classe Action on ajoute des objets de type ActionMessages dans ActionErrors. - un appel à la méthode validate dans la méthode execute afin de récupérer un objet ActionErrors. Si celui-ci est nul (pas d'erreurs) alors la méthode execute crée une liste de beans ou d'objets ErrorVO. Si l'objet ActionErrors n'est pas nul alors on transforme en objet Errors contenant des objets ErrorVO. Le code est résumé ci-après : /** * validation de l'action à traiter (cohérence des données, contrôle de surface...) * * */ protected abstract ActionErrors validate(ActionMapping mapping, HttpServletRequest request) throws TechnicalException, FunctionalException; .../... public ActionForward execute(ActionMapping mapping, ActionForm form, HttpServletRequest request, HttpServletResponse response) throws java.io.IOException, javax.servlet.ServletException, DAOException, TechnicalException, FunctionalException { .../... //vérification du droit d'exécution de cette action suite au contrôle de surface du formulaire ActionErrors actionErrors=new ActionErrors(); try { actionErrors=validate(mapping, request); } catch (RuntimeException e) { logger.error("RuntimeException : "+ e.getMessage()); ErrorVO erreur = new ErrorVO("ERR-TEC-00", null, null, true, false, false); errors.add(erreur); } .../... if (actionErrors==null && contentType != null) { /* construction de la liste de beans */ .../... } if(actionErrors.size()>0){ } return forward; } |
|
