Surveiller ce forum | 
Commencer une nouvelle discussion
| RE: FileVO et BaseAction [ Répondre ] Par : Xavier PRINCE on 2007-02-19 03:02 | [forum:52501] |
| La nouvelle version dispose donc effectivement de deux bases actions ce qui permet d'avoir une action spécifique simplifié pour gérer le download de fichier. Cette version à été faire afin de prendre en compte aussi la notion de "content-disposition" dans le header de la réponse | |
| RE: FileVO et BaseAction [ Répondre ] Par : Xavier PRINCE on 2007-01-13 12:33 | [forum:52404] |
| Effectivement le choix de différencier les bases actions est justifié ... je vais demander quelqu'un de chez nous de travailler sur ce split pour la version 2.4 et de les reporter dans le version 3.0 embarquant StrustACube | |
| RE: FileVO et BaseAction [ Répondre ] Par : Benjamin Leperchey on 2007-01-04 17:49 | [forum:52392] |
|
Ajout : si on distinguait la BaseActionFile de la BaseAction normale, on pourrait gérer proprement la première requête d'IE (celle où le user-agent est contype, et où on est censé répondre seulement avec le content-type) |
|
| FileVO et BaseAction [ Répondre ] Par : Benjamin Leperchey on 2007-01-04 17:14 | [forum:52391] |
|
C'est la même BaseAction qui sert dans le cas d'un FileVO et dans un cas "normal". Le comportement est pourtant complètement différent : dans un cas on écrit directement sur la sortie le contenu et le type MIME du FileVO, dans l'autre on passe la main à StrutsCX. Du coup, le code des actions est très curieux : au lieu de renvoyer un FileVO, il faut renvoyer un tableau de beans dont le premier élément est un FileVO -- les autres éléments étant ignorés -- ce FileVO n'étant d'ailleurs pas du tout un bean. Il serait je trouve plus logique de définir deux BaseAction : une qui ne fonctionne qu'avec StrutsCX (la normale) où l'"utilisateur" doit renvoyer un tableau de beans, et une version où il doit renvoyer un FileVO et où StrutsCX n'est utilisé qu'en cas d'erreur. Pour ne pas (trop) toucher à la BaseAction existante, on pourrait concevoir de ne forwarder à StrutsCX qu'en cas d'erreur ou quand le tableau de beans n'est pas null. La méthode getBeans de BaseActionFile appellerait une autre méthode abstraite getFileVO, écrirait son contenu sur le flux de réponse (ie on déplace le code de BaseAction vers BaseActionFile) et renverrait null. Les exceptions seraient bien sûr propagées. Personnellement, je milite carrément pour deux classes indépendantes (avec éventuellement un ancêtre commun pour les parties communes liées à StrutsCX) pour différencier le comportement vis-à-vis de Struts : une irait chercher le ForwardMapping 'success' dans tous les cas (la BaseAction actuelle, et encore 'success' est assez mal choisi), et l'autre le mapping 'error' en cas d'erreur et null en cas de succès. Le fichier struts-config serait je trouve plus lisible comme ça. Pour les gens du MAE : voir gram.action.BaseActionStruts dans le CVS GRaM (j'utilise un objet HttpResponseContent, quasiment identique au FileVO -- j'avais commencé avant le FileWrapper, il faudra récrire cette partie pour utiliser le framework dans la prochaine version.) |
|
