[
https://issues.apache.org/jira/browse/MYFACES-702?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Freedman reopened MYFACES-702:
--------------------------------------
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?
> outputText generates wrapped span element in a portal
> -----------------------------------------------------
>
> Key: MYFACES-702
> URL: https://issues.apache.org/jira/browse/MYFACES-702
> Project: MyFaces Core
> Issue Type: Bug
> Components: General
> Affects Versions: 1.1.0
> Reporter: Gavin Cornwell
> Assignee: Martin Marinschek
> Fix For: 1.1.2
>
> Attachments: myfaces702.patch
>
>
> 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?
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
