You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@turbine.apache.org by John McNally <jm...@collab.net> on 2002/01/17 04:34:05 UTC

Re: Are navigation classes in for the same fate as screenclassesin Turbine-3

I wrote DirectRenderer and DirectClassicPipeline so that the response is
not created as a large String.  It is not required by the
layout/navigation/screen system.

john mcnally

Jason van Zyl wrote:
> 
> On 1/16/02 10:37 AM, "Gareth Coltman" <ga...@majorband.co.uk>
> wrote:
> 
> > Hi,
> >
> > Sorry about my previous post, it wasn't intended to go to the list, but it
> > doesn't matter!
> >
> > Anyway, Jason posted:
> >
> >>>>>>>
> > No problem. Turbine 3 at the core will have no knowledge of a screen,
> > navigation or layout but the model (the classic model) will still be a valid
> > usage pattern. Scarab is currently using Turbine 3 along with screens,
> > navigations and layouts. How you structure your view will be determined by
> > the collection of valves used. Turbine will be stripped down to a core
> > system upon which anything can be built. The classic model was the first
> > thing implemented and works so your screen, navigation and layout templates
> > can be used in Turbine
> >>>>>>>>> .
> >
> > I guess what I am wondering is whether the 'classic' templating model is
> > what will be suggested for use with Turbine 3. The thing I like about this
> > way of doing things, is that once you have setup layouts and navs, you don't
> > have to worry about them anymore. Has anybody else found a better way to do
> > templating, or is this still the best?
> 
> I think the idea is good but it definitely has the very strong disadvantage
> of not streaming. All the output is buffered before being sent to the
> browser which is bottleneck. I have seen this and Daniel has also notice
> performance problems with this model. I myself am going to try and come up
> with something that will be convenient like the classic model but stream
> instead of buffer.
> 
> >
> > Gareth
> >
> >
> > --
> > To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
> > For additional commands, e-mail: <ma...@jakarta.apache.org>
> 
> --
> 
> jvz.
> 
> Jason van Zyl
> 
> http://tambora.zenplex.org
> http://jakarta.apache.org/turbine
> http://jakarta.apache.org/velocity
> http://jakarta.apache.org/alexandria
> http://jakarta.apache.org/commons
> 
> --
> 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>