David
From: Edgar Dollin <[EMAIL PROTECTED]>
Reply-To: "Struts Users Mailing List" <[EMAIL PROTECTED]>
To: 'Igor Shabalov' <[EMAIL PROTECTED]>, 'Struts Users Mailing List' <[EMAIL PROTECTED]>
Subject: RE: Is Strut too primitive for really useful Controller function?
Date: Wed, 2 Apr 2003 06:52:21 -0500
If I understand what your are saying is that there is a action scripting language built into Exadel. I guess then there is some kind of 'terminal' action which decides the output or is the output built along the way.
Interesting
Edgar
> -----Original Message----- > From: Igor Shabalov [mailto:[EMAIL PROTECTED] > Sent: Tuesday, April 01, 2003 4:31 PM > To: 'Struts Users Mailing List' > Subject: Re: Is Strut too primitive for really useful > Controller function? > > > > I can not find original post from Thorin - but I'm 100% > agree with his > point. > Moreover - I have real experience with system that > allows me to implement > what Thorin is talking about. We implements almost all > business logic in > controller layer, moreover - we have two sub-layer inside > controller - > "presentation" controller, which handles all page flow and input > validations, and "business" controller - where actual > business logic where > implemented on "high" level. > All this because of using our own implementation of MVC > framework - > Exadel. > I'm not here to convince you to switch from Struts to > Exadel, but I can > tell you that Struts "controller" component is too primitive > compared to > Exadel. > We used widely concept of module. In Exadel you can > define module (we call > it "process") with "process context" and actually use it like > "function > calls". You even can use recursion. That gives us ability to > split system > to modules using "vertical" (by functional areas) and > "horizontal" (by > architecture layer) approach. And we design system in a way > where we have > two horizontal layers - one (top) designed to handle page > flow and all > "interface" relater issues. And second (bottom) layer was > dedicated to > business functions. > > I feel that there is something good in such design, the > only problem - > Strut do not really helps here. > > > Best, > Igor. > http://www.exadel.com http://www.exadel.com/products_strutsstudio.htm > > On Tue, 1 Apr 2003 12:08:09 -0800, Thorin Linderholm > <[EMAIL PROTECTED]> wrote: > > > 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] > > > > > > > > -- > Igor Shabalov > Director of Engineering > Exadel Inc. > http://www.exadel.com >
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
_________________________________________________________________
The new MSN 8: advanced junk mail protection and 2 months FREE* http://join.msn.com/?page=features/junkmail
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
