You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@velocity.apache.org by "Jarkko Viinamäki (JIRA)" <de...@velocity.apache.org> on 2009/01/02 17:01:44 UTC

[jira] Updated: (VELOCITY-661) Parsing errors on content inside #literal() #end block

     [ 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: dev-unsubscribe@velocity.apache.org
For additional commands, e-mail: dev-help@velocity.apache.org