MVEL
  1. MVEL
  2. MVEL-70

Templating syntax doesnt match documentation.

    Details

    • Type: Bug Bug
    • Status: Closed Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 1.2.22
    • Component/s: Templating
    • Labels:
      None
    • Number of attachments :
      1

      Description

      MVEL attempts to evaluate anything preceded by an @ symbol, whether or not the following text is contained in curly braces. The behaviour doesnt appear to be as described in the documentation.

      For example, evaluating the following template causes an error (assuming there is no object called smith in context)...

      String template = "my email is john@smith.com";
      String result = TemplateInterpreter.evalToString(template, rootObject, map);

      However, the documentation at http://mvel.codehaus.org/Templating+Basics says...

      "Orb tags are comprised of a preceding @ character, followed by

      {...}

      brackets which contain regular MVEL expressions."

      This suggests that curly braces are required for template text to be considered an expression.

      Given that @ symbols are extremely common in content i suggest modifying the behaviour to match the documentation, rather then the other way around.

        Activity

        Hide
        Mike Brock added a comment -

        I am unable to reproduce this bug. Can you provide specific template code that is causing the error:

        For example the template: "email:@

        {'foo@foo.com'}

        " correctly returns: "email:foo@foo.com"

        Show
        Mike Brock added a comment - I am unable to reproduce this bug. Can you provide specific template code that is causing the error: For example the template: "email:@ {'foo@foo.com'} " correctly returns: "email:foo@foo.com"
        Hide
        brad mcevoy added a comment -

        Has taken a while, but now have reproduced the fault in a test case

        Show
        brad mcevoy added a comment - Has taken a while, but now have reproduced the fault in a test case
        Hide
        brad mcevoy added a comment -

        The attached zip file has 2 tests. One succeeds and the other fails. They both use the same code and only differ in the template each runs. The one that fails has an at symbol without curly braces. This is replaced with ' at ' in the other template.

        Show
        brad mcevoy added a comment - The attached zip file has 2 tests. One succeeds and the other fails. They both use the same code and only differ in the template each runs. The one that fails has an at symbol without curly braces. This is replaced with ' at ' in the other template.
        Hide
        Mike Brock added a comment -

        Fixed in trunk. Next version will allow you to escape the @ character explicitly by doing: @@

        so: "test@@test.com" == "test@test.com"

        Show
        Mike Brock added a comment - Fixed in trunk. Next version will allow you to escape the @ character explicitly by doing: @@ so: "test@@test.com" == "test@test.com"
        Hide
        brad mcevoy added a comment -

        In my opinion evaluating template text as expressions without curly braces is undesirable. I would prefer a solution where test@test.com is always interpreted as literal text.

        But regardless of that evaluation must be consistent, and it isnt (at least in the mvel release i tested). The template given in this jira's description actually works, while the test case fails. But both are semantically and syntactically the same. I haven been unable to determine what factors cause MVEL to evaluate them differently.

        Show
        brad mcevoy added a comment - In my opinion evaluating template text as expressions without curly braces is undesirable. I would prefer a solution where test@test.com is always interpreted as literal text. But regardless of that evaluation must be consistent, and it isnt (at least in the mvel release i tested). The template given in this jira's description actually works, while the test case fails. But both are semantically and syntactically the same. I haven been unable to determine what factors cause MVEL to evaluate them differently.
        Hide
        chinna added a comment -

        I am facing one issue with MFVL formatting. can some one please help me?

        I have text like below.

        enter amount between $5.00 and $@

        {MSAKLABLE}

        MFVL is not able to replace the MSAKLABLE attribute value with original value. If i put space between $ and @

        {...}

        chars , it is working..

        Show
        chinna added a comment - I am facing one issue with MFVL formatting. can some one please help me? I have text like below. enter amount between $5.00 and $@ {MSAKLABLE} MFVL is not able to replace the MSAKLABLE attribute value with original value. If i put space between $ and @ {...} chars , it is working..

          People

          • Assignee:
            Mike Brock
            Reporter:
            brad mcevoy
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: