MyFaces Core
  1. MyFaces Core
  2. MYFACES-702

outputText generates wrapped span element in a portal

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 1.1.0
    • Fix Version/s: 1.1.2
    • Component/s: General
    • Labels:
      None

      Description

      We have a JSF app that runs as a portlet and normal webapp.

      In the webapp the <h:outputText value="some text"/> appears as I would expect (i.e. just the text) however the same thing in the portlet gets rendered as:

      <span id="form-id:handleMetaDataEvent_id36">some text</span>

      This becomes a problem when you are trying to use outputText to render part of a URL or to become a JavaScript string as the output includes the span element!

      Looking at the renderer code for outputText it appears the span gets generated when the id does not start with "_id", so the question is where has the "handleMetaDataEvent" prefix for the id come from?

      1. myfaces702.patch
        0.7 kB
        Henrik Bentel

        Activity

        Hide
        Greg Hester added a comment -

        We are having the same exact issue. Has anyone found a fix or workaround?

        Show
        Greg Hester added a comment - We are having the same exact issue. Has anyone found a fix or workaround?
        Hide
        Greg Hester added a comment -

        I re-read the initial comment and noticed the note about the id starting with "_id". I changed all of my <h:outputText> tags which are generating URLs to contain id attributes starting with "_id" and that fixed my problem. So, I have a workaround but don't think that the format of an id attribute value should have such an impact. I'll look at the source with my team to see if we can offer a suggestion for a fix.

        BTW: I would rather use <h:outputLink> but it seems to only allow absolute urls and I have relative urls. Have I missed the boat on this?

        Show
        Greg Hester added a comment - I re-read the initial comment and noticed the note about the id starting with "_id". I changed all of my <h:outputText> tags which are generating URLs to contain id attributes starting with "_id" and that fixed my problem. So, I have a workaround but don't think that the format of an id attribute value should have such an impact. I'll look at the source with my team to see if we can offer a suggestion for a fix. BTW: I would rather use <h:outputLink> but it seems to only allow absolute urls and I have relative urls. Have I missed the boat on this?
        Hide
        Martin Marinschek added a comment -

        Nothing in the MyFaces-implementation does this, as far as I can see.

        Hmm - I don't know much about the portlet integration, maybe Stan can say more?

        regards,

        Martin

        Show
        Martin Marinschek added a comment - Nothing in the MyFaces-implementation does this, as far as I can see. Hmm - I don't know much about the portlet integration, maybe Stan can say more? regards, Martin
        Hide
        Henrik Bentel added a comment -

        Hi

        I've just experienced the same issue with Liferay 3.6.1 and Myfaces 1.1.1.
        I've looked around in Liferay in the util-jsf library but couldn't find anything of significance.

        -Henrik

        Show
        Henrik Bentel added a comment - Hi I've just experienced the same issue with Liferay 3.6.1 and Myfaces 1.1.1. I've looked around in Liferay in the util-jsf library but couldn't find anything of significance. -Henrik
        Hide
        Henrik Bentel added a comment -

        I discovered one thing in my case.

        The Id's of all the components are "automagically" prefixed with the name of the portlet. So unless the ID is manually set, the ID's generated
        in my case look like this: "reportingid0","_reportingid1","_reporting_id2", where "reporting" is the name of the portlet.
        DOn't know what or who generates the IDs yet.

        In the case of verbatim tags there is no way of specifying an ID so span is injected regardless.

        -Henrik

        Show
        Henrik Bentel added a comment - I discovered one thing in my case. The Id's of all the components are "automagically" prefixed with the name of the portlet. So unless the ID is manually set, the ID's generated in my case look like this: " reporting id0","_reporting id1","_reporting _id2", where "reporting" is the name of the portlet. DOn't know what or who generates the IDs yet. In the case of verbatim tags there is no way of specifying an ID so span is injected regardless. -Henrik
        Hide
        Henrik Bentel added a comment -

        It seems when the components are created the createUniqueId method in UIViewRoot.java
        calls ExternalContext.encodeNamespace(...) method.
        The portlet implementation of the ExternalContext (PortletExternalContextImpl.java) returns
        "((RenderResponse)_portletResponse).getNamespace() + name" where name is passed in and looks like "_id0", "_id1", "_idx".

        The Servlet implementation just returns the passed in value.

        Myfaces's HtmlTextRendererBase.java seems to inject SPAN elements around all components that
        has an ID which does NOT start with "_id".

        -Henrik

        Show
        Henrik Bentel added a comment - It seems when the components are created the createUniqueId method in UIViewRoot.java calls ExternalContext.encodeNamespace(...) method. The portlet implementation of the ExternalContext (PortletExternalContextImpl.java) returns "((RenderResponse)_portletResponse).getNamespace() + name" where name is passed in and looks like "_id0", "_id1", "_idx". The Servlet implementation just returns the passed in value. Myfaces's HtmlTextRendererBase.java seems to inject SPAN elements around all components that has an ID which does NOT start with "_id". -Henrik
        Hide
        Henrik Bentel added a comment -

        One line fix to PortletExternalContextImpl.encodeNamespace.
        Thanks to Martin Marinschek for the best solution.

        Show
        Henrik Bentel added a comment - One line fix to PortletExternalContextImpl.encodeNamespace. Thanks to Martin Marinschek for the best solution.
        Hide
        Michael Freedman added a comment -

        Reopening because PORTLETBRIDGE-186 was filed. (https://issues.apache.org/jira/browse/PORTLETBRIDGE-186)

        I.e. The problem reported in MYFaces-702 was reopened against the bridge indicating that the 1.1 Bridge change/patch to work around this should be applied to the 1.2 bridge.

        I am not so sure. It appears that the real bug is that UIViewRoot.createUniqueId calls ExternalContext.encodeNamespace on the id before returning. It shouldn't make this call. Rather it should just return the uniqueId it generates. My guess is this was very old code that was added to deal with portlet/portal namespacing issues. However, the bridge now handles this more correctly by not impacting the component id – rather it introduces its own UIViewRoot that provides a NamingContainer which ensures all clientIds are namespaced via this externalcontext call.

        Is this correct, or is there some valid reason that createUniqueId calls encodeNamesapce?

        Show
        Michael Freedman added a comment - Reopening because PORTLETBRIDGE-186 was filed. ( https://issues.apache.org/jira/browse/PORTLETBRIDGE-186 ) I.e. The problem reported in MYFaces-702 was reopened against the bridge indicating that the 1.1 Bridge change/patch to work around this should be applied to the 1.2 bridge. I am not so sure. It appears that the real bug is that UIViewRoot.createUniqueId calls ExternalContext.encodeNamespace on the id before returning. It shouldn't make this call. Rather it should just return the uniqueId it generates. My guess is this was very old code that was added to deal with portlet/portal namespacing issues. However, the bridge now handles this more correctly by not impacting the component id – rather it introduces its own UIViewRoot that provides a NamingContainer which ensures all clientIds are namespaced via this externalcontext call. Is this correct, or is there some valid reason that createUniqueId calls encodeNamesapce?
        Hide
        Leonardo Uribe added a comment -

        I checked it and the code comes from other issue:

        https://issues.apache.org/jira/browse/MYFACES-454

        It is probably this is valid on 1.1.x branch (due to its inner portlet code).

        This was a hack that comes from pre portlet-bridge times (note in that time the solution for portlets was use myfaces and its custom generic portlet). In portlet-bridge, the portlet specific UIViewRoot implements NamingContainer, so its clientId is appended to all generated ids implicitly.

        You're right, Michael, this issue should be fixed on 1.2.x and 2.0.x branches (I think there are some code in tomahawk that requires it too). I'll close MYFACES-702 and MYFACES-454.

        Show
        Leonardo Uribe added a comment - I checked it and the code comes from other issue: https://issues.apache.org/jira/browse/MYFACES-454 It is probably this is valid on 1.1.x branch (due to its inner portlet code). This was a hack that comes from pre portlet-bridge times (note in that time the solution for portlets was use myfaces and its custom generic portlet). In portlet-bridge, the portlet specific UIViewRoot implements NamingContainer, so its clientId is appended to all generated ids implicitly. You're right, Michael, this issue should be fixed on 1.2.x and 2.0.x branches (I think there are some code in tomahawk that requires it too). I'll close MYFACES-702 and MYFACES-454 .
        Hide
        Krashan Brahmanjara added a comment -

        >this issue should be fixed on 1.2.x and 2.0.x branches
        So? Why you mark it as fixed without any changes.

        Some corporate portals still use jsf 1.1 and old portlet bridge so they can't upgrade theirs portals without this fix.

        Show
        Krashan Brahmanjara added a comment - >this issue should be fixed on 1.2.x and 2.0.x branches So? Why you mark it as fixed without any changes. Some corporate portals still use jsf 1.1 and old portlet bridge so they can't upgrade theirs portals without this fix.

          People

          • Assignee:
            Martin Marinschek
            Reporter:
            Gavin Cornwell
          • Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development