You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@velocity.apache.org by "Geir Magnusson Jr." <ge...@adeptra.com> on 2002/05/14 20:23:31 UTC
Re: Streaming text contents when using Velocity for HTML templating.
On 5/14/02 1:50 PM, "Nikolaj.Brinch.Joergensen@sdk.sas.com"
<Ni...@sdk.sas.com> wrote:
>
> Hi,
>
> I'm doing an app. where I have som context objects that potentially produce
> very large outputs (data tables).
> I wonder if there is any way I can stream those objects back, so I don't
> have to create a BIG string object on the server (100-1000 of users, and the
> server will suffer from having to create this in RAM for every user).
>
> I know that I can do this with JSP, but I really don't want to go down that
> path, as Velocity is a much cleaner approach to dynamic page generation.
> Actually my context objects are beans that implements a method
>
> public void write(java.io.Writer out);
>
> Which make the bean stream to the Writer.
Hm. You might be able to get away with this. Put the writer itself into
the context
context.put("writer", writer);
$foo.write($writer)
Maybe...
--
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>
RE: Streaming text contents when using Velocity for HTML templating.
Posted by Bill Boland <bo...@attbi.com>.
Interesting problem.
I like the solution that Geir suggested trying. I was going to try this
out myself except that I needed to override the mergeTemplate() method
from the VelocityServlet class into my subclass Servlet. This is where
the VelocityWriter is created or retrieved from a pool and the merge is
performed. Even with the warnings in the doc to override this only if
you really, really need to (I think this would be a good a reason). I
then ran into a snag that the writerPool attribute is private without a
method to access it. So it looks like it might be easier to try this
with a copy of the VelocityServlet than trying to extend it.
BUT...this shows where an enhancement would be nice to have. If the
statement in the mergeTemplate() method of:
template.merge( context, vw);
was replaced with:
performMerge( template, context, vm );
where performMerge was a protected method of VelocityServlet with the
original statement as its default behavior, then you could easily
override this method in a subclass of VelocityServlet to place the
writer into the context. The VelocityServlet could still manage the
private writerPool.
I know this borders as a development topic, but it was interesting and I
thought worth sharing.
bill
-----Original Message-----
From: Geir Magnusson Jr. [mailto:geirm@adeptra.com]
Sent: Tuesday, May 14, 2002 11:24 AM
To: velocity-user@jakarta.apache.org
Subject: Re: Streaming text contents when using Velocity for HTML
templating.
On 5/14/02 1:50 PM, "Nikolaj.Brinch.Joergensen@sdk.sas.com"
<Ni...@sdk.sas.com> wrote:
>
> Hi,
>
> I'm doing an app. where I have som context objects that potentially
produce
> very large outputs (data tables).
> I wonder if there is any way I can stream those objects back, so I
don't
> have to create a BIG string object on the server (100-1000 of users,
and the
> server will suffer from having to create this in RAM for every user).
>
> I know that I can do this with JSP, but I really don't want to go down
that
> path, as Velocity is a much cleaner approach to dynamic page
generation.
> Actually my context objects are beans that implements a method
>
> public void write(java.io.Writer out);
>
> Which make the bean stream to the Writer.
Hm. You might be able to get away with this. Put the writer itself
into
the context
context.put("writer", writer);
$foo.write($writer)
Maybe...
--
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>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>