NVelocity parser
Stuart Carnie
I really dislike the parser implementation. I'm not pointing any
fingers or criticizing as I know this is a conversion of the Java
parser. I'm stating the obvious, but throwing exceptions is horrible,
and horribly inefficient.
I was debugging a template today, and over 8000 exceptions were thrown
in the NVelocity parser. I've dug in to the code, and the only
'right' way to resolve this is a new parser.
I would like to contribute to NVelocity and rewrite the parser using
the Gardens Point Language tools (open source parser generator).
http://plas.fit.qut.edu.au/projects/LanguageProcessingTools.aspx
I would also like to look into lightweight code generation (LCG), so
that the templates are run as native code.
I don't have a great deal of time right now, but if there is interest
in this, I'd be willing to undertake it.
Perfect time to change this to Castle.Velocity...
Cheers,
Stu
Hamilton Verissimo
out of curiosity, why not going with antlr?
--
Cheers,
hamilton verissimo
ham...@castlestronghold.com
http://www.castlestronghold.com/
Stuart Carnie
written from the ground for .NET. It appears to be very lightweight -
it uses generics for the generated lexer/parser. A key goal for me is
efficiency.
Not that it matters to me, but it was designed for the Ruby.NET
project and Microsoft also use in the Visual Studio SDK.
I'll revisit antlr (3.0 specifically) before the undertaking, but I'm
leaning towards GP for now.
Cheers,
Stu
On May 11, 1:03 pm, "Hamilton Verissimo"
<hamm...@castlestronghold.com> wrote:
> Interesting, but you're not the only way heading towards that. Just
> out of curiosity, why not going with antlr?
>
> On 5/11/07, Stuart Carnie <stuart.car...@gmail.com> wrote:
>
>
>
>
>
> > I really like NVelocity.
>
> > I really dislike the parser implementation. I'm not pointing any
> > fingers or criticizing as I know this is a conversion of the Java
> > parser. I'm stating the obvious, but throwing exceptions is horrible,
> > and horribly inefficient.
>
> > I was debugging a template today, and over 8000 exceptions were thrown
> > in the NVelocity parser. I've dug in to the code, and the only
> > 'right' way to resolve this is a new parser.
>
> > I would like to contribute to NVelocity and rewrite the parser using
> > the Gardens Point Language tools (open source parser generator).
> >http://plas.fit.qut.edu.au/projects/LanguageProcessingTools.aspx
>
> > I would also like to look into lightweight code generation (LCG), so
> > that the templates are run as native code.
>
> > I don't have a great deal of time right now, but if there is interest
> > in this, I'd be willing to undertake it.
>
> > Perfect time to change this to Castle.Velocity...
>
> > Cheers,
>
> > Stu
>
> --
> Cheers,
> hamilton verissimo
> hamm...@castlestronghold.comhttp://www.castlestronghold.com/
Tim Haines
Did you see the messages from Jonathan Rossi? He's writing a VS colorization tool for NVelocity, and started talking about writing a parser/compiler next. Perhaps it's worth having a chat with him, and the two of you might find a good way to share the load with it if you're interested...
Tim.
Stuart Carnie
Cheers,
Stu
On May 11, 1:53 pm, "Tim Haines" <tmhai...@gmail.com> wrote:
> Hi Stu,
>
> Did you see the messages from Jonathan Rossi? He's writing a VS
> colorization tool for NVelocity, and started talking about writing a
> parser/compiler next. Perhaps it's worth having a chat with him, and the
> two of you might find a good way to share the load with it if you're
> interested...
>
> Tim.
>
Kunle Odutola
Some questions/comments...
Disclaimer: I contribute to ANTLR/C#.
> I've played around with both; however, a significant factor
> is GP was written from the ground for .NET.
What do you means by this?. Why is it important?.
I think the ability to target multiple platforms/environments/languages is a
strength of those tools that support it. With ANTLR for instance, a C#
parser could be replaced with a C implementation (or C++ in the future)
fairly easily if your application demands that kind of bare-metal
performance.
To be fair, GPPG is basically Yacc with C# 2.0 generation. Shouldn't be too
hard to convert the specification file to some other Yacc-style tool.
> It appears to be
> very lightweight - it uses generics for the generated
> lexer/parser. A key goal for me is efficiency.
Once again, what do you mean by "very lightweight"?. Why is that a good
thing?. I'd like to know as it might be useful for ANTLR/C#.
One consequence of the use of Generics is lack of support for the various C#
1.x-on-CLI v1.x implementations (i.e. .NET 1.x & Mono 1.x). That might suit
Castle but might be inappropriate for a template engine like NVelocity.
Likewise, a C# 2.0 target for ANTLR v3 is doable (and partially exists) but,
C# 1.x support is very important for ANTLR/C#.
On efficiency: GPPG generates table-driven shift-reduce parsers in the
Yacc/Bison/CUP/C#Cup tradition. They are generally efficient but, are much
less amenable to post-generation optimization unlike recursive descent
parsers. Grammar development/debugging and, error handling/recovery
basically sucks compared to RD parsers.
> Not that it matters to me, but it was designed for the
> Ruby.NET project and Microsoft also use in the Visual Studio SDK.
MPlex/MPPG are indeed descended from GPLex/GPPG. Microsoft used Lex/Yacc in
previous VSIP SDKs (when it was C/C++ only ), and the Managed code interface
to their VSIP framework continues that tradition - but with C# output.
> I'll revisit antlr (3.0 specifically) before the undertaking,
> but I'm leaning towards GP for now.
You should. ANTLR v3 + AntlrWorks rocks.
One strength of the Yacc-style tools is that LR grammars require less
"refactoring" than LL grammars. The new LL* support in ANTLR v3 levels the
field considerably but, LR tools still have an edge there [ but no
AntlrWorks sadly ;-) ].
I think you should also revisit/consider using a JavaCC-with-C#-output tool.
It would better at tracking changes in the original Velocity grammar so the
langauges don't diverge too widely.
Ultimately though, I suspect you would like ANTLR v3 enough to want to use
it. Seriously. - AntlrWorks rocks!!. Further since ANTLR supports Java too,
the original Velocity project might be happy to switch from JavaCC if a fast
ANTLR v3 implementation popped up in a future NVelocity.
Kunle
Jonathon Rossi
You dislike the implementation just as much as me, I've build a hand written
scanner because there was no way for a generated scanner to tokenise XHTML
and NVelocity. I haven't yet made an option in the scanner so it won't
detect XHTML tags but it isn't hard.
One thing I have done that the Velocity guys haven't done (from what I can
see) is written a formal language grammar, it is for the XHTML and
NVelocity, however we could pull out the NVelocity and have a separate
document for the XHTML stuff that adds to the main NVelocity grammar.
You could use XHTML detection at the execution level if you wanted the
engine to automatically ident your XHTML tags and format it for you. Or you
could set an option to pack the XHTML as much as possible. Just an idea, not
sure if anyone is after this type of feature. There basically isn't any
performance disadvantage to this since the template will be compiled.
Interesting to know that the parser generated 8000 exceptions, from my
experience the parser stops processing once it hits the first error in your
template. However, I wouldn't be surprised because it is so hard to debug
and is without heaps of unit tests.
I am also considering using the GPPG for the parser for similar reasons and
because my supervisor for my final year university project wrote it.
However, I haven't decided if a hand written parser (recursive descent is
all that is needed since JavaCC generates these) would be more beneficial.
I have also been considering code generation because .NET is also much
better at managing memory and macro stack frames than us. Would you be
looking at generating IL or C#, I was looking at generating IL. One problem
I see straight away is that variables in NVelocity are not statically typed,
when we come to this I'm sure our good friend Ayende will have many problems
solved (if you don't know he build Brail).
This is our chance to finally add more language syntax like the Velocity
guys have been doing and even our own syntax. However, we will be able to
add more at any time because it will be maintainable.
Also so you know, my work is already in the Castle.NVelocity namespace.
PS. It might better to talk offlist so we don't fill up everyone's inbox.
Regards, Jonathon Rossi
Stuart Carnie
On May 11, 4:26 pm, "Kunle Odutola" <kunle.odut...@virgin.net> wrote:
> Hi,
>
> Some questions/comments...
>
> Disclaimer: I contribute to ANTLR/C#.
>
> > I've played around with both; however, a significant factor
> > is GP was written from the ground for .NET.
>
> What do you means by this?. Why is it important?.
Unless things have changed, I understood that the C# implementation
for antlr has dependencies on external assemblies (the C# antlr
assemblies). I didn't want to complicate things or use with tools
such as ILMerge, or include the reasonably large parser libraries. GP
doesn't require any external assemblies to run the parser. If this
has changed, great!
I figured I'd discover these changes when I took a look at antlr 3.0
>
> I think the ability to target multiple platforms/environments/languages is a
> strength of those tools that support it. With ANTLR for instance, a C#
> parser could be replaced with a C implementation (or C++ in the future)
> fairly easily if your application demands that kind of bare-metal
> performance.
>
> To be fair, GPPG is basically Yacc with C# 2.0 generation. Shouldn't be too
> hard to convert the specification file to some other Yacc-style tool.
>
This becomes difficult if the grammar definition contains a
significant amount of language specific code, such as C# or Java.
> > It appears to be
> > very lightweight - it uses generics for the generated
> > lexer/parser. A key goal for me is efficiency.
>
> Once again, what do you mean by "very lightweight"?. Why is that a good
> thing?. I'd like to know as it might be useful for ANTLR/C#.
>
Lightweight by only generating a couple of source files for the full
parser. Maintenance.
> One consequence of the use of Generics is lack of support for the various C#
> 1.x-on-CLI v1.x implementations (i.e. .NET 1.x & Mono 1.x). That might suit
> Castle but might be inappropriate for a template engine like NVelocity.
> Likewise, a C# 2.0 target for ANTLR v3 is doable (and partially exists) but,
> C# 1.x support is very important for ANTLR/C#.
>
> On efficiency: GPPG generates table-driven shift-reduce parsers in the
> Yacc/Bison/CUP/C#Cup tradition. They are generally efficient but, are much
> less amenable to post-generation optimization unlike recursive descent
> parsers. Grammar development/debugging and, error handling/recovery
> basically sucks compared to RD parsers.
>
> > Not that it matters to me, but it was designed for the
> > Ruby.NET project and Microsoft also use in the Visual Studio SDK.
>
> MPlex/MPPG are indeed descended from GPLex/GPPG. Microsoft used Lex/Yacc in
> previous VSIP SDKs (when it was C/C++ only ), and the Managed code interface
> to their VSIP framework continues that tradition - but with C# output.
>
> > I'll revisit antlr (3.0 specifically) before the undertaking,
> > but I'm leaning towards GP for now.
>
> You should. ANTLR v3 + AntlrWorks rocks.
I had seen this previously, and was very impressed by this. I have
used Gold Parser and Visual Parse ++ in previous projects. Visual
Parse ++ is a full IDE, and has a nice integrated debugger, which is
very useful.
Kunle Odutola
> > > I've played around with both; however, a significant factor is GP
> > > was written from the ground for .NET.
> >
> > What do you means by this?. Why is it important?.
>
> Unless things have changed, I understood that the C#
> implementation for antlr has dependencies on external
> assemblies (the C# antlr assemblies). I didn't want to
> complicate things or use with tools such as ILMerge, or
> include the reasonably large parser libraries. GP doesn't
> require any external assemblies to run the parser. If this
> has changed, great!
>
> I figured I'd discover these changes when I took a look at antlr 3.0
Gotcha!. I don't think that having a runtime library is an issue but...
ANTLR v3 has a smalll runtime library. That architecture - generated code +
runtime library - allows the generated code to be smaller and supports bases
features such as flexible error handling/recovery/reporting, basic
testability, AntlrWorks [remote] debugging etc for ANTLR.
GPPG similarly has a small runtime file - Shift-ReduceParser.dll.
> > To be fair, GPPG is basically Yacc with C# 2.0 generation.
> Shouldn't
> > be too hard to convert the specification file to some other
> Yacc-style
> > tool.
> >
>
> This becomes difficult if the grammar definition contains a
> significant amount of language specific code, such as C# or Java.
Yep. ANTLR v3's new Attribute & Dynamic scopes, tree rewrite operators etc
features reduces the need for native code in many instances.
> > > It appears to be
> > > very lightweight - it uses generics for the generated
> lexer/parser.
> > > A key goal for me is efficiency.
> >
> > Once again, what do you mean by "very lightweight"?. Why is that a
> > good thing?. I'd like to know as it might be useful for ANTLR/C#.
> >
>
> Lightweight by only generating a couple of source files for
> the full parser. Maintenance.
OK. ANTLR is the same.
> > > I'll revisit antlr (3.0 specifically) before the undertaking, but
> > > I'm leaning towards GP for now.
> >
> > You should. ANTLR v3 + AntlrWorks rocks.
>
> I had seen this previously, and was very impressed by this.
> I have used Gold Parser and Visual Parse ++ in previous
> projects. Visual Parse ++ is a full IDE, and has a nice
> integrated debugger, which is very useful.
Visual Parse++ was very cool. Never used GOLD parser (Miguel's Jay/C#, C#
CUP and now GPPG serve my LR-in-C# needs well enough).
I wonder, are there any OSS equivalents of Visual Parse++?
Kunle
Arnoud
> see) is written a formal language grammar, it is for the XHTML and
> NVelocity, however we could pull out the NVelocity and have a separate
> document for the XHTML stuff that adds to the main NVelocity grammar.
I think this qualifies:
http://svn.apache.org/viewvc/velocity/engine/trunk/src/parser/Parser.jjt?revision=525317&view=markup
Jonathon Rossi
a formal grammar using EBNF. There are also many cases where they use Java
code to process certain things.
Regards, Jonathon Rossi
> -----Original Message-----
> From: castle-pro...@googlegroups.com [mailto:castle-project-
> de...@googlegroups.com] On Behalf Of Arnoud
> Sent: Saturday, 12 May 2007 10:38 AM
> To: Castle Project Development List
> Subject: Re: NVelocity parser
>
>
Stuart Carnie
On May 11, 4:45 pm, "Jonathon Rossi" <j...@jonorossi.com> wrote:
> Hello Stuart,
>
> You dislike the implementation just as much as me, I've build a hand written
> scanner because there was no way for a generated scanner to tokenise XHTML
> and NVelocity. I haven't yet made an option in the scanner so it won't
> detect XHTML tags but it isn't hard.
>
> One thing I have done that the Velocity guys haven't done (from what I can
> see) is written a formal language grammar, it is for the XHTML and
> NVelocity, however we could pull out the NVelocity and have a separate
> document for the XHTML stuff that adds to the main NVelocity grammar.
>
I'd really like to see that!
> You could use XHTML detection at the execution level if you wanted the
> engine to automatically ident your XHTML tags and format it for you. Or you
> could set an option to pack the XHTML as much as possible. Just an idea, not
> sure if anyone is after this type of feature. There basically isn't any
> performance disadvantage to this since the template will be compiled.
>
> Interesting to know that the parser generated 8000 exceptions, from my
> experience the parser stops processing once it hits the first error in your
> template. However, I wouldn't be surprised because it is so hard to debug
> and is without heaps of unit tests.
>
I don't want to be too critical, but perhaps the original implementers
didn't understand the impact exceptions would have on performance or
didn't consider Velocity for a hi perf environment?
> I am also considering using the GPPG for the parser for similar reasons and
> because my supervisor for my final year university project wrote it.
> However, I haven't decided if a hand written parser (recursive descent is
> all that is needed since JavaCC generates these) would be more beneficial.
>
> I have also been considering code generation because .NET is also much
> better at managing memory and macro stack frames than us. Would you be
> looking at generating IL or C#, I was looking at generating IL. One problem
> I see straight away is that variables in NVelocity are not statically typed,
> when we come to this I'm sure our good friend Ayende will have many problems
> solved (if you don't know he build Brail).
>
Instead of us writing the IL generator or using C# code generation, we
should take a look at the the Dynamic Language Runtime (DLR) for our
'dynamic compilation' - as this scenario is what it is designed
for... You can get the code for Microsoft.Scripting from the
IronPython 2.0 release on Codeplex (http://codeplex.com/IronPython).
I took a gander at it, and get the impression it may be ideal.. We'd
still want an NVelocity interpreter, but having the option to generate
compiled templates would be a huge boost for NVelocity.
> This is our chance to finally add more language syntax like the Velocity
> guys have been doing and even our own syntax. However, we will be able to
> add more at any time because it will be maintainable.
>
> Also so you know, my work is already in the Castle.NVelocity namespace.
>
> PS. It might better to talk offlist so we don't fill up everyone's inbox.
Sure thing.
Kunle Odutola
> > I have also been considering code generation because .NET
> is also much
> > better at managing memory and macro stack frames than us.
> Would you be
> > looking at generating IL or C#, I was looking at generating IL. One
> > problem I see straight away is that variables in NVelocity are not
> > statically typed, when we come to this I'm sure our good
> friend Ayende
> > will have many problems solved (if you don't know he build Brail).
> >
>
> Instead of us writing the IL generator or using C# code
> generation, we should take a look at the the Dynamic Language
> Runtime (DLR) for our 'dynamic compilation' - as this
> scenario is what it is designed for... You can get the code
> for Microsoft.Scripting from the IronPython 2.0 release on
> Codeplex (http://codeplex.com/IronPython). I took a gander at
> it, and get the impression it may be ideal.. We'd still want
> an NVelocity interpreter, but having the option to generate
> compiled templates would be a huge boost for NVelocity.
Snap!. I was looking at whether that stuff fits in ST#'s future. Weird
synchronicity... ;-)
Still, NVelocity isn't obviously a dynamic language...
Kunle
Jonathon Rossi
What exception was it throwing? Were they being thrown because of a error by
you or just a normal flow of process?
I don't think that building an interpreter would be needed since both
WebForms and Brail compile when executed which we could easily do in with
the option of precompiling the templates for deployment.
The DLR might be a way to go however I can see using the code generator to
make typed property bags a good way to have everything all statically typed
so you can get compile time errors. However, others might want NVelocity to
go down the dynamic language road, that is why I am continuing discussion on
the list so others can chime in and let us know what there preference is.
Fábio Batista
> PS. It might better to talk offlist so we don't fill up everyone's inbox.
-1
Keep it going :)
--
Fábio David Batista
fabio.dav...@gmail.com
http://nerd-o-matic.blogspot.com
Tim Haines
Jonathon Rossi
Okay. As I mentioned before it might be better to keep it on the list because it allows everyone else to jump in and say what they think. For example, I would like to know if others would want NVelocity to become a dynamic language or because a fully statically typed language. Obviously there are advantages for each.
I have 2 separate folders (devel and users) in Outlook for the lists and rules to keep them out of my inbox. I’m sure our discussion will be pretty general, just trying to get some ideas and work out where we may be headed.
Regards, Jonathon Rossi
<br
craiggwilson
use IronPython or Brail or the new IronRuby. NVelocity is a template
language and I feel it should be left as such (although compilation
would be cool).
On May 11, 10:12 pm, "Jonathon Rossi" <j...@jonorossi.com> wrote:
> Okay. As I mentioned before it might be better to keep it on the list
> because it allows everyone else to jump in and say what they think. For
> example, I would like to know if others would want NVelocity to become a
> dynamic language or because a fully statically typed language. Obviously
> there are advantages for each.
>
> I have 2 separate folders (devel and users) in Outlook for the lists and
> rules to keep them out of my inbox. I'm sure our discussion will be pretty
> general, just trying to get some ideas and work out where we may be headed.
>
> Regards, Jonathon Rossi
>
> From: castle-pro...@googlegroups.com
> [mailto:castle-pro...@googlegroups.com] On Behalf Of Tim Haines
> Sent: Saturday, 12 May 2007 12:03 PM
> To: castle-pro...@googlegroups.com
> Subject: Re: NVelocity parser
>
> I agree. I'm finding it interesting to eavesdrop on, even though I don't
> expect I'll be contributing. Gmail's threaded conversations does a good job
> of not letting it take over the inbox. ;-)
>
> On 12/05/07, Fábio Batista <fabio.david.bati...@gmail.com> wrote:
>
> On 5/11/07, Jonathon Rossi <j...@jonorossi.com> wrote:
>
> > PS. It might better to talk offlist so we don't fill up everyone's inbox.
>
> -1
>
> Keep it going :)
>
> --
> Fábio David Batista
> fabio.david.bati...@gmail.comhttp://nerd-o-matic.blogspot.com
> <br
Hamilton Verissimo
If it's not a big harm, I'd like to see NVelocity going a step further
as a language. The lack of support for built in dictionaries, lack of
support for decimals and its horrible implementation have always been
a problem to us.
If we can fix those, cool. If we can't, well, we might need to come up
with a new template engine.
On 5/12/07, craiggwilson <craigg...@gmail.com> wrote:
>
> I think if someone needs a dynamic language for their views, they can
> use IronPython or Brail or the new IronRuby. NVelocity is a template
> language and I feel it should be left as such (although compilation
> would be cool).
--
Jonathon Rossi
use the codegenerator and you had to define your property bags? How else
would you be able to compile calls to objects without explicitly knowing
what object it is with a static language?
Regards, Jonathon Rossi
> -----Original Message-----
> From: castle-pro...@googlegroups.com [mailto:castle-project-
> de...@googlegroups.com] On Behalf Of craiggwilson
> Sent: Saturday, 12 May 2007 11:24 PM
> To: Castle Project Development List
Kunle Odutola
> Well, it supports duck typing :-)
>
> If it's not a big harm, I'd like to see NVelocity going a
> step further as a language. The lack of support for built in
> dictionaries, lack of support for decimals and its horrible
> implementation have always been a problem to us.
Decimals?. Do you have a basic use case for decimals support?
Imagine that a new NVelocity implementation exists that replaced the current
parser with a GPPG/ANTLR/CSharpCC/C#CUP version that supported the latest
Velocity VTL syntax, added the Castle syntax extensions but left the AST and
Visitor code essentially intact (save for changes needed to support new
Velocity syntax/semantics).
Would you be happy with it or, would you want to replace/rewrite the
AST/Visitor code too?
What else would you like to add to that implementation?
Any NVelocity API changes?
> If we can fix those, cool. If we can't, well, we might need
> to come up with a new template engine.
Something like ST# perhaps? (Presumably without the restrictions it imposes
to enforce separation).
Kunle
Hamilton Verissimo
if it's possible to rely on a dynamic foundation that is more
optimized than pure reflection, then all is good.
Jonathon Rossi
since we have control over the parser.
Support for real dictionaries is one feature I'd really like as well as many
others. I'm sure we'll be able to do much more with NVelocity, its syntax is
pretty good but as you said the implementation is really poor.
Regards, Jonathon Rossi
> -----Original Message-----
> From: castle-pro...@googlegroups.com [mailto:castle-project-
> de...@googlegroups.com] On Behalf Of Hamilton Verissimo
> Sent: Sunday, 13 May 2007 12:17 AM
> To: castle-pro...@googlegroups.com
> Subject: Re: NVelocity parser
>
>
Ayende Rahien
Hamilton Verissimo
> Decimals?. Do you have a basic use case for decimals support?
It always bite me. But for example, if there was a dictionary support
available, I would want to do
$Scritaculous.VisualEffect( 'mydiv', {duration: 1.2} )
> Imagine that a new NVelocity implementation exists that replaced the current
> parser with a GPPG/ANTLR/CSharpCC/C#CUP version that supported the latest
> Velocity VTL syntax, added the Castle syntax extensions but left the AST and
> Visitor code essentially intact (save for changes needed to support new
> Velocity syntax/semantics).
>
> Would you be happy with it or, would you want to replace/rewrite the
> AST/Visitor code too?
I can't see why not. Depends upon the effort to do it, and to make it
into production/stable level.
> What else would you like to add to that implementation?
> Any NVelocity API changes?
We can add a roadmap for it on the new wiki, just like
http://using.castleproject.org/display/MR/MonoRail+2+-+Roadmap
> Something like ST# perhaps? (Presumably without the restrictions it imposes
> to enforce separation).
I'm not familiar with ST, so I can't say.
Jonathon Rossi
from a clean slate I think it might be good idea to do it with the AST too;
ideas and some code could be used.
Regards, Jonathon Rossi
> -----Original Message-----
> From: castle-pro...@googlegroups.com [mailto:castle-project-
> de...@googlegroups.com] On Behalf Of Hamilton Verissimo
> Sent: Sunday, 13 May 2007 12:48 AM
> To: castle-pro...@googlegroups.com
> Subject: Re: NVelocity parser
>
>
Stuart Carnie
be for the right reasons too - as I think a particularly great feature
of NVelocity is it's simplicity. I selected it for a commercial
project to use in code generation, and others have adopted it for the
same reasons. I consider this simplicity part of it's 'secret
sauce'.
Something I'd definitely like to see improved is more predictable
white space handling when output is intermixed with #directives. Also
an #options directive would be great, to control various aspects of
the engine.
Some examples may include:
#options ( output=html|xml|text|..., foreach=NoNewLines)
output : to allow post formatting of the output. More useful in a
code generation scenario.
foreach : to control the newline handling. In code generation,
using the extended #foreach directive (#each, #between, etc) is great,
but having all the newlines is messy.
...
Cheers,
Stuart
On May 12, 7:16 am, "Hamilton Verissimo"
<hamm...@castlestronghold.com> wrote:
> Well, it supports duck typing :-)
>
> If it's not a big harm, I'd like to see NVelocity going a step further
> as a language. The lack of support for built in dictionaries, lack of
> support for decimals and its horrible implementation have always been
> a problem to us.
>
> If we can fix those, cool. If we can't, well, we might need to come up
> with a new template engine.
>
> On 5/12/07, craiggwilson <craiggwil...@gmail.com> wrote:
>
>
>
> > I think if someone needs a dynamic language for their views, they can
> > use IronPython or Brail or the new IronRuby. NVelocity is a template
> > language and I feel it should be left as such (although compilation
> > would be cool).
>
> --
> Cheers,
> hamilton verissimo
> hamm...@castlestronghold.comhttp://www.castlestronghold.com/
Jonathon Rossi
we shouldn't be making this a full blown programming language.
What would changing the output property of the #options directive do. Would
it be like XSLT? So for example, references could automatically be escaped.
Improved whitespace handling is one thing that would be good. What did you
think if the idea I proposed in a previous email where I said this:
"You could use XHTML detection at the execution level if you wanted the
engine to automatically indent your XHTML tags and format it for you. Or you
could set an option to pack the XHTML as much as possible. Just an idea, not
sure if anyone is after this type of feature. There basically isn't any
performance disadvantage to this since the template will be compiled."
Regards, Jonathon Rossi
> -----Original Message-----
> From: castle-pro...@googlegroups.com [mailto:castle-project-
> de...@googlegroups.com] On Behalf Of Stuart Carnie
> Sent: Tuesday, 15 May 2007 4:17 PM
> To: Castle Project Development List
> Subject: Re: NVelocity parser
>
>
Stuart Carnie
> One reason I chose NVelocity over Brail was for its simplicity, I agree that
> we shouldn't be making this a full blown programming language.
>
> What would changing the output property of the #options directive do. Would
> it be like XSLT? So for example, references could automatically be escaped.
>
indenting output, etc.
> Improved whitespace handling is one thing that would be good. What did you
> think if the idea I proposed in a previous email where I said this:
>
> "You could use XHTML detection at the execution level if you wanted the
> engine to automatically indent your XHTML tags and format it for you. Or you
> could set an option to pack the XHTML as much as possible. Just an idea, not
> sure if anyone is after this type of feature. There basically isn't any
> performance disadvantage to this since the template will be compiled."
>
That was my intent of the #options tag.
#options ( output=xhtml|xml|text|etc )
That way, we can be explicit rather than attempting to detect the
output. If I specify #options (output=xhtml), the output will be
indented appropriately.
Fábio Batista
> > Improved whitespace handling is one thing that would be good. What did you
> > think if the idea I proposed in a previous email where I said this:
> >
> > "You could use XHTML detection at the execution level if you wanted the
> > engine to automatically indent your XHTML tags and format it for you. Or you
> > could set an option to pack the XHTML as much as possible. Just an idea, not
> > sure if anyone is after this type of feature. There basically isn't any
> > performance disadvantage to this since the template will be compiled."
> >
> That was my intent of the #options tag.
>
> #options ( output=xhtml|xml|text|etc )
>
> That way, we can be explicit rather than attempting to detect the
> output. If I specify #options (output=xhtml), the output will be
> indented appropriately.
I don't think auto-indent is really important, as it could be made
with post-processors, thus, independently of the template engine. I
can't see any advantage on embedding this kind of code on NVelocity
itself.
Things i see that are important to add to a rewrite:
- Allowing formal references to directives, just like they added to
the lastest Velocity, so cases like the following are possible:
<span class="#{if($test)}class1#{else}class2#{end}">
- Allow discarding the result of a method call (syntax is just a suggestion):
#void($myObject.someMethodThatReturnsSomethingIDontWant(...)})
- Allow simple String.Format shortcuts (syntax is just a suggestion):
<td> $myObj.moneyProperty%n2 </td>
<td> $myObj.dateProperty%MM/dd/yyyy </td>
<td> ${myObj.dateProperty%MMM, dd yyyy} </td>
- Allow "escaping objects", that can be supplied to the template
engine, maybe implementing somethink like ITextEscape:
<td> $myObj.complexTextData%xmlescape </td>
<script> alert("$myObj.textData%jsescape") </script>
$myObj.text%customescape
- "select case":
#switch ($var)
#case (1)
..
#case (2)
..
#end
- "eval":
#set ($templateText = 'Welcome, $name') ## would probably come from
DB or something
#set ($name = 'Lord')
#eval ($templateText) ## renders the result
#eval ($result = $templateText) ## saves into a variable
- "with":
#with ($customer)
$name
$address.street
#end
- support for optional cleaner block closing:
#if (...) #endif #with (...) #endwith
- support for named parameters on method calls, using default values
for parameters not supplied. would make helpers a lot cleaner:
$ajaxHelper.buttonToRemote(innerContent: "test", url: "...")
- support for line breaks on method calls (I never tested, maybe it
already works):
$ajaxHelper.buttonToRemote(
innerContent: "test",
url: "..."
)
- nice dictionary notation (already discussed);
That's all I can remember now. Maybe we should set up a scrap page on
Jira, where everyone can come with new ideas.
Colin Ramsay
Jonathon Rossi
That’s what I was thinking too, I don’t think specifying it in every template it very nice. You could configure certain files for each mode and leave everything else to the default.
I’m trying to think of a reason to embed it into NVelocity but I can’t, maybe to disable changing the format of a section. Some things like calling helpers and viewcomponents would also be more work to format in the desired way.
Regards, Jonathon Rossi
From: castle-pro...@googlegroups.com
[mailto:castle-pro...@googlegroups.com] On Behalf Of Colin Ramsay
Sent: Wednesday, 16 May 2007 6:00 AM
To: castle-pro...@googlegroups.com
Subject: Re: NVelocity parser
This is just my opinion, but I don't understand the point of an #options directive. Isn't this something that should be taken care of in configuration?
<br
Jonathon Rossi
code colourising will colour it for you ;).
Many good suggestions, I don't like some of the syntax but you are just
brainstorming. I won't try to reply to your ideas via email because it will
get hard to read.
A page\issue in JIRA might be a bit hard to manage, a development wiki would
be good but we don't have one. I'm not sure were we could keep a list of
possible additions and be able to discuss them.
Regards, Jonathon Rossi
> -----Original Message-----
> From: castle-pro...@googlegroups.com [mailto:castle-project-
> de...@googlegroups.com] On Behalf Of Fábio Batista
> Sent: Wednesday, 16 May 2007 4:52 AM
> To: castle-pro...@googlegroups.com
> Subject: Re: NVelocity parser
>
>
Stuart Carnie
When it is absent from the template, it behaves as NVelocity does
today.
I'm taking the broader view, where NVelocity is a template generation
tool, not just a View Component for MonoRail. I understand that
output formatting is fairly irrelevant when generating HTML pages;
however, for code generation, it is very important the output is more
logically formatted.
I think the #options directive should be pluggable, so new options can
be registered through configuration. In addition the 'output' option
would be better called 'postprocess'. One could specify a fully
qualified class to instantiate, or a pre-registered keyword for
different post processing, such as xhtml, xml, etc.
This directive would almost certainly be avoided for MonoRail View
Component templates.
It would typically be defined at the top of a template, however I
don't see any reason it couldn't be used to change the state of the
engine throughout the template.
I'm not to concerned about the #options keyword, just a suggestion.
On May 15, 12:59 pm, "Colin Ramsay" <colinram...@gmail.com> wrote:
> This is just my opinion, but I don't understand the point of an #options
> directive. Isn't this something that should be taken care of in
> configuration?
>
Stuart Carnie
On May 15, 3:37 pm, "Jonathon Rossi" <j...@jonorossi.com> wrote:
> I thought NVelocity already had formal directives. Well if it doesn't my
> code colourising will colour it for you ;).
>
> Many good suggestions, I don't like some of the syntax but you are just
> brainstorming. I won't try to reply to your ideas via email because it will
> get hard to read.
>
> A page\issue in JIRA might be a bit hard to manage, a development wiki would
> be good but we don't have one. I'm not sure were we could keep a list of
> possible additions and be able to discuss them.
>
> Regards, Jonathon Rossi
>
>
>
> > -----Original Message-----
> > From: castle-pro...@googlegroups.com [mailto:castle-project-
> > de...@googlegroups.com] On Behalf Of Fábio Batista
> > Sent: Wednesday, 16 May 2007 4:52 AM
> > To: castle-pro...@googlegroups.com
> > Subject: Re: NVelocity parser
>
> > fabio.david.bati...@gmail.com
> >http://nerd-o-matic.blogspot.com
Kunle Odutola
> Things i see that are important to add to a rewrite:
>
> - Allowing formal references to directives, just like they
> added to the lastest Velocity, so cases like the following
> are possible:
> <span class="#{if($test)}class1#{else}class2#{end}">
It should fully support the latest revision of the Velocity language plus
any custom Castle changes.
> That's all I can remember now. Maybe we should set up a scrap
> page on Jira, where everyone can come with new ideas.
+1
Won't a wiki Roadmap-style page be more flexible (at least in the
short-term)?
Kunle
Jonathon Rossi
Regards, Jonathon Rossi
> -----Original Message-----
> From: castle-pro...@googlegroups.com [mailto:castle-project-
> de...@googlegroups.com] On Behalf Of Stuart Carnie
> Sent: Wednesday, 16 May 2007 8:39 AM
> To: Castle Project Development List
> Subject: Re: NVelocity parser
>
>
Stuart Carnie
Some great ideas there.
Another feature:
* Perhaps we should consider support of extension methods, similar
to C# 3.0.
This would make it easy to implement the to_quote() and
to_squote() functions that the Castle team has provided, and allow for
further expansion, perhaps for you formatting, etc.
On May 15, 11:51 am, "Fábio Batista" <fabio.david.bati...@gmail.com>
wrote:
You can already achieve this using $
{myObj.dateProperty.ToString("[format string]")
Perhaps we can come up with a shorthand for this.
> - Allow "escaping objects", that can be supplied to the template
> engine, maybe implementing somethink like ITextEscape:
> <td> $myObj.complexTextData%xmlescape </td>
> <script> alert("$myObj.textData%jsescape") </script>
> $myObj.text%customescape
>
> - "select case":
> #switch ($var)
> #case (1)
> ..
> #case (2)
> ..
> #end
>
I agree this would be useful.
> - "eval":
> #set ($templateText = 'Welcome, $name') ## would probably come from
> DB or something
> #set ($name = 'Lord')
>
> #eval ($templateText) ## renders the result
> #eval ($result = $templateText) ## saves into a variable
>
Also would be useful.
> - "with":
> #with ($customer)
> $name
> $address.street
> #end
>
> - support for optional cleaner block closing:
> #if (...) #endif #with (...) #endwith
>
I agree; however we should support #end for compatibility too, which I
think you are suggesting.
> - support for named parameters on method calls, using default values
> for parameters not supplied. would make helpers a lot cleaner:
> $ajaxHelper.buttonToRemote(innerContent: "test", url: "...")
>
Good too.
> - support for line breaks on method calls (I never tested, maybe it
> already works):
> $ajaxHelper.buttonToRemote(
> innerContent: "test",
> url: "..."
> )
>
> - nice dictionary notation (already discussed);
>
> That's all I can remember now. Maybe we should set up a scrap page on
> Jira, where everyone can come with new ideas.
>
> --
> Fábio David Batista
> fabio.david.bati...@gmail.comhttp://nerd-o-matic.blogspot.com
Jonathon Rossi
few places.
Regards, Jonathon Rossi
> -----Original Message-----
> From: castle-pro...@googlegroups.com [mailto:castle-project-
> de...@googlegroups.com] On Behalf Of Stuart Carnie
> Sent: Wednesday, 16 May 2007 9:21 AM
> To: Castle Project Development List
> Subject: Re: NVelocity parser
>
>
Jonathon Rossi
get someone more important to create the page for us since I can't see any
where to create a page.
I guess we just need a single page to document the syntax of new features.
Regards, Jonathon Rossi
> -----Original Message-----
> From: castle-pro...@googlegroups.com [mailto:castle-project-
> de...@googlegroups.com] On Behalf Of Stuart Carnie
> Sent: Wednesday, 16 May 2007 8:41 AM
> To: Castle Project Development List
> Subject: Re: NVelocity parser
>
>
Fábio Batista
I've set up a page with my initial suggestions. Everyone is free to
register and then edit the page.
http://using.castleproject.org/display/MR/Castle.NVelocity+Discussions
Stuart Carnie
On May 15, 5:22 pm, "Fábio Batista" <fabio.david.bati...@gmail.com>
wrote:
> using.castleproject.org is a wiki.
>
> I've set up a page with my initial suggestions. Everyone is free to
> register and then edit the page.
>
> http://using.castleproject.org/display/MR/Castle.NVelocity+Discussions
>
> fabio.david.bati...@gmail.comhttp://nerd-o-matic.blogspot.com
Kunle Odutola
> Kunle wrote:
> One strength of the Yacc-style tools is that LR grammars
> require less "refactoring" than LL grammars. The new LL*
> support in ANTLR v3 levels the field considerably but, LR
> tools still have an edge there [ but no AntlrWorks sadly ;-) ].
I take this back.
Developing and debugging LR grammars for used with GPPG currently.
Arrrrrrrrrrrrrrrrrghhh!!!!
Kunle