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?
Possible names could be:
* Controller for the class (or maybe TilesController) - controllerClass
and controllerUrl for tag attributes
* ViewPreparer (or TilesPreparer) for the class - preparerClass and
preparerUrl and for the tag attribute (thanks Nathan!);
* TilesPreprocessor - preprocessorClass, preprocessorUrl (this is what I
suggest).
I think we should retain the controller for Tiles definitions (not
sure about the insert tag).
I have the same doubt, especially for controllerClass in <tiles:insert>:
every time a new instance of that controller is created! Should we
provide a caching mechanism, or remove the controllerClass at all?
Ciao
Antonio
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
