You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@struts.apache.org by Joey Watson <jo...@gmail.com> on 2006/05/04 19:07:07 UTC
How to avoid lots of "if else" in Action class.
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
Re: How to avoid lots of "if else" in Action class.
Posted by Joey Watson <jo...@gmail.com>.
Thanks Michael. I will study it.
On 5/5/06, Michael Jouravlev <jm...@gmail.com> wrote:
> 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 <jo...@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
Re: How to avoid lots of "if else" in Action class.
Posted by Jakub Milkiewicz <jm...@gmail.com>.
THe gold rule use interface to encapsulte behaviour
2006/5/4, Michael Jouravlev <jm...@gmail.com>:
>
> 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 <jo...@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
>
>
Re: Securing DispatchActions
Posted by "Frank W. Zammetti" <fz...@omnytex.com>.
On Thu, May 4, 2006 2:37 pm, Dave Newton said:
> Frank W. Zammetti wrote:
>> What if you simply are not allowed to include security
>> mechanisms in your application? (configuring groups isn't considered "in
>> the application").
>
> Not allowed? Don't tell 'em ;)
I've done plenty of that :) Sometimes I actually try to play good
corporate citizen though!
>> Well, I can kind of answer my own question... of
>> course we *are* allowed to see what group a user is in and act
>> accordingly, so yes, I *could* code that sort of thing in a
>> Dispatch-type
>> Action. But then, (a) the benefit of externalized security decreases
>> because it isn't quite so external any more, and
>
> I don't really see any reasonable way around that, though... what if
> you're mandated to use a single-URI param-based webapp and only have
> LDAP? Well, you work around the limitations of the environment. How? You
> can always(-ish) intercept behavior at a higher level, whether through a
> filter, URL-rewriting, weberver module, etc.
The problem I ran in to is that we have a rather robust security framework
built on top of J2EE security. It externalizes all our security concerns
from our applications and makes them quite secure and robust. The other
issue is that while we have our own in-house hosting environment, because
I work for a large corporation, that hosting environment is essentially a
separate entity, and they place a lot of constraints on what we can and
can't do...
<tangent>Oh, how I long for the days when we were a little 250-person shop
and I could walk into the server room and do whatever I wanted, and could
code whatever I wanted, so long as it supported the business :( But, two
corporate acquisitions later, that is no longer the environment I find
myself in. There are rules that can't (easily) be broken, lest the
security group sick the hounds on me.</tangent>
> In any case, I'd be more likely to handle this at a higher, more
> abstract level than inside my actual dispatch-style actions via a
> request processor, filter, etc. and configure it via a plug-in/etc. that
> can deal with whatever external mechanism being used and set things up
> appropriately.
I agree, and ultimately I wound up using a filter to deal with the issues
I had at the time. The problem though is that ultimately, audits throw it
up as a red flag because there is a part of the security mechanism that
now belongs to the application code and not the security framework and
more importantly is managed by the container (both of which are heavily
audited and thus preferred by corporate security). I can get away with it
once, but I can't push my luck, hence the question about securing multiple
paths, because I know I am not the only one working in such an
environment.
>> (b) the request isn't
>> getting stopped at the boundary, which is what we want, it's still
>> getting
>> into my application code to some degree.
>>
>
> Eh, IMO if it gets in to your code but can't execute (much of) anything
> I don't see the issue(s), at least on a practical level.
This is one place I actually agree with the corporate mandates... if it
were nothing else, it would be a question of liability... if Websphere is
doing all the security, and some hacker gets through, we can place the
blame on IBM. If it turns out we left a hole, even a very minute one,
then it's on us. So, if you keep a request from getting into *any*
application code, and allow the container to do that constraining,
liability-wise, it isn't on us. It's sad that corporations have to think
that way, I don't as a developer in general, but I can certainly
understand their perspective.
> I think we could debate mandate-based "what-if" scenarios until we both
> died but ultimately the answer will be the same: you work with or around
> whatever you have to work with or around.
I agree, but that's why I raised the issue... maybe there *is* a good way
to work around it, but if not, it's worth knowing about the problem. :)
> Dave
Frank
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Securing DispatchActions
Posted by Dave Newton <ne...@pingsite.com>.
Frank W. Zammetti wrote:
> What if you simply are not allowed to include security
> mechanisms in your application? (configuring groups isn't considered "in
> the application").
Not allowed? Don't tell 'em ;)
> Well, I can kind of answer my own question... of
> course we *are* allowed to see what group a user is in and act
> accordingly, so yes, I *could* code that sort of thing in a Dispatch-type
> Action. But then, (a) the benefit of externalized security decreases
> because it isn't quite so external any more, and
I don't really see any reasonable way around that, though... what if
you're mandated to use a single-URI param-based webapp and only have
LDAP? Well, you work around the limitations of the environment. How? You
can always(-ish) intercept behavior at a higher level, whether through a
filter, URL-rewriting, weberver module, etc.
In any case, I'd be more likely to handle this at a higher, more
abstract level than inside my actual dispatch-style actions via a
request processor, filter, etc. and configure it via a plug-in/etc. that
can deal with whatever external mechanism being used and set things up
appropriately.
> (b) the request isn't
> getting stopped at the boundary, which is what we want, it's still getting
> into my application code to some degree.
>
Eh, IMO if it gets in to your code but can't execute (much of) anything
I don't see the issue(s), at least on a practical level.
I think we could debate mandate-based "what-if" scenarios until we both
died but ultimately the answer will be the same: you work with or around
whatever you have to work with or around.
Dave
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Securing DispatchActions (was: How to avoid lots of "if else"
in Action class.)
Posted by "Frank W. Zammetti" <fz...@omnytex.com>.
Didn't want to hijack a thread, so...
On Thu, May 4, 2006 2:21 pm, Dave Newton said:
> Frank W. Zammetti wrote:
>> 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?
>>
>
> Acegi, other, or hand-rolled method- (or object- or...) -based role
> processing. Before I knew about Acegi (or anything else, really :/ I
> handled things like that through base classes.
What if your corporate mandate (for better or worse) is J2EE security
backed by LDAP? What if you simply are not allowed to include security
mechanisms in your application? (configuring groups isn't considered "in
the application"). Well, I can kind of answer my own question... of
course we *are* allowed to see what group a user is in and act
accordingly, so yes, I *could* code that sort of thing in a Dispatch-type
Action. But then, (a) the benefit of externalized security decreases
because it isn't quite so external any more, and (b) the request isn't
getting stopped at the boundary, which is what we want, it's still getting
into my application code to some degree.
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!
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
indexed property validation
Posted by Carl Smith <cc...@yahoo.com>.
I have an indexed property which is a tipical list of textboxes, I have a requirement to validate that the user need to at least enter values into one text box. How can you configure this using Struts "required" validator? Thanks in advance.
---------------------------------
Love cheap thrills? Enjoy PC-to-Phone calls to 30+ countries for just 2ยข/min with Yahoo! Messenger with Voice.
Re: How to avoid lots of "if else" in Action class.
Posted by Dave Newton <ne...@pingsite.com>.
Frank W. Zammetti wrote:
> 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?
>
Acegi, other, or hand-rolled method- (or object- or...) -based role
processing. Before I knew about Acegi (or anything else, really :/ I
handled things like that through base classes.
Even with a single-URI dispatch-style codebase the action code is pretty
tight with well-injected service classes.
Command handlers can also be injected, making for nice, small source
files (ahhhhhh) with low complexity metrics. Although I must inform
folks that I just worked on a 350-line Action with a cyclometric
complexity of 36... Pity me... hurry... length isn't everything.
Er...
Dave
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: How to avoid lots of "if else" in Action class.
Posted by Michael Jouravlev <jm...@gmail.com>.
On 5/4/06, Frank W. Zammetti <fz...@omnytex.com> wrote:
> No, sorry, never did get around to reading it... I meant to, but the
> book is all I've had time for since pretty much January.
Yeah, yeah, yeah ;-)
> I actually
> really can't wait to be done with it, at least the initial writing.
Will it be available online? For free? :-)
> There's so many things I'd like to be working on right now! The current
> project, while being really fun, has been a TON of work (an AJAX-based
> adventure game). I can't remember the last time I got a full nights' sleep.
I saw some Ajax games. I don't play much lately. I like to replay some
old LucasArts games from 1991-1992 :-)
> I see you've been busy :) Be careful, they might make you a committer :)
What about you? Would you accept it if they offered you a committer
position? Or "the train has gone" ? ;) I believe that they move to
WW/Shale and need people for 1.x. Incidentally, this is where my
interest is. I don't know about you.
Well, hope your book will be released soon!
Michael.
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: How to avoid lots of "if else" in Action class.
Posted by "Frank W. Zammetti" <fz...@omnytex.com>.
No, sorry, never did get around to reading it... I meant to, but the
book is all I've had time for since pretty much January. I actually
really can't wait to be done with it, at least the initial writing.
There's so many things I'd like to be working on right now! The current
project, while being really fun, has been a TON of work (an AJAX-based
adventure game). I can't remember the last time I got a full nights' sleep.
I see you've been busy :) Be careful, they might make you a committer :)
Frank
Michael Jouravlev wrote:
> My article is out:
>
> http://today.java.net/pub/a/today/2006/05/04/almost-portlets.html
>
> I bet you haven't read the draft that I've sent you :-) How's your
> book going? This #$%@ing article took me almost a month. I updated it
> 15 times or so. The book... oh, this should be really tough :)
>
> Michael.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>
>
>
--
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!
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: How to avoid lots of "if else" in Action class.
Posted by Michael Jouravlev <jm...@gmail.com>.
My article is out:
http://today.java.net/pub/a/today/2006/05/04/almost-portlets.html
I bet you haven't read the draft that I've sent you :-) How's your
book going? This #$%@ing article took me almost a month. I updated it
15 times or so. The book... oh, this should be really tough :)
Michael.
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: How to avoid lots of "if else" in Action class.
Posted by "Frank W. Zammetti" <fz...@omnytex.com>.
On Thu, May 4, 2006 3:56 pm, Michael Jouravlev said:
> I see the value of a dispatch action primarily as input (post-,
> submit, accept) action, not as a render (pre-, setup) action. Your
> /showAccont.do mapping is a render action, therefore it will likely
> not be covered by dispatch action.
>
> /updateAccount.do is an input action, you would likely protect this one.
>
> On the other hand, the above "*.do" things are not actions, they are
> action _mappings_. Two mappings can refer to the same action class.
> The roles protect URLs, not actual Java classes (roles do not have to
> know anything about Struts). So here you are: you can have two or more
> mappings in a struts-config.xml file that refer to the same action
> class, which it turn, combines all needed functionality.
Ah, you know, brainfart moment here... you are of course right! :-) I
could blame it on the 4-5 hours of sleep a night I've gotten the past two
months, but I won't. Should have seen the obvious, but didn't. D'OH.
> Michael.
Frank
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: How to avoid lots of "if else" in Action class.
Posted by Michael Jouravlev <jm...@gmail.com>.
On 5/4/06, Frank W. Zammetti <fz...@omnytex.com> wrote:
> 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 see the value of a dispatch action primarily as input (post-,
submit, accept) action, not as a render (pre-, setup) action. Your
/showAccont.do mapping is a render action, therefore it will likely
not be covered by dispatch action.
/updateAccount.do is an input action, you would likely protect this one.
On the other hand, the above "*.do" things are not actions, they are
action _mappings_. Two mappings can refer to the same action class.
The roles protect URLs, not actual Java classes (roles do not have to
know anything about Struts). So here you are: you can have two or more
mappings in a struts-config.xml file that refer to the same action
class, which it turn, combines all needed functionality.
Michael.
P.S. You should've rather hijaacked this thread ;-)
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: How to avoid lots of "if else" in Action class.
Posted by "Frank W. Zammetti" <fz...@omnytex.com>.
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 <fz...@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 <jo...@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
Re: How to avoid lots of "if else" in Action class.
Posted by Michael Jouravlev <jm...@gmail.com>.
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.
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 :-)
I will think on more benefits of dispatch actions :)
On 5/4/06, Frank W. Zammetti <fz...@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 <jo...@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
Re: How to avoid lots of "if else" in Action class.
Posted by "Frank W. Zammetti" <fz...@omnytex.com>.
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 <jo...@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
Re: How to avoid lots of "if else" in Action class.
Posted by Michael Jouravlev <jm...@gmail.com>.
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 <jo...@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