On Sat, 12 Mar 2005 17:52:17 -0500, Mike Kienenberger <[EMAIL PROTECTED]> wrote: > David Geary <[EMAIL PROTECTED]> wrote: > > I think this is all good stuff, but I'd rather see integration with > > Tiles instead of reinventing Tiles. Tiles has already covered some of > > this ground and I see no reason for us to follow. > > I haven't used JSF enough to see if it fits the same pattern, but the > component-based frameworks I've used in the past have always made Tiles > unnecessary. Components are "tiles". >
The ability to create layout components was indeed one of the motivations for the API design in JSF. Indeed, if you are using a templating approach that does *not* allow intermixing static template text (which is not the case for JSP, or for Tapestry), then you are pretty much stuck with using components to do your layout for you. The benefit, on the other hand, is that you can delegate responsibility for dealing with all the nit-picky details (such as browser incompatibilities) to your layout components, instead of having to deal with them in your reusable template text fragments. > You build a component representing your layout and stick your other layout > components in it. Then you reference your layout component from your > general application pages. > > An example (and possibly not the best example) from a four-year-old > Webobjects project. Note that WebObjects (and Tapestry as well from what I > understand -- RenderBody?) both allow you to access the parent document > content. It's unclear to me whether JSF is "component-based" enough to do > this as I haven't built any components with it yet. (Someone asked me this > question last week, and I haven't had time to find an answer yet.) When you use <f:subview> in JSF, the components defined in the dynamically included fragment (a tile, in the case of Tiles) are grafted in to the component tree of the parent page, so you can use getParent() recursively to access "outer" state. Is that what you meant? > > Component-based models allow you to do things differently, and I'm just > wondering if you're dragging some "old-school" methodologies into it > unnecessarily. Perhaps the answer is that there's no need to reinvent Tiles > OR integrate Tiles. There are people who like both philosophies. Especially people that have existing Tiles based applications that they wish to port. It's not (yet) clear to me that Shale should only cater to one or the other approach. > > -Mike Craig --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
