struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dave Newton <>
Subject Re: How Many Methods Must an Action Walk Down (was Re: Annotation Validation, per method?)
Date Wed, 07 Nov 2007 23:39:59 GMT
--- Gary Affonso <> wrote:
> Ted Husted wrote:
>> Meanwhile, in Struts 1 there is a "DispatchAction"
>> that does much the same thing. From other
>> discussions, I gather that "multiple actions per
>> controller" is considered a Good Thing on platforms
>> like Ruby on Rails.

It's really only a Good Thing in RoR because the
framework and markup makes it easier to do it that
way: it's a result of RoR's opinionation... Linking to
a different action requires an additional parameter in
the link tag "custom tag"; a conceptual equivalent
might be an S2 link with a "namespace" attribute in
addition to a configured "action" name.

> But for what I do with it (fairly typical webapps)
> one-action-class-per-action has served me very well.

I don't think anybody's saying that it's a bad idea,
but the framework does sort of "gently nudge" a
developer in the multiple-methods-per-action-class
(see below).

> I have limited experience using webwork/s2 with AJAX
> (I assume this is what you mean by "rich controls").

I think we're just talking about any type of control
that requires some form of preparation on the server
side; an Ajax control could be loaded by any
action/method on page load.

> Curiously, action!input is not a part of the
> framework I'm familiarwith.  Can you point me
> to some docs that describe it?

Look at the "Dynamic Method Invocation" section,
1/2-2/3 of the way down.

> Again, not one *method*.  That'd be crazy!

That's what's being discussed, I'm pretty sure, but
with an eye towards a different "prepare" cycle: the
whole Preparable lifecycle makes more sense if there
are multiple (request-handling) methods in an Action
class. If there's only "execute" you don't gain very
much by having the framework call prepare(), and I'd
probably even argue it's less clear than calling it
manually from execute().

If, OTOH, you have several methods that all require
identical preparation then a prepare() in each method
is a bit noisier than letting the framework call it.

(This was just discussed on a current project and that
seemed to be the general consensus, anyway, but for
the most part I agree with it.)


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message