I had come to the conclusion that Struts Actions are moreover 'View Adapter Components' or "VAC's" (you can quote me on that one!) and should not be relied on for handling business logic or data collection by any means, just as a facsimile for "pulling" model/controller data into the view.
I wrote a logical framework that runs under the same premise as Ant's targets and depends attributes (storingUser depends on validateUser). My LogicalAction class allowed properties to be set through normal means with the struts-config w/ a plugin too, that would have a comma delimited list of 'modules' to execute. Using the Filter Pattern and FilterChain-type object, LogicalActions are provided with an executeLogic() method that throws an exception. So basically, your struts-config defines the "controller" calls per action, but the controllers are actually referenced in a separate document that defines their dependency. Keeping your business logic separate, you may want to create a separate DTO object that wraps the http request, much like torque uses. BTW, only after writing this framework did I see that turbine has this framework already built with valves and pipelines: http://jakarta.apache.org/turbine/turbine-3/pipeline.html -Jacob | -----Original Message----- | From: Thorin Linderholm [mailto:[EMAIL PROTECTED] | Sent: Tuesday, April 01, 2003 1:31 PM | To: '[EMAIL PROTECTED]' | Subject: design question about action chaining | | | I have been tasked with porting an existing web application with it's own | proprietary controller architecture to using Struts. | | As they are both web controller architectures, they have many | similarities, | but I'm running into one difference in overall architecture that I'm | having | difficulty resolving. | | This difficulty is most closely related to the 'action chaining' posts | I've | been able to find in the mailing list archives. | | Specifically, I have over 400 pages mapped to various actions (our | controller calls them that, and they're roughly synonymous with struts | actions.) However, our controller allows specifying a list of actions to | execute on a per-page, and per-page-set basis. In other words, we can | assign an action like 'Ensure Session initialization has been | completed/Initialize session' to every page in the site with a single | mapping (assuming you've already listed all the pages.) Or you can assign | it to 90% of your pages if you happen to desire. We have approximatly ten | actions that happen on between 60-99% of the pages on our site. If we | were | to directly translate this to the struts mapping system we would end up | having to re-specify those ten actions on most of those 400+ pages, | creating | long action chains for each page (a whole lot of duplication: hard to | maintain, easy to get wrong, etc.) | | So, conceptually, I want to be able to apply a few different bits of logic | to whole sets of pages. Some of those 'bits of logic' (actions if you | will,) interrupt the process and forward to a different page (page access | rules for instance.) | | There are several possible solutions that I've come up with, but so far | all | of them involve either hacks, extending struts (which happens to partialy | eliminate the reason I'm being required to move to Struts, and so isn't | very | favored by my supperiors,) some complicated java inheritance hierarchy | where | I inherit non-related functionality in those ten actions into a set of | compound actions, each inheriting in the set of functionality we want | (lame,) or I could implement a 'view preprocessor' of some kind that | parallels the struts-config and defines processing that I need to do for | each view page (which requires me to have two completely redundant sets of | page mappings, and apears to me to obsolete the need for Struts in the | first | place (if we were to ignore it's tag libraries and other helper classes | which we also already have proprietary equivalents to.) | | I'd love to hear from anyone about other possibilities, or (even better,) | pointers to somebody/some package already solving this problem. | | Another way to look at the whole thing: How have other people solved the | problem of being able to apply a set of page access rules to arbitrary | sets | of pages without having to create a system parallel to struts that | re-defines every page in the application? Or do people consider a | parallel | system that respecifies every page as the proper design? | | Thorin | | | --------------------------------------------------------------------- | To unsubscribe, e-mail: [EMAIL PROTECTED] | For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
