On Fri, 03 Dec 2004 12:40:49 +0100, Sylvain Wallez <[EMAIL PROTECTED]> wrote:
<snip> lots of discussion on taglibs and templates</snips> > Taglibs are to templates just what factorization in classes and methods > are to Java code. Taglib features could equally well be provided as > extension functions to the expression language, but writing them in XML > (either with tags or attributes) just seems more consistent with the XML > world of the view layer. There is another way. It's sort of weird and in it's simplest implementation requires modern browsers but you previously asked how our templating system works, so I might as well fill you in on how we handle things like this. First we separate the concept of "screens" (or pages) from templates, there can be multiple templates per screen. Each template has a base type, the two most important for this discussion being "edit" and "grid". A edit template allows random positioning of individual objects anywhere on the screen using relative positioning and XSLT ordering of the objects (to make the CSS calculation of the relative positioning easier). A grid produces a regular table. Either of these layouts can contain the other. We use iframes to embed any given template within another. This couples a single URI to any given template. We have a special form of object known as a "key" that is used for managing relationships between collections of data and when you embed a template within another any key values from the first are automatically passed to the second as request parameters on the iframe src. Thus, mapping one to may relationships in the database has an exact equivalent at screen creation time and you don't end up denormalizing in you query and then splitting things back apart at presentation time. There is a requirement to make sure that the appropriate screen types are mapped to the correct data producers on the back end. We have logic that automatically selects between screen types if multiple matches are defined, but if all you have is a "edit" screen and the keys you get passed from your container result in multiple rows being produced you will see only a single edit screen (though I guess we could automatically produce the corresponding grid in this case). I said at the beginning that the simplest implementation requires appropriate browser support, that being iframes. However, you could manage this all on the back end, doing essentially server side embedding of the templates within each other and still mapping the population of each portion to the proper URI. From what I've read I don't think the result would be much more complex than some of cforms (or the existing templating proposals for that matter)... IOW, if you need to refactor templates, allow templates to be normalized WRT to each other. I don't think you need a new concept.... -- Peter Hunsberger
