You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@velocity.apache.org by Thomas Åhlen <th...@obidobi.net> on 2001/12/07 08:32:47 UTC
pluggable grammar.
Some weeks ago I asked if it was possible to make the grammar pluggable.
Didn't get any answer? Is it hard to implement?
If the problem is that nobody has time to implement it I might take a shoot
at it, since I really need that funtionallity. I have to build my pages with
multiple parsings and there is no other way to do it. Today I use mutliple \
before my directives for them not to be removed durring the previous parse.
But I need another solution since that is not managable way of doing things.
The way I see it the best solution is to use 2 diffrerent grammars. I could
use some other parser than velocity for the first parse but I really would
like to use Velocity only.
If you are wondering what I am doing. I am making a complete framework for
building Servlet only applications. When it gets a bit more mature I will
open source it :).
Thomas
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: pluggable grammar.
Posted by Christoph Reck <Ch...@dlr.de>.
I like Ewan's solution the best. It avoids the necessity of counting
escapes, and makes things clear that these are intended for a 2nd
pass. Note that this could be driven even further with ${pass2},
${pass3}, ... but IMHO more than two passes would be a *real*
strange application.
:) Christoph
Ewan Makepeace wrote:
>
> Could you not put the second parse characters into variables to get
> substituted on the first pass?
>
> Something like:
> {$hash}if( $a ==1 )
> #foreach( $b in $vector )
> this is a $b
> #end
> {$hash}else
> nothing
> {$hash}end
>
> Which parses once to:
>
> #if ( $a ==1 )
> this is a cat
> this is a dog
> #else
> nothing
> #end
>
> Still not what you wanted but significantly more readable than \\\\ or Geirs
> recursive system?
> rgds
> Ewan
>
> -----Original Message-----
> From: Geir Magnusson Jr. [mailto:geirm@optonline.net]
> Sent: Saturday, December 08, 2001 4:03 AM
> To: velocity-user@jakarta.apache.org
> Subject: Re: pluggable grammar.
>
> On 12/7/01 3:54 PM, "Thomas Åhlen" <th...@obidobi.net> wrote:
>
> >> #blargh( 2 )
> >> #if( $a == 0 )
> >> #foreach( $b in $vector )
> >> $b != $a
> >> #end
> >> #else
> >> 1
> >> #end
> >> #end
> >
> > Yes that is much better. But there are instances where you have nested
> > directives.
> > This is how my template can look today:
> >
> > \\#If( $a == 1)
> > #foreach( $b in $vector )
> > this is a $b
> > #end
> > \\#else
> > nothing
> > \\#end
> >
> > where the foreach is done in parse 1 and the #if is evaluated in parse 2.
> > I don't see how #blargh( 2 ) could solv that one.
> >
>
> That's true - it just means you cook up a line directive like I first
> suggested :
>
> #pthub( 2 '#if( $a == 1 )' )
> #foreach...
> ...
> #end
> #pthub( 2 '#else' )
> #pthub( 2 ' nothing' )
> #pthub( 2 '#end' )
>
> I dunno. That might be a pain.
>
> What a wacky problem you have :)
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: pluggable grammar.
Posted by Jason van Zyl <jv...@zenplex.com>.
On 12/7/01 7:48 AM, "Thomas Åhlen" <th...@obidobi.net> wrote:
>> My honest view is that it's not hard to implement a pluggable grammar per
> se
>> - however I don't think that Velocity as a project wants to offer
>> alternative grammars (too confusing to users) and that writing a grammer to
>> work with our 'core' would be difficult. I say this because our grammar is
>> so utterly wacky, allowing the syntax to be interspersed in what is
>> effectively random garbage, the template contents :)
>
> I am only thinking of changing the visual apperance not any functionallity.
No way. That would be a nightmare trying to maintain and Velocity has a
known 'look' now. And though I sometimes get criticized for this view,
myriad flexibility at all levels is not a good thing.
In your situation where you need all these grammars have you really asked
yourself why? And if it's really a boon to the people using it to have to
deal with all these variations.
Not to mention that it would make the processing of nodes even crazier than
it already is. It would make the core grammar even harder to read and the
structure of any of the nodes that 'manually' pull tokens and nodes out for
processing would become nuts.
> The ultimate solution would ofcourse be to make a more generic grammar which
> can be configured. For example directive and variable delimitors could be
> changed.
>
> #foreach( $a in $vector )
> $a
> #end
>
> could be written as when changing directive delimitors
>
> [%foreach( $a in $vector )%]
> $a
> [%end%]
I see zero advantage to this, plus as Geir mentioned it would be seriously
confusing.
> <!--foreach( $a in $vector )-->
> $a
> <!--end-->
>
> when initzializing velocity I could decide which delimitors to use( I know
> template engines which created a directive so that the delimitors could be
> change during a parse, but that might be to over do it ) . I don't think
> this will confuse users since it is up to the use to deside which kind of
> delimiters to use and the default directive delimitors is ofcourse
> "#,<space>".
Yes, it would be confusing to users because all our documentation refers to
the grammar that we already have. You give them one grammar and they know
that it's velocity and than they come to the website and see something
completely different?
--
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: pluggable grammar.
Posted by Thomas Åhlen <th...@obidobi.net>.
>My honest view is that it's not hard to implement a pluggable grammar per
se
>- however I don't think that Velocity as a project wants to offer
>alternative grammars (too confusing to users) and that writing a grammer to
>work with our 'core' would be difficult. I say this because our grammar is
>so utterly wacky, allowing the syntax to be interspersed in what is
>effectively random garbage, the template contents :)
I am only thinking of changing the visual apperance not any functionallity.
The ultimate solution would ofcourse be to make a more generic grammar which
can be configured. For example directive and variable delimitors could be
changed.
#foreach( $a in $vector )
$a
#end
could be written as when changing directive delimitors
[%foreach( $a in $vector )%]
$a
[%end%]
<!--foreach( $a in $vector )-->
$a
<!--end-->
when initzializing velocity I could decide which delimitors to use( I know
template engines which created a directive so that the delimitors could be
change during a parse, but that might be to over do it ) . I don't think
this will confuse users since it is up to the use to deside which kind of
delimiters to use and the default directive delimitors is ofcourse
"#,<space>".
By having the ability to use several delimitors in the same template I can
parse the templates several times without problems. I only have to use one
kind of delimitors for each parse.
>Is it possible to boil down the problem into something really simple and
>show us? There are some might clever people lurking around here, and they
>might be able to suggest something you haven't thought of.
Well it's not a problem is just a way of doing things :).
The first parse:
I add static content. Image names and url's depending on style. Words and
sentances of text depending on language. Also take a bunch of
templates(components) merge them into one final template. The result I call
a RuntimeTemplate. This parse can be done once and only needs to be redone
when some template component or languageBundle have been changed.
Second parse:
The runtime template is fetched by the servlet application, rendered and
sent to the client. This parse add the dynamic content that are produced by
the user interaction.
Why do I do this: I get quicker response times since most of the work done
by velocity on my templates are already done in advance. Almost all
#includes #parse directives was executed in the first parse.
Thomas
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: pluggable grammar.
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
On 12/7/01 2:32 AM, "Thomas Åhlen" <th...@obidobi.net> wrote:
> Some weeks ago I asked if it was possible to make the grammar pluggable.
> Didn't get any answer? Is it hard to implement?
My honest view is that it's not hard to implement a pluggable grammar per se
- however I don't think that Velocity as a project wants to offer
alternative grammars (too confusing to users) and that writing a grammer to
work with our 'core' would be difficult. I say this because our grammar is
so utterly wacky, allowing the syntax to be interspersed in what is
effectively random garbage, the template contents :)
>
> If the problem is that nobody has time to implement it I might take a shoot
> at it, since I really need that funtionallity. I have to build my pages with
> multiple parsings and there is no other way to do it. Today I use mutliple \
> before my directives for them not to be removed durring the previous parse.
> But I need another solution since that is not managable way of doing things.
> The way I see it the best solution is to use 2 diffrerent grammars. I could
> use some other parser than velocity for the first parse but I really would
> like to use Velocity only.
Is it possible to boil down the problem into something really simple and
show us? There are some might clever people lurking around here, and they
might be able to suggest something you haven't thought of.
> If you are wondering what I am doing. I am making a complete framework for
> building Servlet only applications. When it gets a bit more mature I will
> open source it :).
:)
--
Geir Magnusson Jr. geirm@optonline.net
System and Software Consulting
Be a giant. Take giant steps. Do giant things...
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: pluggable grammar.
Posted by Jason van Zyl <jv...@zenplex.com>.
On 12/7/01 2:32 AM, "Thomas Åhlen" <th...@obidobi.net> wrote:
> Some weeks ago I asked if it was possible to make the grammar pluggable.
> Didn't get any answer? Is it hard to implement?
The first versions of velocity had a couple grammars. I actually tried to
have a WebMacro grammar and a Velocity grammar and they both actually worked
together but it was a severe pain in the ass. It's not as easy to maintain
as you might think.
And really in the end I don't think we need more than one grammar. Although
a pluggable parser might be interesting to try things out like Antlr or
SableCC but at this point all of velocity is tied to the objects that are
produced by a JavaCC grammar. So I say interesting but probably not of much
use at this point.
> If the problem is that nobody has time to implement it I might take a shoot
> at it, since I really need that funtionallity.
I not in favour of another grammar. Velocity has a BNF and I think it should
remain that way.
> I have to build my pages with
> multiple parsings and there is no other way to do it. Today I use mutliple \
> before my directives for them not to be removed durring the previous parse.
> But I need another solution since that is not managable way of doing things.
> The way I see it the best solution is to use 2 diffrerent grammars. I could
> use some other parser than velocity for the first parse but I really would
> like to use Velocity only.
>
> If you are wondering what I am doing. I am making a complete framework for
> building Servlet only applications. When it gets a bit more mature I will
> open source it :).
>
> Thomas
>
>
> --
> 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>