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

Michael Osipov edited comment on VELOCITY-917 at 6/1/19 11:30 AM:
------------------------------------------------------------------

Arobase is French, not English. It's also asterisk and not star. I think this 
is a good idea because we'd like to use consistent approaches throughout 
template languages (frameworks) at work. Python's mako supports this. Though, I 
do not like the custom classloader approach. It seems to as too much heavy 
lifting. If we can't make it better with JavaCC then don't do it.


was (Author: michael-o):
Arobase is French, not English. It's also asterisk and not star. I think this 
is a good idea because we'd like to use consistent approaches throughout 
template language at work. Python's mako supports this. Though  I do not like 
the custom classloader approach. It seems to as too much heavy lifting. If we 
can't make it better with JavaCC then don't do it.

> 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