[ https://issues.apache.org/jira/browse/MYFACES-2667?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12860999#action_12860999 ]
Jakob Korherr commented on MYFACES-2667: ---------------------------------------- Hi Martin, Very good idea :) Furthermore what do you think of only making <ui:debug /> work, if the ProjectStage is Development, because evaluating the whole tree another 2 times is really expensive and users may forget to remove it... Of course, a warning should be displayed if it is used when ProjectStage is not Development. 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/us...@myfaces.apache.org/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.