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?
Carsten
--
Carsten Ziegeler
[EMAIL PROTECTED]
