[
https://issues.apache.org/jira/browse/VELOCITY-917?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16853490#comment-16853490
]
Claude Brisson commented on VELOCITY-917:
-----------------------------------------
I was anticipating some debate.
We can't make it better with JavaCC. Even differentiating '#' uses between ##
and #macro doesn't seem doable. And I'm even inclined to think that we can't
avoid altering performances without a patch. Yes, patching a class file is a
technique which can be considered as a hack, and yes the patches will need to
be updated, but it's just a shell script to launch, and should it be a hack,
it's a very clean one.
{quote}
On a more general note, are you sure it is a good idea to add this
configuration? Velocity is supposed to be an extremely lightweight language,
and while I see the usefulness of this feature, it may complicate
documentation, split the community if a major user decides to change the
syntax, and reduce the cohesiveness in general.
{quote}
Yes. I really think it's a good idea, if not a must have. The usefulness of a
template engine lies in its syntactic orthogonality with the target language.
Should you want to use Velocity to do Markdown templating today? Bad luck. You
just can't.
The documentation will stay with the standard characters, of course. It will
only mention that it's possible to substitute some characters for others using
an *advanced* option.
The default syntax being orthogonal to HTML and quite good for Java sources, it
covers a very good percentage of uses. So I'm pretty sure that this feature
will remain of confidential use. Should it not, this hypothetical major user
will have his own syntax documentation, but I really don't see it as a risk for
the community, since it will be the same engine underneath. Without the
feature, this major user will just use another engine.
{quote}
Arobase is French, not English. It's also asterisk and not star.
{quote}
Oops. Thanks. So we're left with *dollar*, *hash*, *at* and *asterisk*.
{quote}
Though I do not like the custom classloader approach. It seems to as too much
heavy lifting.
{quote}
Well, I searched for a better way to do it, but apart from rewriting a parser
from scratch, I don't see any. At least I'm happy not to need asm or ByteBuddy.
{quote}
If we can't make it better with JavaCC then don't do it.
{quote}
Well, I'm doing it anyway and we'll vote for inclusion in master.
> VTL Grammar Characters Configuration
> ------------------------------------
>
> Key: VELOCITY-917
> URL: https://issues.apache.org/jira/browse/VELOCITY-917
> Project: Velocity
> Issue Type: New Feature
> Components: Engine
> Affects Versions: 2.2
> Reporter: Claude Brisson
> Assignee: Claude Brisson
> Priority: Major
>
> Experimental feature.
> The goal is to introduce new configuration parameters to be able to change
> the VTL grammar. For instance:
> parser.character.dollar = '~'
> parser.character.hash = '@'
> parser.character.arobase = '%'
> parser.character.star = '?'
> Requirements:
> + fully B.C.
> + done at runtime, without the need to recompile the parser
> + null impact on performance
> Implementation:
> 1. Parametrize code that needs explicit references to those characters
> 2. Define a ParserTokenManager interface and have the parser use this
> interface rather than a concrete class
> 3. Use a custom class loader to *patch* the concrete token manager .class
> file, instantiate this custom token manager and initialize parsers with it
> The binary patch is prepared at compilation time (there will be one patch per
> JRE vendor and class file version).
> Due to the limited capability of this technique, the chosen characters are
> restricted to UTF-8 single bytes characters. Patches _could_ be prepared for
> two-bytes or more characters, but there would be the need to have as many
> parser objects as variants in one/two/... characters combinations.
> Also, some characters and combinations are obviously invalid.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org
