[ 
https://issues.apache.org/jira/browse/VELOCITY-917?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16855398#comment-16855398
 ] 

Michael Osipov commented on VELOCITY-917:
-----------------------------------------

The user-defined module will contain the custom parser built from the JavaCC 
stub and configurable parameters. The stub can be filtered with Velocity and 
the plugin producing the fully qualified JavaCC file would receive a map of 
properties to be fully dynamic. The custom parser will be complete at compile 
time.

(1) Provide JavaCC stub file?
(2) Have the use use provide properties in a plugin written by us
(3) have the plugin read those properties and the stub file
(4) Merge both
(5) Handle over to the JavaCC plugin
(6) Compile generated parser code

> 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

Reply via email to