You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@struts.apache.org by Igor Shabalov <ig...@exadel.com> on 2003/04/01 23:31:19 UTC

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 
<tl...@TRUELINK.com> 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:dgraham1980@hotmail.com]
> Sent: Tuesday, April 01, 2003 11:52 AM
> To: struts-user@jakarta.apache.org
> 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 <tl...@TRUELINK.com>
>> Reply-To: "Struts Users Mailing List" <st...@jakarta.apache.org>
>> To: "'struts-user@jakarta.apache.org'" <st...@jakarta.apache.org>
>> 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: struts-user-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: struts-user-help@jakarta.apache.org
>>
>
>
> _________________________________________________________________
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: struts-user-help@jakarta.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: struts-user-help@jakarta.apache.org
>
>



-- 
Igor Shabalov
Director of Engineering
Exadel Inc.
http://www.exadel.com

---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org