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]
RE: design question about action chaining
The static method you suggest would be very cumbersome to implement and maintain, requiring hard-coding calls to each bit of functionality I wanted on each page (aghh!) But thanks for the reply :-) I have to disagree that 'If they are a business tier concept, Struts should have nothing to do with chaining them.' The struts ActionServlet and the page mappings in the struts-config are the 'controller' portion of Struts. The whole of Struts is much more than the 'C' in MVC. It has taglibs for supporting the V, and actions are in fact always implementing buisness logic (they decide what page to go to by returning a 'forward': definite buisness logic, if there is such a thing.) And that's always been a gray area in MVC for me: does all the buisness logic belong in the model, or can it also go in the controller? Or is there an MVCC where there is a 'view' controller and 'buisness' controller (which seems a bit redundant to me.) -Original Message- From: Paul Yunusov [mailto:[EMAIL PROTECTED] Sent: Tuesday, April 01, 2003 11:43 AM To: Struts Users Mailing List Subject: Re: design question about action chaining On Tuesday 01 April 2003 02:30 pm, Thorin Linderholm wrote: 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 Ever thought of defining functionality equivalent to your proprietory actions in classes that don't extend the Struts framework and chaining calls to instances of these classes in your Struts Actions? This is a static solution as opposed to having struts-config.xml support some sort of action chaining tags but Struts Actions are only HTTP adapters, and chaining them violates the spirit of the framework. That's why I think implementing chaining with non-Struts classes is a better idea. Your actions seem to be pretty fine-grained (Ensure Session initialization has been completed/Initialize session). If session in this case refers to the HttpSession, then they are almost as low-level as the Servlet API (why?). If they are a business tier concept, Struts should have nothing to do with chaining them
RE: design question about action chaining
Filters are one of the design/imp choices I've considered under the 'parallel system' heading, though I hadn't thought of trying to use the web.xml for this. I'd have to look into these more. I take it you recomending that a second, parallel system of specifying functionality on a per-page or per-page-set basis is the way to go? What reasons would you have for this design choice, as opposed to extending struts to contain this functionality? Have you (or others,) implemented something similar to this? (This port is going to be a large chunk of time and I'm just trying to find out if other people have already thought through and implemented this type of functionality before I just pick something, run with it, and end up with some kind of maintenance or design nightmare :-) -Original Message- From: David Graham [mailto:[EMAIL PROTECTED] Sent: Tuesday, April 01, 2003 11:52 AM To: [EMAIL PROTECTED] Subject: Re: design question about action chaining I think Filters would be a good choice for your needs. You can define a filter for each piece of logic and then configure them in web.xml for groups of pages. You'll need to put related pages in the same path scheme so that you can map a filter to the group instead of each page. David From: Thorin Linderholm [EMAIL PROTECTED] Reply-To: Struts Users Mailing List [EMAIL PROTECTED] To: '[EMAIL PROTECTED]' [EMAIL PROTECTED] Subject: design question about action chaining Date: Tue, 1 Apr 2003 11:30:39 -0800 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: /do or .do
If you wanted to switch to *.do you could use: /admin/cms/article/add.do That will still match your *.do servlet mapping. -Original Message- From: Brandon Goodin [mailto:[EMAIL PROTECTED] Sent: Tuesday, April 01, 2003 4:15 PM To: Struts User List Subject: /do or .do I have been in the habit of /do pattern. It seems to work fine for me. Apart from having different 'modules' or subapps, is there a compelling reason to use .do. In the course of using /do I have found it easier to map the functions of my actions. For examples: /do/admin/cms/article/add vs adminCMSArticleAdd.do To me the first one is cleaner. Can I stir all of your thoughts on this subject. I am at a place where I can change to the .do if there is a good reason. Brandon Goodin - 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]
