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).
Two similar concepts in other places might provide fodder for names: * In WW/Sttruts2 the corresponding concept is the Preparable interface ... it might be nice to use the same name if the concept applies directly. If that might be too confusing, then Preparer would likely be better (although it is a bit awkward to pronounce). * In Shale, the corresponding concept is the prerender() method of the ViewController interface. That name was chosen to set the connotation that "get the data I'm going to need to render this view" is what code should actually go here. Craig
