You can easily move your application specific configuration to other configuration files (i.e. ApplicationResources or tiles-defs.xml). You don't have to use the mapping.findForward() at all in your Actions, instead, read these values from ApplicationResource files.

> Robert H. Tran wrote:
> 
>>My point was not against configuration altogether, but rather against the
>>current rigid and centralized configuration. There should be options. If
>>there is configurations in a component, it should be self-contained by the
>>component. It is no framework's business. If there is an api in Struts,
> 
> this
> 
>>can be done nice and easy, as I said with Eclipse.
>>
>>- Robert.
>>
>>----- Original Message ----- 
>>From: "Martin Cooper" <martinc@apache.org>
>>To: <struts-user@jakarta.apache.org>
>>Sent: Thursday, December 04, 2003 11:51 AM
>>Subject: Re: Disadvantages of Struts?
>>
>>
>>
>>
>>>"Robert H. Tran" <rhtran2000@hotmail.com> wrote in message
>>>news:BAY8-DAV35wOxFmfnXA00002874@hotmail.com...
>>>
>>>
>>>>I think an action's mapping is a decision by the action itself. Like I
>>>
>>>said
>>>
>>>
>>>>earlier, when an application development finishes, that decision will
>>>
>>>become
>>>
>>>
>>>>static. At that point, when an Action's mapping changes, its code will
>>>
>>>have
>>>
>>>
>>>>to change too (unless the new mapping is kind of a synonym to the old
>>>>mapping, which doesn't bear any shift in the semantics). As such, there
>>
>>is
>>
>>
>>>>almost no point in keeping the decision and the code separate (i.e.
>>
>>making
>>
>>
>>>>the decision's configuration a loose end of the code). Or at least,
>>>>configuration shouldn't be the only way to add or modify an Action.
>>>
>>>I disagree with this almost completely. If actions are written properly,
>>
>>you
>>
>>
>>>should be able to reconfigure the application, to some extent at least, by
>>>changing the config alone and not touching the Java code. This is
>>
>>immensely
>>
>>
>>>useful when an app needs to be customised after the fact, and when the
>>>source code is not available (e.g. by a customer, in their own
>>
>>environment).
>>
>>
>>>--
>>>Martin Cooper
>>>
>>>
>>>
>>>
>>>>Even though each Action's configuration may be small, the configurations
>>>
>>>for
>>>
>>>
>>>>all the Actions need to be kept track of and maintained (for integrity).
>>>>That may be a significant but unnecessary side work. To view the
>>
>>mappings,
>>
>>
>>>>there can be a tool to traverse the structure by api calls and display
>>
>>it.
>>
>>
>>>>That can be done after the fact and doesn't have to be before it. In
>>>>addition to that, when the decision (or configuration if any) goes where
>>>
>>>the
>>>
>>>
>>>>code lives, modularity increases.
>>>>
>>>>IMHO,
>>>>
>>>>- Robert.
>>>>
>>>>
>>>>----- Original Message ----- 
>>>>From: <John.Pitchko@shell.ca>
>>>>To: <struts-user@jakarta.apache.org>
>>>>Sent: Thursday, December 04, 2003 6:55 AM
>>>>Subject: RE: Disadvantages of Struts?
>>>>
>>>>
>>>>I have to disagree with you on the first point. I find that there is
>>>>just a small amount of necessary configuration required to build an
>>>>Action class (most of my Action configurations have about a half dozen
>>>>lines, even less if there is no associated ActionForm). I'm not really
>>>>sure what you mean by "paddle back and forth between the code and the
>>>>configuration", could you explain?
>>>>
>>>>Thanks.
>>>>
>>>>Robert H. Tran wrote:
>>>>
>>>>
>>>>>I am not sure that is true. Struts seems to lack of an API. IMO, there
>>>>
>>>>are
>>>>
>>>>
>>>>>more required configurations than necessary. Take Action for example,
>>>>
>>>>to
>>>>
>>>>
>>>>>write an Action, one has to paddle back and forth between the code and
>>>>
>>>>the
>>>>
>>>>
>>>>>configuration. It is like an executable having to configure each of
>>>>
>>>>its
>>>>
>>>>
>>>>>dlls. The visibility of the mappings is nice to have but the mappings
>>>>
>>>>can
>>>>
>>>>
>>>>>be generated after the fact as in a debugging view. When the
>>>>
>>>>application is
>>>>
>>>>
>>>>>finished, configurations become static. But since configurations are
>>>>>required, they will be like loose ends of the application. Another
>>>>
>>>>issue:
>>>>
>>>>
>>>>>how can one componentize his code and deploy it in a self-contained
>>>>
>>>>plug-in,
>>>>
>>>>
>>>>>as with Eclipse? Please forgive my novice.
>>>>>
>>>>>- Robert.
>>>>>
>>>>>----- Original Message ----- 
>>>>>From: "Rick Hightower" <rhightower@triveratech.com>
>>>>>To: "'Struts Developers List'" <struts-dev@jakarta.apache.org>
>>>>>Sent: Wednesday, December 03, 2003 6:24 PM
>>>>>Subject: RE: Disadvantages of Struts?
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>Don't be silly. Struts is perfect.
>>>>>>
>>>>>>-----Original Message-----
>>>>>>From: Robert H. Tran [mailto:rhtran2000@hotmail.com]
>>>>>>Sent: Wednesday, December 03, 2003 2:10 PM
>>>>>>To: Struts Developers List
>>>>>>Subject: Disadvantages of Struts?
>>>>>>
>>>>>>I just wonder if Struts comes with any significant drawback. I mean
>>>>
>>>>not in
>>>>
>>>>
>>>>>>terms of when to use Struts and when not to use it necessarily, but
>>>>
>>>>more
>>>>
>>>>
>>>>>in
>>>>>
>>>>>
>>>>>
>>>>>>the line of anyone's wishes that it had been better. Any advice is
>>>>
>>>>very
>>>>
>>>>
>>>>>>appreciated.
>>>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>--------------------------------------------------------------------------
>>>--
>>>
>>>
>>>>----
>>>>
>>>>
>>>>
>>>>
>>>>>---------------------------------------------------------------------
>>>>>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