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]

Reply via email to