[
https://issues.apache.org/jira/browse/VELOCITY-917?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16855125#comment-16855125
]
Claude Brisson commented on VELOCITY-917:
-----------------------------------------
{quote}What about having the user to provide a custom parser? This may no be a
perfect solution, but one w/o performance issues. You have to evaluate whether
this is possible at all:
Consider we provide a stub JavaCC definition file which can read the (custom)
token defition at compile time, thus the user has a distinct Maven module in
his build which contains a custom parser with his tokens and this one can be
plugged at start time into Velocity, if none provided we take our
DefaultParser.class. No runtime class modifications necessary.
{quote}
Making the parser pluggable is the way to go, in fact the hard part is already
done in the branch (for the Parser and ParserTokenManager -aka lexer, objects).
I also agree in the idea of having a grammar file which is templatized by Maven
properties, if that's what you mean by JavaCC stub.
But I'm not sure I fully understand your proposal regarding the distinct Maven
module. It would typically only contains a the custom parser, as I understand
it, but where would this specific module come from:
* would it be a user defined module, depending on a new velocity-custom-parser
plugin, for instance?
* or is there any other mean to dynamically generate a custom module at
compile time?
* otherwise, what did you mean? Where would the {{build.properties}} file
defining the custom parser be?
> 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
