MyFaces Core
  1. MyFaces Core
  2. MYFACES-2667

var values cause problems with ui:debug when creating the debug component tree

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 2.0.1-SNAPSHOT
    • Fix Version/s: 2.0.1
    • Component/s: None
    • Labels:
      None

      Description

      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/users@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.

        Activity

        Hide
        Martin Marinschek added a comment -

        Hi Jakob,

        yes, the location in the XHTML. Actually, from our discussion on the EG, we have stated that this location should be part of the information each component has (it comes from the tag field of a TagHandler in Facelets I think). I hope this has made it into the spec, if not, you will need to file a spec issue

        Emitting this information would be very valuable on the debug page.

        best regards,

        Martin

        Show
        Martin Marinschek added a comment - Hi Jakob, yes, the location in the XHTML. Actually, from our discussion on the EG, we have stated that this location should be part of the information each component has (it comes from the tag field of a TagHandler in Facelets I think). I hope this has made it into the spec, if not, you will need to file a spec issue Emitting this information would be very valuable on the debug page. best regards, Martin
        Hide
        Jakob Korherr added a comment -

        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

        Show
        Jakob Korherr added a comment - 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
        Hide
        Martin Marinschek added a comment -

        Hi Jakob,

        sure, that is a good idea!

        A feature which I would have wanted for a long time already would be the ability to concentrate on one component (like click on it on the debug page) and then being able to see how that component values changed over the lifecycle. That would help me a lot with debugging in cs-JSF. The location of the component (coming from the Facelet Tag Handler) is hopefully already included in the information shown?

        best regards,

        Martin

        Show
        Martin Marinschek added a comment - Hi Jakob, sure, that is a good idea! A feature which I would have wanted for a long time already would be the ability to concentrate on one component (like click on it on the debug page) and then being able to see how that component values changed over the lifecycle. That would help me a lot with debugging in cs-JSF. The location of the component (coming from the Facelet Tag Handler) is hopefully already included in the information shown? best regards, Martin
        Hide
        Jakob Korherr added a comment -

        created MYFACES-2676

        Show
        Jakob Korherr added a comment - created MYFACES-2676
        Hide
        Jakob Korherr added a comment -

        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

        Show
        Jakob Korherr added a comment - 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
        Hide
        Martin Marinschek added a comment -

        Hi Jakob,

        now that we have the tree-visiting in place, we can do both:

        • first write out the component-tree master, with only expressions in place
        • second we write out the tree how it is really evaluated by the components, with the real component values

        the more debugging information, the better!

        best regards,

        Martin

        Show
        Martin Marinschek added a comment - Hi Jakob, now that we have the tree-visiting in place, we can do both: first write out the component-tree master, with only expressions in place second we write out the tree how it is really evaluated by the components, with the real component values the more debugging information, the better! best regards, Martin

          People

          • Assignee:
            Jakob Korherr
            Reporter:
            Jakob Korherr
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development