[
https://issues.apache.org/jira/browse/VELOCITY-917?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16859339#comment-16859339
]
Claude Brisson commented on VELOCITY-917:
-----------------------------------------
Right now, in the parser_experiments branch, a use can already build a custom
parser with the velocity-engine-core module, by customizing the parser maven
properties:
{noformat}
<!-- You can modify those properties to build a custom parser.
The parser.name property will be used to generate the class:
org.apache.velocity.runtime.parser.${parser.name}Parser
which you must specify at runtime using the parser.class Velocity
property.
You'll have to skip the tests which for now don't work for custom
parsers:
mvn -DskipTests package
and extract the parser class from the generated jar if you wish
this custom parser to
coexist with the standard one.
-->
<parser.debug>false</parser.debug>
<parser.name>Standard</parser.name>
<parser.char.asterisk>*</parser.char.asterisk>
<parser.char.at>@</parser.char.at>
<parser.char.dollar>$</parser.char.dollar>
<parser.char.hash>#</parser.char.hash>
{noformat}
It's even dangerous per se, because if the user uses the generated jar, it may
poison legitimate standard Velocity parsers elswhere.
I started a custom plugin, but it's an empty shell. It should expose the same
properties in its configuration, and then (both in generate-sources phase) :
+ filter-remote-copy the resource file
{{org/apache/velocity/runtime/parser/Parser.jjt}} towards {{target/parser}}
+ launch javacc on this file to generate the final
org.apache.velocity.runtime.parser.${parser.name}Parser class
I'm not familiar with Groovy or Groovy Maven Plugin.
> 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: [email protected]
For additional commands, e-mail: [email protected]
