[
https://issues.apache.org/jira/browse/VELOCITY-661?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jarkko Viinamäki updated VELOCITY-661:
--------------------------------------
Attachment: velocity-661-v1.0.patch
OK. Here's my attempt to fix this issue.
This patch introduces a new token type which I call "Textblock". Textblocks can
be marked like this:
#% here you can have any text, characters etc. %#
Velocity will not attempt to parse anything between "#% " and " %#" and will
output content between these tokens as such. Note that one whitespace is part
of each token.
With this feature it is easy to deal with issues described e.g. in VELOCITY-584
Reasons for selecting this token format:
1. It's short and thus easy to use.
2. It is quite unlikely that you need to have string " %#" inside the area you
want to "escape" with a Textblock. Thus there is no need for a custom end token
(which would have been tricky to implement). Note that you can have %# inside
the area as long as it doesn't have whitespace in front of it.
This patch also includes some performance tweaks made to the parser:
1. Transformation StringBuffer -> StrBuilder is done with Ant script after the
generation.
2. Parser state is stored using a custom inner class instead of Hashtable which
wastes space.
Note that I'm a total newbie with JavaCC (I took a closer look at it today for
the first time) so the parser might not be as efficient as possible. I had to
use the JavaCC MORE feature when in IN_TEXTBLOCK mode. I'm not sure if this is
the only way.
NOTICE! You must use "ant parser" command to process the Parser.jjt which then
generates Parser.java etc. I didn't include the generated files in this patch
since TortoiseSVN complained something about invalid linefeeds. I noticed that
JavaCC 4.2 is incompatible with existing classes. JavaCC 4.0 worked OK.
Tweaks to the build.xml:
1. Now it's possible to execute just one Test Case by defining the test case
name:
ant -Dtestcase=org.apache.velocity.test.TextblockTestCase test
This makes debugging a lot faster.
2. Generated ParserTokenManager is tweaked to use StrBuilder by simple search &
replace.
> Parsing errors on content inside #literal() #end block
> ------------------------------------------------------
>
> Key: VELOCITY-661
> URL: https://issues.apache.org/jira/browse/VELOCITY-661
> Project: Velocity
> Issue Type: Improvement
> Components: Engine
> Affects Versions: 1.6.1
> Environment: ALL
> Reporter: ND
> Attachments: velocity-661-v1.0.patch
>
>
> I have some velocity templates that include quit some javascript. Inside the
> javascript a javascrip template engine is used which also uses ${varname}
> Escaping each occurance would make the code rather unreable, so to prevent
> velocity from parsing the javascript code, I put a #literal() around it.
> However, velocity still PARSES the contents of this block, which of course
> results in parsing exceptions.
> My feeling with "literal" is that it is completely UNINTERPRETED content?
> This SHOULD work:
> #literal()
> var myId = 'someID';
> $('#test).append($.template('<div id="${myId}"></div>').apply({myId: myId}));
> #end
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
