[
https://issues.apache.org/jira/browse/MYFACES-2667?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12862368#action_12862368
]
Jakob Korherr commented on MYFACES-2667:
----------------------------------------
Hi Martin,
OK cool, sounds like a very handy debug feature! I will start to work on a
better debug support for MyFaces soon :)
I assume you mean the .xhtml page each component comes from by "location of the
component", right? Nope - this info is not included at the moment.
Regards,
Jakob
> var values cause problems with ui:debug when creating the debug component tree
> ------------------------------------------------------------------------------
>
> Key: MYFACES-2667
> URL: https://issues.apache.org/jira/browse/MYFACES-2667
> Project: MyFaces Core
> Issue Type: Bug
> Affects Versions: 2.0.1-SNAPSHOT
> Reporter: Jakob Korherr
> Assignee: Jakob Korherr
> Fix For: 2.0.1-SNAPSHOT
>
>
> When using <ui:debug /> on a page, it creates a String version of the current
> component tree to show it in the debug output window (opens by hitting ctrl +
> shift + D in the browser).
> While creating this component tree, ui:debug wants to display every property
> of every component in the tree using the class' PropertyDescriptors. However
> there are some problems with this solution related to components that publish
> values in the RequestMap while the real tree is processed (rendered) like
> e.g. ui:repeat or h:dataTable (mostly those with a "var" attribute). Every
> child component of such a component, which refers to this value, will cause
> EL operations with invalid parameters (null or empty String) when its getters
> are called. See the related thread on the mailing list to this problem:
> http://www.mail-archive.com/[email protected]/msg55485.html
> In addition, properties with values of Collection, Map or Iterator are not
> included in the debug output, only those with "real" values (like true,
> false, 1234) are included. Also I don't think that it makes much sence to
> include all real values in the debug component tree, because what should we
> display for components that render their children a couple of times like
> h:dataTable? ...and depend on values of their parent which are published
> somewhere else?
> To visualize the problem a bit more, see the following facelet page:
> <ui:repeat var="master" value="#{myBean.masterList}">
> <h:dataTable var="detail" value="#{myBean.getDetailList(master)}">
> <h:column>
> <h:outputText value="#{detail}" />
> </h:column>
> </h:dataTable>
> </ui:repeat>
> The debug output for this one looks something like this:
> <UIRepeat id="j_id2114509110_7e08d943" inView="true" offset="0"
> rendered="true" size="-1" step="1" transient="false" var="master">
> <HtmlDataTable border="-2147483648" first="0"
> id="j_id2114509110_7e08d9b9" inView="true" rendered="true" rowIndex="-1"
> rows="0" transient="false" var="detail">
> <UIColumn id="j_id2114509110_7e08d99f" inView="true"
> rendered="true" transient="false">
> <HtmlOutputText escape="true" id="j_id2114509110_7e08d9f5"
> inView="true" rendered="true" transient="false"/>
> </UIColumn>
> </HtmlDataTable>
> </UIRepeat>
> I personally think that it would be much better not to evaluate the
> ValueExpressions, but to include the properties with the expression String in
> the component tree, like you see here:
> <UIRepeat id="j_id2114509110_7e08d943" inView="true" offset="0"
> rendered="true" size="-1" step="1" transient="false"
> value="#{myBean.masterList}" var="master">
> <HtmlDataTable border="-2147483648" first="0"
> id="j_id2114509110_7e08d9b9" inView="true" rendered="true" rowIndex="-1"
> rows="0" transient="false" value="#{myBean.getDetailList(master)}"
> var="detail">
> <UIColumn id="j_id2114509110_7e08d99f" inView="true"
> rendered="true" transient="false">
> <HtmlOutputText escape="true" id="j_id2114509110_7e08d9f5"
> inView="true" rendered="true" transient="false" value="#{detail}"/>
> </UIColumn>
> </HtmlDataTable>
> </UIRepeat>
> This will solve the problem the user has experienced and will also create a
> much better debug output.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
