On 4/25/06, Michael Jouravlev <[EMAIL PROTECTED]> wrote: > > On 4/25/06, Craig McClanahan <[EMAIL PROTECTED]> wrote: > > According to the APIs, it is actually one Controller per Tile, not one > > Controller per page ... doesn't that give you (Michael) the hook you'd > need > > to grab the dynamic data for each fragment? > > I guess it does. But how is this better/different than simply > including Struts actions or any other resources?
I found a pointer to Cedric's old web site[1] from the days before Tiles was contributed into Struts. The "advanced features" link there has some extended discussion of controllers (as well as a bunch of the other features of Tiles). Also, can I submit to a particular controller? Does a controller have URL? Sort of. You can define the logic that implements a controller either as a Java class that implements Controller, or as a Struts Action. But I think it's simpler to think of the execution of the Controller as a side effect of invoking the Tile's URL, immediately before the Tile is rendered. Thinking of it this way means you don't have to consciously map one kind of URL for Tiles that have controllers, and a different type for Tiles that don't. Use the URL of the Tile, and the right logic will get automatically invoked, if that particular Tile needs it (i.e. if there is dynamic data to go collect). By the way, the Tiles Controller was one of the inspirations for Shale's ViewController, where the prerender() callback is used for exactly the same sort of thing. I guess I have to go read the docs one more time. Please excuse me for > heating up the discussion without checking the facts. > > Michael. Craig [1] http://www.lifl.fr/~dumoulin/tiles/
