On Oct 6, 2006, at 2:27 AM, Antonio Petrelli wrote:
Greg Reddin ha scritto:
Here's what I envision for the controller: I don't think it would
really be used to change the destination of the response. I don't
see the controller as being analogous to a Struts action even
though it could be used in that way. If I wanted the controller
to be used as a "controller" in the MVC sense of the word (IOW to
select a destination) I'd want it to return something like actions
do in Struts, WebWork, and JSF. I've always used the controller
like a JSP tag. I use it to implement code that needs to reside
in the view layer (or code that needs to be called from the view
layer) and as a way to keep from writing scriptlet code in my JSPs.
Uh I see, I think it's time to resurrect controllers (I think it's
needed only in the TLD). Now what about their name?
I think we still want to support it in the DTD for the <definition>
tag. When I've used controllers I've always declared them in the
tiles-defs.xml file.
Possible names could be:
* Controller for the class (or maybe TilesController) -
controllerClass and controllerUrl for tag attributes
Well, it's the controllerUrl I have the most trouble with. I don't
have any problem with declaring a class to be executed to prepare the
view. But an URL? An URL will always resolve to something - return
a response - and I don't think these view preparers should return
anything or resolve anything. They should simply be capable of
manipulating the context - preparing the context for the view (IMHO).
* ViewPreparer (or TilesPreparer) for the class - preparerClass and
preparerUrl and for the tag attribute (thanks Nathan!);
I think I like ViewPreparer the best.
Greg
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
