On 4/25/06, Michael Jouravlev <[EMAIL PROTECTED]> wrote: > > On 4/25/06, Greg Reddin <[EMAIL PROTECTED]> wrote: > > > if I have a > > > composite page out of three JSP files, how would I run their > > > corresponding setup actions before the page is composed? > > > > > > Instead of including JSP pages I would include Struts actions (Will it > > > work with Tiles? I haven't tried it yet) like this (seems that I can > > > use include directive instead of dynamic include tag here): > > > > The thought scares me :-) I haven't tried it like that. Tiles used > > to allow you to specify a Struts action as a controller. It probably > > still does but I haven't used that pattern in a long time and I can > > guarantee that Standalone Tiles will not support that. > > I don't see why Tiles would care what kind of resource I want to use > to compose my page. At the higher abstraction level, I want to provide > a URL, and Tiles should obtain response generated by resource at this > URL, be it JSP fragment or Struts action or whatever else. > > > You should > > really check out the Controller interface. Sorry, the documentation > > is non-existent currently, but it's in the pipeline. It allows you > > to specify a controller class that will be executed before the > > definition is rendered. In that class you have access to the Tiles > > Context and whatever else you need. The only drawback is that I > > don't believe you can specify a controller for each piece of the > > composite page. > > Having one controller is better than having nothing.
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? Craig Consider this. Say, most fragments do not contain dynamic data, like > static header or footer. I can use Tiles or I can use two JSP includes > in a separate file, and include this file. Same thing? > > Now, I have header and footer, and both require dynamic data from > database. Who is going to pull it out? Apparently, Struts action. > Which one? You said I can specify one controller. So this controller > should know that it pulls data for two specific fragments. Now I have > a controller tied to two fragments. Is this a good programming > practice? What if I later decide to add, say, an advertisement block? > Should I modify the controller to pull info from the database with ads > as well? What if I want to use this ad block only on some pages. > Should I have two different controllers? See, this is what I am > talking about. Tiles combines view sections, not components. > > The point I am trying to make, it seems to me that Tiles helps with > composing a page from simple subviews. But when a subview requires > dynamic data, Tiles does not really help. With Tiles, actions and JSP > fragments are separated. There are mostly independent JSP fragments, > there are controllers (one per page), there are input actions, that > process submitted data. This arraingment does not seem observable and > manageable to me, contrary to what Rick and you say. Maybe I am > missing something. Please excuse me if I sound pushy, I just really > try to understand the benefit of Tiles. > > But returning back to my original question, I did not intend to > badmouth Tiles and to push my own ideas. I just asked, how Tiles > compares to XHTML+CSS. As I understood, the major Tiles benefit is > handling "dynamic" data, and encapsulating it in one single place like > definition file. But my example with dynamic data from database seems > to show that this setup is not possible with Tiles, Struts actions > must be involved. > > Therefore, for static headers/footers regular JSP includes seem fine. > On the other hand, if I have highly dynamic data for every fragment, I > need to call respective setup actions, and it is not possible with > Tiles right now. As you stated, I can have only one controller per > definition. In both cases, Tiles is either on par with JSP includes, > or has some serious constraints. > > What am I missing? > > Michael. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
