I think "controllers" should stay, but the name should be changed. Call them ViewPreparers or something...
On 10/5/06, Greg Reddin <[EMAIL PROTECTED]> wrote:
On Oct 5, 2006, at 9:53 AM, Antonio Petrelli wrote: >> * The controllers were added to allows stand alone use of tiles to >> be able to do some kind of computation associated to the tiles. >> When used with Struts, there is a redundancy (with the use of >> actions), but when used alone, the controller mechanism is very >> useful to separate view rendering from controller business > > The problem with Tiles controllers is that the controller is not > able to > choose between different destination pages. It misses an important > part > of a controller: the dispatcher. > But using a normal url as a template (or tile :-) ) it can do both > calling the model and dispatching. If you download the latest version > from SVN, there is a test with a simple servlet that includes a (fixed > for the moment) JSP page. > And I think that including a Controller in a View layer technology is > not a good idea. 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. It just so happens that the controller API gives you indirect access to the request and response objects so you could use them to include or forward or write directly to the response and all the other stuff you can do there. But I'd not recommend the controller be used in this way. I would use the controller to manipulate the TilesContext and the JSP contexts, but not to actually "do anything" with regards to changing the destination. In today's world if I was writing a Struts app with Tiles I would try to use JSTL, EL, custom tags, (or in JSF, action listeners, etc). to do things I did in the past with controllers. But I can still see circumstances where I might want a controller instead. Think about this: Tiles can be used for page composition outside of any MVC framework. In that sense it's kind of like a portlet container. (In fact I think that's how Cedric envisioned it before JSR-168 came about). So you can compose pages out of JSP fragments and populate each fragment with a controller that is executed before the fragment is processed and included. I actually have written a couple of small webapps that use Tiles in this way and see it as a powerful feature. I think we should retain the controller for Tiles definitions (not sure about the insert tag). I also think we should document the fact that you can get yourself into all kinds of trouble by making improper use of the request and response APIs from within the controller. Thoughts? Greg --------------------------------------------------------------------- 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]
