Re: VelocityViewServlet extensions

[Nathan Bubna <na...@esha.com>]

Andy Freeman said:
> Hi Nathan,
>
> I apologize for this not going to the list but I do not have this account
> set up to send messages to the list.  Anyway, would you mind posting your
> layout extensions (layouts, custom error screen, etc.) to the VVS to the
> mailing list?
...

ok.  here's a stripped down version of what i'm doing (the one i'm actually
using has some other app specific stuff), but this is pretty much the guts
of it.  I hope it compiles (i just yanked out the proprietary stuff and
didn't try it out.   Included are an example layout and error template.  I
don't think this belongs in the Velocity-Tools project, but if people wanted
(and Geir was willing :), it might fit well into a contrib section.  In any
case, it's attached to this email.  enjoy!

Nathan Bubna
nathan@esha.com

Re: VelocityViewServlet extensions

[Claude Brisson <cl...@savoirweb.com>]

hum... I'm wrong on one point :

> And we recover the cache at the same way...

false, since reference values may have changed...
but the remaining does still make sens to me

CloD



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: VelocityViewServlet extensions

[Nathan Bubna <na...@esha.com>]

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
nathan@esha.com


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: VelocityViewServlet extensions

[Claude Brisson <cl...@savoirweb.com>]

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:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: VelocityViewServlet extensions

[Nathan Bubna <na...@esha.com>]

Geir said:
...
> As much as I myself adore the "Faith-based" compilation strategy, can you
> make sure it compiles, maybe add a touch of doc (.txt is fine) and yes, we
> can drop into contrib.

ok, i can now confirm that it compiles and works like a charm.  O ye of
little faith! :-)
a touch of doc is attached.  (longer than i planned, when i type i get a bit
verbose.  oh well.)

Nathan Bubna
nathan@esha.com

Re: VelocityViewServlet extensions

["Geir Magnusson Jr." <ge...@adeptra.com>]

On 7/17/02 1:57 PM, "Nathan Bubna" <na...@esha.com> wrote:

> Andy Freeman said:
>> Hi Nathan,
>> 
>> I apologize for this not going to the list but I do not have this account
>> set up to send messages to the list.  Anyway, would you mind posting your
>> layout extensions (layouts, custom error screen, etc.) to the VVS to the
>> mailing list?
> ...
> 
> ok.  here's a stripped down version of what i'm doing (the one i'm actually
> using has some other app specific stuff), but this is pretty much the guts
> of it.  I hope it compiles (i just yanked out the proprietary stuff and
> didn't try it out.   Included are an example layout and error template.  I
> don't think this belongs in the Velocity-Tools project, but if people wanted
> (and Geir was willing :), it might fit well into a contrib section.  In any
> case, it's attached to this email.  enjoy!

As much as I myself adore the "Faith-based" compilation strategy, can you
make sure it compiles, maybe add a touch of doc (.txt is fine) and yes, we
can drop into contrib.

-- 
Geir Magnusson Jr. 
Research & Development, Adeptra Inc.
geirm@adeptra.com
+1-203-247-1713



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>