That's interesting...
One limit is that apart from "screen content", all references come from #set()
directives (like $page_title in the sample).
Suppose one may have several big portions of text to include at several points in the
template, how could it be done ?
One constraint is that all those portions of text do reside in the same (content) text
file (otherwise content edition becomes
specific and complicated...).
So my guess would be to prepone a "retro-layout" parser that would take as input a
template like
<javascript>
bla${foo}blabla....
</javascript>
<content>
morebla${bar}blabla...
</content>
and merge it into the layout with
$javascript = bla_foo_blabla...
$content = morebla_bar_blabla...
This must not be very far from the principles of some publication frameworks, I
dunno...
Another example : take as input standard html content template files, and merge them
into layout html files, WITHOUT using frames
:-)
Only by separating and merging the head and body portions. Wouldn't it be nice ?
The parsing step would then occur in the mergeTemplate process.
Also, the result of this parsing should be cached for efficiency.
But the weak point I see is that content files are no more velocity templates, as they
must be sliced down before the merging
process...
No problem ! Let's have a child class of Template do the parsing ! And we recover the
cache at the same way...
Any advice or remark, should I find the time to try it ?
CloD
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
