Claude said:
> That's interesting...
>
> One limit is that apart from "screen content", all references come from
#set() directives (like $page_title in the sample).
not quite true. there are still configurable tool references and the
hard-coded req/res/sess/app references.
> Suppose one may have several big portions of text to include at several
points in the template, how could it be done ?
#parse() and #include() can come in pretty handy
> One constraint is that all those portions of text do reside in the same
(content) text file (otherwise content edition becomes
> specific and complicated...).
hmm. one man's complication may be another's simplicity, i like separate
things in separate files. but, yeah, #parse and #include won't help you
much here. dare i suggest writing a tool?
> 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...
or perhaps
$contentTool.javascript
$contentTool.content
if you define your content in xml, it shouldn't be too hard to write a tool
that can grab the content of the an arbitrary node in the file. then i
think you would just need to feed that string through Velocity.evaluate()
(with the current context and a writer) and return the result of that.
> This must not be very far from the principles of some publication
frameworks, I dunno...
i dunno either.
> 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 ?
hmm... you probably won't catch me writing or using it, i have no need for
that whatsoever. but i guess i might imagine how someone might find it
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 ?
i think writing a tool would be a better approach.
Nathan Bubna
[EMAIL PROTECTED]
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
