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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] >> 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 <[EMAIL PROTECTED]> 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: [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] >> >> > > --------------------------------------------------------------------- > 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]
