On Tuesday 01 April 2003 03:59 pm, Igor Shabalov wrote: > You can not possibly imagine how useful and powerful can be good GUI tool > when you handle really big and cumbersome struts-config file. Actually it > can give you much more capability to implement such pipes, filers and > “assembling” of application from pre-defined action components.
Why, I can. Paul > > On Tue, 1 Apr 2003 15:12:34 -0500, Paul Yunusov <[EMAIL PROTECTED]> > > wrote: > > On Tuesday 01 April 2003 03:00 pm, Thorin Linderholm wrote: > >> 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.) > > > > Well, at one point you will wonder which is more cumbersome: coding > > Action classes or having a mile-long struts-config.xml. > > > > Paul > > > >> -----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. > >> > >> Paul > > > > --------------------------------------------------------------------- > > 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]
