Cocoon
  1. Cocoon
  2. COCOON-1523

[PATCH] XSP expressions (attribute value/text interpolation)

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 2.1.8
    • Fix Version/s: None
    • Component/s: Blocks: XSP
    • Labels:
      None
    • Environment:
      Operating System: other
      Platform: Other

      Description

      In [1] in we discussed an XSP expression syntax for attribute value and text
      expressions. This patch makes expressions available.

      In XSP, you now can write:
      <elem attrib="{#expression}" which will be expanded to:
      <elem><xsp:attribute
      name="attrib"><xsp:expr>expression</xsp:expr><xsp:attribute></elem>
      or
      <elem>Hello #user.getFullName</elem>, which will be expanded to <elem>Hello
      <xsp:expr>user.getFullName</xsp:expr></elem>

      Writing {##text} will prevent expansion and will be replaced by the text
      "{#text}". Inside expressions, write "##" to get "#" and "#}" to get "}".

      This works in XSPs as well as logicsheets. The '#' was chosen out of the
      discussed characters because it is IMO least likely to occur in an expression in
      the used languages.

      This feature is turned on by default and can be turned off by setting
      "attribute-value-interpolation" or "text-interpolation" to "false" in cocon.xconf:

      <markup-languages>
          <xsp-language ... attribute-value-interpolation="false"
      text-interpolation="false">
              ...
          </xsp-language>
      </markup-language>

      It can be turned on or off on a per-XSP-/logicsheet-basis by setting attributes
      "attribute-value-interpolation" or "text-interpolation" of the top level element
      to true or false. Note that these attributes must belong to the
      "http://apache.org/xsp" namespace.

      How it works:

      New class XSPExpressionParser is a parser for the expressions. New class
      XSPExpressionFilter is a filter that gets SAX events with embedded expressions
      and generates SAX events for expanded expressions. This is used in LogicSheet to
      filter read logicsheers and in XSPMarkupLanguage to filter the XSP.

      Changes to existing code.

      LogicSheets need to know the namespace and uri of the markup language in order
      to replace expressions. Therefor AbstractMarkupLanguage needs to know this when
      reading logicsheets. This meant that I had to move this configuration
      information from parametrize to configure. It is unclear to me anyway, why
      AbstractMarkupLanguage used both methods at the same time (which are described
      as "incompatible" in the Avalon documentation).

      The old PreProcessFilter wraps text() nodes in <xsp:text> elements inside some
      tags (See [2]). It is unclear to me why this was done, and all XSPs I've tested
      worked without this. I got no reponse on the list, so I left this feature out of
      the new PreProcessFilter.

      If any of the above changes need further discussion, clarification or change,
      please tell me and I'll update the patch.

      This patch also should be applied to 2.2. If it does not work, again please tell
      me and I'll make a 2.2 patch available.

      [1] http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=111693513631888&w=2

      [2] http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=111778627925208&w=2

        Activity

        Jochen Kuhnle created issue -
        Hide
        Jochen Kuhnle added a comment -
        Created an attachment (id=15303)
        Patch for XSP expressions
        Show
        Jochen Kuhnle added a comment - Created an attachment (id=15303) Patch for XSP expressions
        Hide
        Jochen Kuhnle added a comment -
        (In reply to comment #0)
        Oops, typo. Text interpolation of course uses curlies to:
        In XSP, you now can write:
        <elem attrib="{#expression}" which will be expanded to:
        <elem><xsp:attribute
        name="attrib"><xsp:expr>expression</xsp:expr><xsp:attribute></elem>
        or
        <elem>Hello {#user.getFullName}</elem>, which will be expanded to <elem>Hello
        <xsp:expr>user.getFullName</xsp:expr></elem>
        Show
        Jochen Kuhnle added a comment - (In reply to comment #0) Oops, typo. Text interpolation of course uses curlies to: In XSP, you now can write: <elem attrib="{#expression}" which will be expanded to: <elem><xsp:attribute name="attrib"><xsp:expr>expression</xsp:expr><xsp:attribute></elem> or <elem>Hello {#user.getFullName}</elem>, which will be expanded to <elem>Hello <xsp:expr>user.getFullName</xsp:expr></elem>
        Hide
        Alfred Nathaniel added a comment -
        Trying to apply patch to 2.1.
        Show
        Alfred Nathaniel added a comment - Trying to apply patch to 2.1.
        Hide
        Alfred Nathaniel added a comment -
        I applied the patch to 2.1 but did a few changes.

        Disabling the interpolation features on each logicsheet individually is
        overkill. A pair of global flags is enough in order to give a fast way out in
        case someone has problems with existing XSPs.

        So I moved the flags to AbstractMarkupLanguage and left them to be set as
        Parameterizable. Making them accessible with getters also allowed to reduce
        the very long argument lists in the orginal patch.

        There was a Java1.5 feature (String.contains) used. Please bear in mind that
        Cocoon 2.1 should run with Java1.3 and Cocoon 2.2 must be Java1.4 compatible.

        Otherwise that is great stuff and I hope to see more of it.
        Show
        Alfred Nathaniel added a comment - I applied the patch to 2.1 but did a few changes. Disabling the interpolation features on each logicsheet individually is overkill. A pair of global flags is enough in order to give a fast way out in case someone has problems with existing XSPs. So I moved the flags to AbstractMarkupLanguage and left them to be set as Parameterizable. Making them accessible with getters also allowed to reduce the very long argument lists in the orginal patch. There was a Java1.5 feature (String.contains) used. Please bear in mind that Cocoon 2.1 should run with Java1.3 and Cocoon 2.2 must be Java1.4 compatible. Otherwise that is great stuff and I hope to see more of it.
        Hide
        Alfred Nathaniel added a comment -
        Also applied to 2.2 trunk.
        Show
        Alfred Nathaniel added a comment - Also applied to 2.2 trunk.
        Jeff Turner made changes -
        Field Original Value New Value
        issue.field.bugzillaimportkey 35228 12324832
        Pier Fumagalli made changes -
        Workflow jira [ 12341267 ] Cocoon Workflow [ 12342145 ]
        Ralph Goers made changes -
        Component/s Blocks: (Undefined) [ 12310440 ]
        Bugzilla Id 35228
        Component/s Blocks: XSP [ 12310448 ]
        Description In [1] in we discussed an XSP expression syntax for attribute value and text
        expressions. This patch makes expressions available.

        In XSP, you now can write:
        <elem attrib="{#expression}" which will be expanded to:
        <elem><xsp:attribute
        name="attrib"><xsp:expr>expression</xsp:expr><xsp:attribute></elem>
        or
        <elem>Hello #user.getFullName</elem>, which will be expanded to <elem>Hello
        <xsp:expr>user.getFullName</xsp:expr></elem>

        Writing {##text} will prevent expansion and will be replaced by the text
        "{#text}". Inside expressions, write "##" to get "#" and "#}" to get "}".

        This works in XSPs as well as logicsheets. The '#' was chosen out of the
        discussed characters because it is IMO least likely to occur in an expression in
        the used languages.

        This feature is turned on by default and can be turned off by setting
        "attribute-value-interpolation" or "text-interpolation" to "false" in cocon.xconf:

        <markup-languages>
            <xsp-language ... attribute-value-interpolation="false"
        text-interpolation="false">
                ...
            </xsp-language>
        </markup-language>

        It can be turned on or off on a per-XSP-/logicsheet-basis by setting attributes
        "attribute-value-interpolation" or "text-interpolation" of the top level element
        to true or false. Note that these attributes must belong to the
        "http://apache.org/xsp" namespace.

        How it works:

        New class XSPExpressionParser is a parser for the expressions. New class
        XSPExpressionFilter is a filter that gets SAX events with embedded expressions
        and generates SAX events for expanded expressions. This is used in LogicSheet to
        filter read logicsheers and in XSPMarkupLanguage to filter the XSP.

        Changes to existing code.

        LogicSheets need to know the namespace and uri of the markup language in order
        to replace expressions. Therefor AbstractMarkupLanguage needs to know this when
        reading logicsheets. This meant that I had to move this configuration
        information from parametrize to configure. It is unclear to me anyway, why
        AbstractMarkupLanguage used both methods at the same time (which are described
        as "incompatible" in the Avalon documentation).

        The old PreProcessFilter wraps text() nodes in <xsp:text> elements inside some
        tags (See [2]). It is unclear to me why this was done, and all XSPs I've tested
        worked without this. I got no reponse on the list, so I left this feature out of
        the new PreProcessFilter.

        If any of the above changes need further discussion, clarification or change,
        please tell me and I'll update the patch.

        This patch also should be applied to 2.2. If it does not work, again please tell
        me and I'll make a 2.2 patch available.

        [1] http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=111693513631888&w=2

        [2] http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=111778627925208&w=2
        In [1] in we discussed an XSP expression syntax for attribute value and text
        expressions. This patch makes expressions available.

        In XSP, you now can write:
        <elem attrib="{#expression}" which will be expanded to:
        <elem><xsp:attribute
        name="attrib"><xsp:expr>expression</xsp:expr><xsp:attribute></elem>
        or
        <elem>Hello #user.getFullName</elem>, which will be expanded to <elem>Hello
        <xsp:expr>user.getFullName</xsp:expr></elem>

        Writing {##text} will prevent expansion and will be replaced by the text
        "{#text}". Inside expressions, write "##" to get "#" and "#}" to get "}".

        This works in XSPs as well as logicsheets. The '#' was chosen out of the
        discussed characters because it is IMO least likely to occur in an expression in
        the used languages.

        This feature is turned on by default and can be turned off by setting
        "attribute-value-interpolation" or "text-interpolation" to "false" in cocon.xconf:

        <markup-languages>
            <xsp-language ... attribute-value-interpolation="false"
        text-interpolation="false">
                ...
            </xsp-language>
        </markup-language>

        It can be turned on or off on a per-XSP-/logicsheet-basis by setting attributes
        "attribute-value-interpolation" or "text-interpolation" of the top level element
        to true or false. Note that these attributes must belong to the
        "http://apache.org/xsp" namespace.

        How it works:

        New class XSPExpressionParser is a parser for the expressions. New class
        XSPExpressionFilter is a filter that gets SAX events with embedded expressions
        and generates SAX events for expanded expressions. This is used in LogicSheet to
        filter read logicsheers and in XSPMarkupLanguage to filter the XSP.

        Changes to existing code.

        LogicSheets need to know the namespace and uri of the markup language in order
        to replace expressions. Therefor AbstractMarkupLanguage needs to know this when
        reading logicsheets. This meant that I had to move this configuration
        information from parametrize to configure. It is unclear to me anyway, why
        AbstractMarkupLanguage used both methods at the same time (which are described
        as "incompatible" in the Avalon documentation).

        The old PreProcessFilter wraps text() nodes in <xsp:text> elements inside some
        tags (See [2]). It is unclear to me why this was done, and all XSPs I've tested
        worked without this. I got no reponse on the list, so I left this feature out of
        the new PreProcessFilter.

        If any of the above changes need further discussion, clarification or change,
        please tell me and I'll update the patch.

        This patch also should be applied to 2.2. If it does not work, again please tell
        me and I'll make a 2.2 patch available.

        [1] http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=111693513631888&w=2

        [2] http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=111778627925208&w=2
        Hide
        hepabolu@hotmail.com added a comment -
        reopened just to set the resolution to fixed
        Show
        hepabolu@hotmail.com added a comment - reopened just to set the resolution to fixed
        hepabolu@hotmail.com made changes -
        Status Closed [ 6 ] Reopened [ 4 ]
        hepabolu@hotmail.com made changes -
        Status Reopened [ 4 ] Closed [ 6 ]
        Resolution Fixed [ 1 ]
        Mark Thomas made changes -
        Assignee Cocoon Developers Team [ cocoon ]
        Transition Time In Source Status Execution Times Last Executer Last Execution Date
        Closed Closed Reopened Reopened
        141d 21h 20m 1 hepabolu@hotmail.com 26/Oct/05 00:08
        Reopened Reopened Closed Closed
        5s 1 hepabolu@hotmail.com 26/Oct/05 00:08

          People

          • Assignee:
            Unassigned
            Reporter:
            Jochen Kuhnle
          • Votes:
            1 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development