On 10/5/06, Nathan Bubna <[EMAIL PROTECTED]> wrote:
I think "controllers" should stay, but the name should be changed. Call them ViewPreparers or something...
I would agree. The useful thing you can do here is prepare the data needed to do the subsquent rendering. It is called *after* the controller has already dispatched and chosen which view to render. Craig 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]
