Well, it definitely seems better to handle the whitespace issue with
post-processing than with the grammar-- it looks like most of the "hmm
will this work" comments in the grammar all relate to munching
whitespace as part of parsing. And of course the way it's handled
currently means that if you wanted flexibility about how to handle
whitespace, you're *totally* dead in the water.
I buy the "parsing schmoo gives you schmoo" argument only so much.
Because that applies only with an empty context! You either have to
know everything that can possibly be set in the context through all time
and space, or you have to have the happy situation that a dollar sign
followed by text isn't all that common. Otherwise, you have to always
escape dollar signs. Using the ${D} hack instead of the so-called
"escape" mechanism, since the escape doesn't actually escape /parsing/. ;-)
Actually, removing the backslash mechanism from the language entirely
would probably help everyone involved-- it would eliminate sooooo many
special cases and "I'm not sure if this works" hacks, on both sides of
the fence-- Velocity template authors and Velocity developers. Man, you
want funny, look at the handling for $\!foo. Ouch, my head hurts.
I'm not really familiar with JavaCC but at this point it doesn't look
like SimpleNode is set up to allow modifications, nor does it have a
copy constructor or a clone method. So modifying the AST after parsing
is currently a no-go. For my problem, adding a "is reference a
constant" callout to the grammar file would be easy and I'm thinkin'
${D} and ${H} are gonna be hardcoded as special literals. Just because
I can. Muhahaha.
But to handle whitespace like you want-- configurably-- you'd want to
tweak an AST that's already been built, and have the grammar be
completely respectful of whitespace and create whitespace literal tokens
for you.
Definitely interesting to think about, tho... ;-)
--jason
Christoph Reck wrote:
Jason Pettiss wrote:
Actually, after reading through the parser grammar it's pretty clear
this is haunting the authors. They're trying to describe an escape
sequence in the grammar itself which causes havoc for the poor
parser. Escape sequences should be handled by the scanner. Really
when \$ appears in the stream it should be emitted as $ in literal
output, with no possibility to be tokenized. Then the grammer
doesn't care and is smaller, the parser is faster, and you have an
outlet for backwards-compatible growth if in the future you need new
language constructs. (Imagine if #hello is in my template. And in
the future hello becomes a directive. It breaks me. But if I do
\#hello now, then I'm always covered.)
Your point is a good one-- does the speed really matter? In most
cases no, it really doesn't. In my case it actually might, I don't
know... there are a TON of dollar signs over megabytes of content.
I'm just imagining an interrupted stream and a hashmap lookup for
each and every one... there's no notion of constant or final template
variables is there?
Hmm. Anyway, thanks for the thoughts.
[snip]
I can see that you understood the issue with escaping and the grammar
(not my dog-food :), the issue that parsing any schmoo should produce
the same schmoo prohibits gobbling the backslash in a \$foo sequence.
OTOH, your idea of a "notion of constant or final template variables"
is a good one. The short answer is no :(
So this could be a feature request. Could it be done during parse time
creating the text nodes?
A workaround is to walk yourself the AST from an already parsed template
and work in the appropriate text nodes into the exising nodes before or
after!. Is this feasible? One could fit such a thing in by wrapping
an existing resource loader. (Side note: the post-processing of the
AST is an idea I have been thinking about for the whitespace gobbling
handling issue... more on this issue is in the wiki)
Cheers,
Christoph
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
