struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Frank W. Zammetti" <fzli...@omnytex.com>
Subject Re: How to avoid lots of "if else" in Action class.
Date Thu, 04 May 2006 18:08:38 GMT
On Thu, May 4, 2006 1:59 pm, Michael Jouravlev said:
> Code-wise:
>
> one action class per one logical web resource seems more natural to
> me. Say, Employee. I would have one EmployeeForm, one EmployeeAction
> and several JSP pages for different modes. All compact and observable
> with as little stuff in config file as possible. But this is just a
> preference.

Agreed, it's a preference :)  I can certainly see where your coming from.

> Usability-wise:
>
> One action and one action mapping make one URL. This may be important
> for some (me), and not important for others. Combined with some other
> development approaches, one URL may help to solve stale page problems
> or implicit double submit problems. But then again, if you have one
> render mapping, but you use redirection, then even with several submit
> mappings you can get away with only one visible URL. So again, the
> matter of taste :-)

This one may not always be a matter of taste... what if you had a
situation (and I can tell you, I have in the environment I work in) where
you want to apply different security roles to different URIs?  If you
always have a single URL, how can you do this?  I.e., you want
/showAccount.do accessible to the AccountManager and Customer roles, but
you only want /updateAccount.do accessible to the AccountManager role?  As
I understand it, you would have something like /accountResource.do, and
dispatch to a particular method... how could I secure one but not the
other based on role?

Frank

> I will think on more benefits of dispatch actions :)

Well, the name sounds cooler :)

> On 5/4/06, Frank W. Zammetti <fzlists@omnytex.com> wrote:
>> And of course the simple option: separate action :)
>>
>> It's absolutely true that a Dispath-type action will get rid of all the
>> if's, and that's good... but you will still be left with a potentially
>> large Action that performs a number of different (hopefully at least
>> related!) functions.
>>
>> Me, I still prefer individual Actions that are only a few lines of
>> actual
>> code a piece.  I'd rather have more smaller Actions than fewer larger
>> Actions.  I find it easier to comprehend an application constructed that
>> way, and I also find it easier to make incremental changes.  It also
>> potentially makes working in a team environment less contentious,
>> although
>> this isn't to me a major concern.
>>
>> Frank
>>
>> --
>> Frank W. Zammetti
>> Founder and Chief Software Architect
>> Omnytex Technologies
>> http://www.omnytex.com
>> AIM: fzammetti
>> Yahoo: fzammetti
>> MSN: fzammetti@hotmail.com
>> Java Web Parts -
>> http://javawebparts.sourceforge.net
>> Supplying the wheel, so you don't have to reinvent it!
>>
>> On Thu, May 4, 2006 1:20 pm, Michael Jouravlev said:
>> > Dispatching action. Do not use old and crusty DispatchAction.
>> > See these links:
>> >
>> > http://wiki.apache.org/struts/EventActionDispatcher
>> > http://wiki.apache.org/struts/DataEntryForm
>> >
>> > Michael.
>> >
>> > On 5/4/06, Joey Watson <joey.information@gmail.com> wrote:
>> >> hello everybody.
>> >>
>> >>   When I was working a big project. I always met this problem. coz
>> the
>> >> sometimes there are a lot of event need to be handled in a single jsp
>> >> page. so programer need to use lots of "if - else" to deal with
>> >> different event  in Action.execute method. of cause. I think those
>> >> codes is not hard to be understant,  but sometimes it make the action
>> >> class too big.  Any suggestion?
>> >>
>> >> Thanks.
>> >>
>> >> Joey.
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
>> >> For additional commands, e-mail: user-help@struts.apache.org
>> >>
>> >>
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
>> > For additional commands, e-mail: user-help@struts.apache.org
>> >
>> >
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
>> For additional commands, e-mail: user-help@struts.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>


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


Mime
View raw message