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>