On 10/18/07, Carsten Ziegeler <[EMAIL PROTECTED]> wrote: > Hi, I have thought a little bit more about template handling and I came > to the conclusion that we could add support for it to the heart of > Sling. (For now, I'm refering to the "old" sling - current trunk, we can > adapt this to the new stuff later on). > > Ok, let's start with an example. Assume you have a template for a page > with a header, a footer and content (yes, it's that famous example again > - but this time its a good one). Now, you want to create pages from this > template which just refer to the header and footer but obviously have > their own content. The structure in the repository could look like this: > > Template A > + footer > + header > + content > > Page One > + content > > Now, when the page is rendered, the component doing this should know > that it has to render the header first, then content and then the footer > (or perhaps it's for upside down people and it renders the footer first, > who knows). > > Ok, so the first information, the Page One needs to store is from which > template it was generated, so we could add a property like > "sling:template" to the Page One node which contains the path to > "Template A". > > The component rendering the page could now check if Page One has a child > header, if not it goes to the "Template A" node and uses that header and > so on. This would work, but requires a lot of coding in the component. A > lot of nasty tests. > > So, I thought of a more transparent way :) > > Currently the request has the getContent(String) method. We could modify > the implementation that this method does some more checks if the path is > relative: > a) If the current node has a child with the relative path, this child is > used. > b) If the current node does not have a child with the relative path, the > current node is checked for a "sling:template" property. > b)I) if the node has no "sling:template" property, the current node is > changed to the parent of the current node, and we continue with b) > b)II) if the node has a "sling:template" property, the referenced > template node queried of it contains a child with the given relative > path. If it has such a child, that one is used, if not we go back to b). > > Now, if b) is called several times, there will be some path > concatenation, like in the following: > Template A > + footer > + copyright > Page One > - sling:template = "/Template A" > + footer > > Now, when the footer node of Page One is rendered it checks for its > "copyright" child which is not there. Now footer is checked for the > sling:template property and then Page One is checked. The sling:template > property points correctly to "Template A", but of course "copyright" is > a child of footer. > As our algorithm knows that it has stepped up from "footer" to Page One, > it will concatenate sling:template + "footer" + copyright (of course > with the correct path separators etc.) > > > Does this make sense? WDYT?
hi, once again this is display logic. the 'main' component script knows that it needs to display a header and a footer, so basically you do a: <sling:include componentId="footerComponent" content="footer" /> then the footer component will check if it actually has content, and if not, it fetches it from the parent page or whatsoever. imo, templates are great for copying some default content structure but are useless for meaningful default content. regards, toby -- -----------------------------------------< [EMAIL PROTECTED] >--- Tobias Bocanegra, Day Management AG, Barfuesserplatz 6, CH - 4001 Basel T +41 61 226 98 98, F +41 61 226 98 97 -----------------------------------------------< http://www.day.com >---
