Dave Newton wrote:
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.
Dave, does that mean you don't favour one approach over the other? ie.
happy with multiple methods per action?
I've never settled on only "one action class per action" or only
"multiple action methods per action". I've found both conventions have
their time and place, although I've been longing for a consistent approach.
I use action!method notation a lot despite a hatred of it. However I
have been trying to phase out GET's to action!input and replace them
with a GET to a clean URL and use the wildcard notation only for posts.
I also only use doMethod notation (ie. method="do{1}") as a precaution
against arbitrary method calls.
Your preparable lifecycle points are well received here.
The "one action class per action" approach is clean and tidy on small
applications but I find it blows configuration out exponentially on
large apps (although codebehind fixes that)
My latest favourite approach is as per RoR/the rest plugin - that is, a
set of WELL KNOWN action methods per action class, rather than just
execute() or arbitrary action methods per action.
I'd appreciate hearing what others have settled into?
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
