Dave Newton wrote:
Curiously, action!input is not a part of the
framework I'm familiarwith. Can you point me
to some docs that describe it?
>
> http://struts.apache.org/2.x/docs/action-configuration.html
>
> Look at the "Dynamic Method Invocation" section,
> 1/2-2/3 of the way down.
Well, that explains it. The wildcard feature seems to come from s1
(which I never used) and the "dynamic method invocation" feature wasn't
very well documented (not even named) until s2.
Thanks for the pointer, this is good stuff for me to know. The vast
majority of my experience is with WebWork. For the most part s2 has
been like slipping into a nicely worn pair of shoes.
But then I find out somebody added blinky light in the soles. :-)
I still have a hard time imagining using either of those features. I
completely get why they are there. There was a time where I valued
brevity over clarity, too. I guess I'm gettin old.
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().
I'd say that argument is more valid for the validate() method. It
really does offer nothing besides a dedicated method for doing something
just as easy to do in the first part of "execute()".
But for prepare() that's not the case (at least for me). The prepare
interceptor is typically called after the first of two "params"
interceptors. Something like...
params interceptor
prepare interceptor
params interceptor
...more
This is a pretty elegant way to deal with hydrating objects from IDs
embedded in the form and then doing direct-model-injectition into that
recently retrieved object from fields in the *same* form.
Example...
If your view does this:
<input type="hidden" name="addressId" value="123">
<input type="hidden" name="address.name" value="new name">
<input type="hidden" name="address.zip" value="38123">
Then prepare() allows you to use the first "params" interceptor to scoop
up the ID, the prepare method to go get an "Address" object
corresponding to that ID, and then the second "params" interceptor to
scoop the address-specific fields in the form into that recently
hydrated object.
In other words, your action gets *two* shots at accepting injected form
data.
That's not do-able with just the execute() method.
I mean it *is* do-able but you start having to do things like provide a
temporary address object to capture the form data (in addition to an ID
property) and then in execute() go get the *real* address object
after-the-fact (using the ID) and then transfer the address data from
the temp object to the real address object.
Prepare seems way better and way more clear. Or did I miss something?
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.
I absolutely agree. If you're doing a ton of the same preparation for
your action methods then you should consolidate that into a single place.
But, to paraphrase what as I said earlier, if you're doing a ton of
preparation for your Action methods, there's probably a better place to
put that code than in your Action.
Everybody, at this point, seems to "get" that you put as little java
code as possible in the view (JSP, etc.). That's something that I think
we need to start preaching for the Action as well...
Put as little code as possible in the Actions!
Put the code in domain objects, service objects, dao objects,
business-logic objects, etc. but keep it out of the action!
Uh, are we still talking apples-to-apples here? I think maybe I got off
on a tangent.
:-)
- Gary
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
