You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@turbine.apache.org by Mike Haberman <mi...@ncsa.uiuc.edu> on 2001/11/12 17:46:22 UTC
updates to the 3.0 source tree
Hello All,
Unfortunately, I've been doing non turbine stuff here for a few months..
So I haven't been very active. But I have 3 sites that are using
turbine-3 code since Aug/Sept. (before fulcrum was separated) that have
been running beautifully. I want to build both using the latest
in cvs, but would like to integrate my patches into the 3.0 source:
1. I created a Runner object whose responsibility is just to
run the module (and removed this from the Renderer). The
Renderer only renders the template/target. The Runner, runs the
module. Also, if the target changes after the run, it is run
again (and so ad infinitum).
2. Incorporated the above in ClassicPipeline.
The above, actually speeds up the classic pipeline a bit.
3. can we make Resolver an interface:
String getTemplate(moduleType, target)
Module getModule(moduleType, target)
Then
1. ModuleLoader can use the Resolver
2. I can plug in my own Resolver. (I use a different
search algorithm then the default).
The current Resolver implementation can be the DefaultResolver.
4. Also, for those of us using velocity is there any advantage
to using render.render(.....) in the templates over #parse(...) ?
(Since renderer no longer runs a module, #parse has been working
fine for me)
5. With the way the Runner and the Renderer now work, we can
actually put $screen_placeholder back in the context as we
do in 2.1. I know some didn't want to waste the extra
memory required to this, but the first thing I need to do
in my template is "$body = $renderer.render(...)" anyway.
Just a thought to keep things easier for the migration.
I know jason has 3.0 code yet to commit that affects the pipeline, but
I would help me out a great deal if I can go ahead and commit the
small changes. I think others (that use the 3.0 code) can benefit
from it as well.
Thanks, hope all is well. Sorry I haven't been able to
contribute much. I like the changes and direction of
both torque and fulcrum. Keep up the great work.
mike
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: updates to the 3.0 source tree
Posted by John McNally <jm...@collab.net>.
Mike Haberman wrote:
>
>
> 5. With the way the Runner and the Renderer now work, we can
> actually put $screen_placeholder back in the context as we
> do in 2.1. I know some didn't want to waste the extra
> memory required to this, but the first thing I need to do
> in my template is "$body = $renderer.render(...)" anyway.
> Just a thought to keep things easier for the migration.
>
why do we want to do this? It seems a step backwards.
john mcnally
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: updates to the 3.0 source tree
Posted by Daniel Rall <dl...@finemaltcoding.com>.
Jon Stevens <jo...@latchkey.com> writes:
> on 11/12/01 9:03 AM, "Jason van Zyl" <jv...@zenplex.com> wrote:
>
>> What about render()?
>>
>
> Can we change that to doRender() to be consistent?
+1, more bean like as well.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: updates to the 3.0 source tree
Posted by Jon Stevens <jo...@latchkey.com>.
on 11/12/01 9:27 AM, "Jason van Zyl" <jv...@zenplex.com> wrote:
> On 11/12/01 12:23 PM, "Jon Stevens" <jo...@latchkey.com> wrote:
>
>> on 11/12/01 9:03 AM, "Jason van Zyl" <jv...@zenplex.com> wrote:
>>
>>> What about render()?
>>>
>>
>> Can we change that to doRender() to be consistent?
>
> I've actually removed most of the doX with X in most of the code but left
> the doX's for compatibility. Wasn't sure what the do's provided.
>
'do' is more bean-like.
-jon
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: updates to the 3.0 source tree
Posted by Jason van Zyl <jv...@zenplex.com>.
On 11/12/01 12:23 PM, "Jon Stevens" <jo...@latchkey.com> wrote:
> on 11/12/01 9:03 AM, "Jason van Zyl" <jv...@zenplex.com> wrote:
>
>> What about render()?
>>
>
> Can we change that to doRender() to be consistent?
I've actually removed most of the doX with X in most of the code but left
the doX's for compatibility. Wasn't sure what the do's provided.
> -jon
>
>
> --
> 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>
Re: updates to the 3.0 source tree
Posted by Jon Stevens <jo...@latchkey.com>.
on 11/12/01 9:03 AM, "Jason van Zyl" <jv...@zenplex.com> wrote:
> What about render()?
>
Can we change that to doRender() to be consistent?
-jon
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: updates to the 3.0 source tree
Posted by Jason van Zyl <jv...@zenplex.com>.
On 11/12/01 11:46 AM, "Mike Haberman" <mi...@ncsa.uiuc.edu> wrote:
>
> Hello All,
>
> Unfortunately, I've been doing non turbine stuff here for a few months..
> So I haven't been very active. But I have 3 sites that are using
> turbine-3 code since Aug/Sept. (before fulcrum was separated) that have
> been running beautifully. I want to build both using the latest
> in cvs, but would like to integrate my patches into the 3.0 source:
>
> 1. I created a Runner object whose responsibility is just to
> run the module (and removed this from the Renderer). The
> Renderer only renders the template/target. The Runner, runs the
> module. Also, if the target changes after the run, it is run
> again (and so ad infinitum).
I'd like to see this particular patch first. I'm not sure I see the point of
the Runner when the module can execute itself.
> 2. Incorporated the above in ClassicPipeline.
>
> The above, actually speeds up the classic pipeline a bit.
>
> 3. can we make Resolver an interface:
>
> String getTemplate(moduleType, target)
> Module getModule(moduleType, target)
What about render()?
> Then
>
> 1. ModuleLoader can use the Resolver
> 2. I can plug in my own Resolver. (I use a different
> search algorithm then the default).
I'm all for pluggable resolvers.
> The current Resolver implementation can be the DefaultResolver.
>
> 4. Also, for those of us using velocity is there any advantage
> to using render.render(.....) in the templates over #parse(...) ?
> (Since renderer no longer runs a module, #parse has been working
> fine for me)
>
> 5. With the way the Runner and the Renderer now work, we can
> actually put $screen_placeholder back in the context as we
> do in 2.1. I know some didn't want to waste the extra
> memory required to this, but the first thing I need to do
> in my template is "$body = $renderer.render(...)" anyway.
> Just a thought to keep things easier for the migration.
>
> I know jason has 3.0 code yet to commit that affects the pipeline, but
> I would help me out a great deal if I can go ahead and commit the
> small changes. I think others (that use the 3.0 code) can benefit
> from it as well.
Please post the patches first. I'm in the middle of trying to get Torque and
Fulcrum out the door and than I will go back to Turbine. I'm not in Turbine
3.x headspace at the moment as I feel the decouple portions of Turbine need
some attention first so that people can start using them ASAP.
> Thanks, hope all is well. Sorry I haven't been able to
> contribute much. I like the changes and direction of
> both torque and fulcrum. Keep up the great work.
>
>
> mike
>
> --
> 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>