On 10/6/06, Antonio Petrelli <[EMAIL PROTECTED]> 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?
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).
How about TilePrep? It's shorter and can stand for either/both
Preparer or Preprocessor.
> 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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
