You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@velocity.apache.org by dave <da...@miceda-data.com> on 2000/08/28 03:55:21 UTC
Cloning templates
I'm looking at ways to eliminate any context clashes etc. with caching
templates.
What do you guys think about cloning copies of pre-parsed
templates from the cache? That way the cached version is never really
altered? Also remove the reference to the context from within the template
and pass it through on parse: template.parse( context )
--
dave
daveb@miceda-data.com
----------------------
Re: Cloning templates
Posted by "Daniel L. Rall" <dl...@finemaltcoding.com>.
dave wrote:
>
> I'm looking at ways to eliminate any context clashes etc. with caching
> templates.
>
> What do you guys think about cloning copies of pre-parsed
> templates from the cache? That way the cached version is never really
> altered? Also remove the reference to the context from within the template
> and pass it through on parse: template.parse( context )
Can the compiled templates should be read-only? This
would--hopefully--eliminate the need for cloning. When dynamic data is
inserted, a filled-in template could be generated.
--
Daniel Rall <dl...@finemaltcoding.com>
Re: Cloning templates
Posted by "Daniel L. Rall" <dl...@finemaltcoding.com>.
Jason van Zyl wrote:
>
> On Mon, 28 Aug 2000, Daniel L. Rall wrote:
> > > I'm just a little hazy on why different types or necessary (sorry)...
>
> I'm working on a design document now. The visitors that are used
> right now are general, any visitor that implements the ParserVisitor
> (which is auto generated by JavaCC) can walk the tree. This
> can definitely be optimized, but for now while we might be
> changing some of the grammar and therefore affect some of
> node types being generated it is best to stick with what
> is generated. When we get close to deciding on what the final
> syntax will look like then we can decide on an optimized
> visitor that removes some of the flexibility in favour
> of speed. I will attempt to explain all of this in
> detail in the Design doc.
Sounds great Jason, thanks!
--
Daniel Rall <dl...@finemaltcoding.com>
Re: WebMacro Methods
Posted by Jon Stevens <jo...@latchkey.com>.
on 8/28/2000 10:51 AM, "Jason van Zyl" <jv...@periapt.com> wrote:
> so I would just like
> to use the WM method stuff right now so we can get
> some compatibility going.
+1
-jon
--
http://scarab.tigris.org/ | http://noodle.tigris.org/
http://java.apache.org/ | http://java.apache.org/turbine/
http://www.working-dogs.com/ | http://jakarta.apache.org/velocity/
http://www.collab.net/ | http://www.sourcexchange.com/
Re: WebMacro Methods
Posted by "Daniel L. Rall" <dl...@finemaltcoding.com>.
bob wrote:
>
> Yah, WM handles that Just Fine. Things of the form
>
> $foo.bar($arg)
>
> should be handled by the parser rule, and won't need extra
> interpretation.
>
> $foo.bar("$arg is nice")
>
> will need an additional round on interpretation on the String,
> since the parser/lexer should be treating quoting strings as
> fairly opaque when used as an argument to a function.
>
> Also, WM can, I think, do magic with
>
> $foo.ByFirstName.bob
>
> turning it into
>
> foo.getByFirstName("bob")
>
> Another wacky thing iSpock can do
>
> $foo.($use.this).bar
>
> It'll resolve the parenthetical portion, and use the result
> in the actual walking of the objects, maybe resulting in
>
> $foo.goober.bar
I'd really like to limit the number of wacky things that the parser
can/will do. Let's attempt to provide only one way to do things--this
will greatly simplify the life of the template developer, and thus
simplify our lives as well (less ways to screw up, less internal tech
support and debugging questions).
--
Daniel Rall <dl...@finemaltcoding.com>
Re: WebMacro Methods
Posted by Jon Stevens <jo...@latchkey.com>.
on 8/28/2000 11:14 AM, "bob" <bo...@accurev.com> wrote:
> $foo.($use.this).bar
>
> It'll resolve the parenthetical portion, and use the result
> in the actual walking of the objects, maybe resulting in
>
> $foo.goober.bar
very cool. dynamic method invocation. :-) although this is a bit scary as it
isn't web designer friendly at all. they aren't going to understand what
this does at all.
-jon
--
http://scarab.tigris.org/ | http://noodle.tigris.org/
http://java.apache.org/ | http://java.apache.org/turbine/
http://www.working-dogs.com/ | http://jakarta.apache.org/velocity/
http://www.collab.net/ | http://www.sourcexchange.com/
Re: WebMacro Methods
Posted by bob <bo...@accurev.com>.
Yah, WM handles that Just Fine. Things of the form
$foo.bar($arg)
should be handled by the parser rule, and won't need extra
interpretation.
$foo.bar("$arg is nice")
will need an additional round on interpretation on the String,
since the parser/lexer should be treating quoting strings as
fairly opaque when used as an argument to a function.
Also, WM can, I think, do magic with
$foo.ByFirstName.bob
turning it into
foo.getByFirstName("bob")
Another wacky thing iSpock can do
$foo.($use.this).bar
It'll resolve the parenthetical portion, and use the result
in the actual walking of the objects, maybe resulting in
$foo.goober.bar
> Let me explain a bit further. Velocity can
> actually parse anything like this:
>
> $object.getThis("this", $that, $foo.Bar, $foo.getBar($voo.Doo("to", $you,
> $too))
>
> But right now I grab it as entire token. And Velocity can't
> really do much with it right now because of that fact. I didn't
> want to write a little parser to deal with because all the
> parameters to the methods should end up as nodes that
> I can recursively evaluate so any arbitrary nesting will
> work. I've had problems doing this, so I would just like
> to use the WM method stuff right now so we can get
> some compatibility going.
Re: WebMacro Methods
Posted by Jason van Zyl <jv...@periapt.com>.
Hi,
Let me explain a bit further. Velocity can
actually parse anything like this:
$object.getThis("this", $that, $foo.Bar, $foo.getBar($voo.Doo("to", $you,
$too))
But right now I grab it as entire token. And Velocity can't
really do much with it right now because of that fact. I didn't
want to write a little parser to deal with because all the
parameters to the methods should end up as nodes that
I can recursively evaluate so any arbitrary nesting will
work. I've had problems doing this, so I would just like
to use the WM method stuff right now so we can get
some compatibility going.
jvz.
On Mon, 28 Aug 2000, Jason van Zyl wrote:
> Hey,
>
> I was just looking through the WM code. Can someone
> tell me if this is the case? Can WM only do methods
> of the following form:
>
> $order.getCustomer("Fred").getName().Last
>
> Where methods can only have single parameters?
>
> Can you do something like:
>
> $order.getThis("param1", $param2, $foo.Order, $bar.get("this", "that",
> $theOther))
>
> Can WM handle methods themselves as parameters, and can
> the methods have multiple parameters.
>
> Recursively parsing methods is something I started adding
> to Velocity, but was having problems with the grammar.
> That's what I would like eventually, but for now I
> would like to take the method evaluation code out
> of WM, until I implement recursive method parsing.
>
> It doesn't look like WM implements it. As far as
> web design the use of nest methods would be rare,
> if at all. But as a general utility used by programmers
> it would probably be useful.
>
> Justin, are you there? I would really like your ok
> before I use your WM code as a matter of courtesy.
> And I would like to put you on the contributors'
> list as well.
>
> jvz.
>
>
--
Jason van Zyl
jvanzyl@periapt.com
WebMacro Methods
Posted by Jason van Zyl <jv...@periapt.com>.
Hey,
I was just looking through the WM code. Can someone
tell me if this is the case? Can WM only do methods
of the following form:
$order.getCustomer("Fred").getName().Last
Where methods can only have single parameters?
Can you do something like:
$order.getThis("param1", $param2, $foo.Order, $bar.get("this", "that",
$theOther))
Can WM handle methods themselves as parameters, and can
the methods have multiple parameters.
Recursively parsing methods is something I started adding
to Velocity, but was having problems with the grammar.
That's what I would like eventually, but for now I
would like to take the method evaluation code out
of WM, until I implement recursive method parsing.
It doesn't look like WM implements it. As far as
web design the use of nest methods would be rare,
if at all. But as a general utility used by programmers
it would probably be useful.
Justin, are you there? I would really like your ok
before I use your WM code as a matter of courtesy.
And I would like to put you on the contributors'
list as well.
jvz.
--
Jason van Zyl
jvanzyl@periapt.com
Re: Cloning templates
Posted by Jason van Zyl <jv...@periapt.com>.
On Mon, 28 Aug 2000, Daniel L. Rall wrote:
> bob wrote:
> > [snip some good stuff]
> > The parser could continue to produce the AST it's creating
> > now, for random walkers to walk, but I think a special-case
> > of a self-walking ProcessableTree might also be beneficial.
> >
> > I'll stop rambling now.
>
> Could someone explain when/why each type of tree/walker combo should be
> used? I see how the self-walking tree saves a level of indirection,
> which is extremely important when using a templating system for web apps
> (the template system implementation becomes inner-loop code). I'm just
> a little hazy on why different types or necessary (sorry)...
I'm working on a design document now. The visitors that are used
right now are general, any visitor that implements the ParserVisitor
(which is auto generated by JavaCC) can walk the tree. This
can definitely be optimized, but for now while we might be
changing some of the grammar and therefore affect some of
node types being generated it is best to stick with what
is generated. When we get close to deciding on what the final
syntax will look like then we can decide on an optimized
visitor that removes some of the flexibility in favour
of speed. I will attempt to explain all of this in
detail in the Design doc.
jvz.
--
Jason van Zyl
jvanzyl@periapt.com
Re: Cloning templates
Posted by "Daniel L. Rall" <dl...@finemaltcoding.com>.
bob wrote:
> [snip some good stuff]
> The parser could continue to produce the AST it's creating
> now, for random walkers to walk, but I think a special-case
> of a self-walking ProcessableTree might also be beneficial.
>
> I'll stop rambling now.
Could someone explain when/why each type of tree/walker combo should be
used? I see how the self-walking tree saves a level of indirection,
which is extremely important when using a templating system for web apps
(the template system implementation becomes inner-loop code). I'm just
a little hazy on why different types or necessary (sorry)...
--
Daniel Rall <dl...@finemaltcoding.com>
Re: Cloning templates
Posted by Jon Stevens <jo...@latchkey.com>.
on 8/27/2000 8:33 PM, "dave" <da...@miceda-data.com> wrote:
> I'll have to digest this a little.
>
> Jason, Jon, anyone... any thoughts on this ?
For some reason, my mind has a really hard time grasping parser concepts and
implementations.
I trust bob though. He knows what he is doing. Bob, my only comment is that
if you would like to make these changes, contribute code. :-) I also want to
hear what Jason has to say.
-jon
--
http://scarab.tigris.org/ | http://noodle.tigris.org/
http://java.apache.org/ | http://java.apache.org/turbine/
http://www.working-dogs.com/ | http://jakarta.apache.org/velocity/
http://www.collab.net/ | http://www.sourcexchange.com/
Re: Cloning templates
Posted by dave <da...@miceda-data.com>.
On Sun, 27 Aug 2000, you wrote:
> The parser could continue to produce the AST it's creating
> now, for random walkers to walk, but I think a special-case
> of a self-walking ProcessableTree might also be beneficial.
>
> I'll stop rambling now.
I'll have to digest this a little.
Jason, Jon, anyone... any thoughts on this ?
--
dave
daveb@miceda-data.com
----------------------
Re: Cloning templates
Posted by bob <bo...@accurev.com>.
Just had an out-of-band chat with dave regarding the
Visitor pattern usage, and Templates/Visitors holding
state.
I know the Visitor pattern allows for extensibility,
but it also adds another level of indirection. It's
to allow mulitple divergent things to walk the same
AST, possibly performing different actions (Processing
the template, pretty-printing the template, or whatnot.)
I'm thinking, possibly, to enhance performance, instead
of having a single type of tree, which can be walked by
many walkers, instead have the parser generate different
types of trees as needed.
Parse the template, and create a ProcessableTree, which
accepts a context, an output sink, and can walk itself
directly.
Or, have the Parser generate some other type of Tree,
which knows how to walk itself for whatever else you
need to do, taking whatever state it needs to do its
job.
I like the Visitor pattern, I do, but it does have it's
drawbacks. (The extra method calls, for example, which add
up over a large tree. And remember, each variable reference
generates a node in the tree, which results in 2 method calls
before even getting to the meat of the action to be performed
for that node.)
The parser could continue to produce the AST it's creating
now, for random walkers to walk, but I think a special-case
of a self-walking ProcessableTree might also be beneficial.
I'll stop rambling now.
-bob
Re: Cloning templates
Posted by dave <da...@miceda-data.com>.
On Sun, 27 Aug 2000, you wrote:
> Yes, you're making sense. I solved it by simply passing the context
> to the tree as an argument. Template doesn't need the context except
> to do the actual outputting. So, just kinda drop the context (and your
> output sink) down the tree. This is what iSpock does, to eliminate
> just this problem.
Thanks.
--
dave
daveb@miceda-data.com
----------------------
Re: Cloning templates
Posted by Jason van Zyl <jv...@periapt.com>.
On Sun, 27 Aug 2000, bob wrote:
>
> Yes, you're making sense. I solved it by simply passing the context
> to the tree as an argument. Template doesn't need the context except
> to do the actual outputting. So, just kinda drop the context (and your
> output sink) down the tree. This is what iSpock does, to eliminate
> just this problem.
>
> -bob
+1
I'm the first to admit the context needs work!
jvz.
> On Sun, 27 Aug 2000, dave wrote:
>
> > On Sun, 27 Aug 2000, you wrote:
> > > on 8/27/2000 6:55 PM, "dave" <da...@miceda-data.com> wrote:
> > >
> > > > I'm looking at ways to eliminate any context clashes etc. with caching
> > > > templates.
> > > >
> > > > What do you guys think about cloning copies of pre-parsed
> > > > templates from the cache? That way the cached version is never really
> > > > altered? Also remove the reference to the context from within the template
> > > > and pass it through on parse: template.parse( context )
> > > >
> > >
> > > I don't totally get what you are saying.
> >
> > 2 threads are using the same template from the cache at the same time.
> > Couldn't this cause a problem? What I'm saying is to clone ( or make a
> > shallow copy ) of the template with any dynamic fields nulled out and hand
> > that to the requesting thread. At the same time remove the reference to
> > context from the template and just pass it through at parse when it's
> > needed.
> >
> > Am I making sense? Or do I need a break? :-)
> >
> > --
> > dave
> > daveb@miceda-data.com
> > ----------------------
> >
>
>
>
--
Jason van Zyl
jvanzyl@periapt.com
Re: Cloning templates
Posted by Jon Stevens <jo...@latchkey.com>.
on 8/27/2000 7:27 PM, "bob" <bo...@accurev.com> wrote:
> Yes, you're making sense. I solved it by simply passing the context
> to the tree as an argument. Template doesn't need the context except
> to do the actual outputting. So, just kinda drop the context (and your
> output sink) down the tree. This is what iSpock does, to eliminate
> just this problem.
>
> -bob
+1
-jon
--
Scarab -
Java Servlet Based - Open Source
Bug/Issue Tracking System
<http://scarab.tigris.org/>
Re: Cloning templates
Posted by bob <bo...@accurev.com>.
Yes, you're making sense. I solved it by simply passing the context
to the tree as an argument. Template doesn't need the context except
to do the actual outputting. So, just kinda drop the context (and your
output sink) down the tree. This is what iSpock does, to eliminate
just this problem.
-bob
On Sun, 27 Aug 2000, dave wrote:
> On Sun, 27 Aug 2000, you wrote:
> > on 8/27/2000 6:55 PM, "dave" <da...@miceda-data.com> wrote:
> >
> > > I'm looking at ways to eliminate any context clashes etc. with caching
> > > templates.
> > >
> > > What do you guys think about cloning copies of pre-parsed
> > > templates from the cache? That way the cached version is never really
> > > altered? Also remove the reference to the context from within the template
> > > and pass it through on parse: template.parse( context )
> > >
> >
> > I don't totally get what you are saying.
>
> 2 threads are using the same template from the cache at the same time.
> Couldn't this cause a problem? What I'm saying is to clone ( or make a
> shallow copy ) of the template with any dynamic fields nulled out and hand
> that to the requesting thread. At the same time remove the reference to
> context from the template and just pass it through at parse when it's
> needed.
>
> Am I making sense? Or do I need a break? :-)
>
> --
> dave
> daveb@miceda-data.com
> ----------------------
>
Re: Cloning templates
Posted by dave <da...@miceda-data.com>.
On Sun, 27 Aug 2000, you wrote:
> on 8/27/2000 6:55 PM, "dave" <da...@miceda-data.com> wrote:
>
> > I'm looking at ways to eliminate any context clashes etc. with caching
> > templates.
> >
> > What do you guys think about cloning copies of pre-parsed
> > templates from the cache? That way the cached version is never really
> > altered? Also remove the reference to the context from within the template
> > and pass it through on parse: template.parse( context )
> >
>
> I don't totally get what you are saying.
2 threads are using the same template from the cache at the same time.
Couldn't this cause a problem? What I'm saying is to clone ( or make a
shallow copy ) of the template with any dynamic fields nulled out and hand
that to the requesting thread. At the same time remove the reference to
context from the template and just pass it through at parse when it's
needed.
Am I making sense? Or do I need a break? :-)
--
dave
daveb@miceda-data.com
----------------------
Re: Cloning templates
Posted by Jon Stevens <jo...@latchkey.com>.
on 8/27/2000 6:55 PM, "dave" <da...@miceda-data.com> wrote:
> I'm looking at ways to eliminate any context clashes etc. with caching
> templates.
>
> What do you guys think about cloning copies of pre-parsed
> templates from the cache? That way the cached version is never really
> altered? Also remove the reference to the context from within the template
> and pass it through on parse: template.parse( context )
>
I don't totally get what you are saying.
-jon
--
Scarab -
Java Servlet Based - Open Source
Bug/Issue Tracking System
<http://scarab.tigris.org/>