MyFaces Core
  1. MyFaces Core
  2. MYFACES-2624

Automatically add h:messages if ProjectStage is Development

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 2.0.0-beta-3
    • Fix Version/s: 2.0.0
    • Component/s: JSR-314
    • Labels:
      None

      Description

      If ProjectStage is Development and there is no h:messages component on the current view we should automatically add h:messages to the component tree, because many users often forget about adding this useful (debug) component and wonder why their actions are never called.

      This is also an official JSF 2.0 spec requirement, however I couldn't find it in the spec-pdf or in the javadoc, but in the spec issue tracker [1] and on several blogs like Ryan Lubke's Blog [2]. Furthermore Mojarra also does it.

      [1] https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=314
      [2] http://blogs.sun.com/rlubke/entry/jsf_2_0_new_feature2

        Issue Links

          Activity

          Hide
          Martin Marinschek added a comment -

          Hi Jakob,

          can you please open a spec issue (against the missing documentation)?

          thanks a lot,

          regards,

          Martin

          Show
          Martin Marinschek added a comment - Hi Jakob, can you please open a spec issue (against the missing documentation)? thanks a lot, regards, Martin
          Hide
          Jakob Korherr added a comment -

          Actually I was going to do that today, but anyway thanks for the reminder, Martin

          Posted spec issue #778: https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=778

          Show
          Jakob Korherr added a comment - Actually I was going to do that today, but anyway thanks for the reminder, Martin Posted spec issue #778: https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=778
          Hide
          Jakob Korherr added a comment -

          After digging into to issue, I have to say I am a little confused. The spec issue #314 says to automatically add a h:messages as the last child of every UIForm if there is no UIMessages in the view.

          However there are some problems with this approach. At first the presence of an UIMessages does not mean that every FacesMessage is really displayed (e.g. if the attribute for is set). Furthermore we would have to traverse the whole tree to find out if there really are UIMessages or not, because we can't rely on our facelet handlers or JSP tag handlers to find out if there is an h:messages component, because the user might use a custom messages component (like e.g. the one from tomahawk).

          The easiest way to determine if every FacesMessage really has been rendered is to check FacesMessage.isRendered() on every FacesMessage, but we can only check this after the rendering has happened and thus we won't be able to add the h:messages component any more.

          Using <ui:debug /> on Mojarra to see how it deals with this scenario I found out that it does not add an UIMessages component at all. It seems to hook into the rendering phase before the body tag is closed (and not at the end of every form like the spec issue says) and to just add the HTML from the h:messages renderer to the output without adding the component itself to the tree. Thus, Mojarra does not change the component tree at all, which is kinda nice!

          I will try some things out to find the best fitting solution to this problem. Suggestions are always welcome!!

          Show
          Jakob Korherr added a comment - After digging into to issue, I have to say I am a little confused. The spec issue #314 says to automatically add a h:messages as the last child of every UIForm if there is no UIMessages in the view. However there are some problems with this approach. At first the presence of an UIMessages does not mean that every FacesMessage is really displayed (e.g. if the attribute for is set). Furthermore we would have to traverse the whole tree to find out if there really are UIMessages or not, because we can't rely on our facelet handlers or JSP tag handlers to find out if there is an h:messages component, because the user might use a custom messages component (like e.g. the one from tomahawk). The easiest way to determine if every FacesMessage really has been rendered is to check FacesMessage.isRendered() on every FacesMessage, but we can only check this after the rendering has happened and thus we won't be able to add the h:messages component any more. Using <ui:debug /> on Mojarra to see how it deals with this scenario I found out that it does not add an UIMessages component at all. It seems to hook into the rendering phase before the body tag is closed (and not at the end of every form like the spec issue says) and to just add the HTML from the h:messages renderer to the output without adding the component itself to the tree. Thus, Mojarra does not change the component tree at all, which is kinda nice! I will try some things out to find the best fitting solution to this problem. Suggestions are always welcome!!
          Hide
          Jakob Korherr added a comment -

          This patch (MYFACES-2624-add-UIMessages-to-UIForm.patch) includes the proposal from the spec issue - if ProjectStage is Development it traverses the tree and adds UIMessages as the last child of every UIForm.

          The reason why I use visitTree() here is because the user might use different ViewHandler implementations (e.g. facelets-1.x) and so I can't really hook into our ViewHandler impls. Furthermore I can't really hook into our UIForm impl, because the user might use other UIForm impls (e.g. from tomahawk).

          Frankly, I don't really like this solution, because there are some problems with it (e.g. why have one UIMessages at the end of every UIForm? or: Is UIForm really the best place to put it?), but I wanted to provide a patch for it.

          For now I think it is the best to do what Mojarra currently does, even though the solution does only work when using the built-in facelets VDL. Hopefully the EG will address this issue soon and tell us what to do.

          Show
          Jakob Korherr added a comment - This patch ( MYFACES-2624 -add-UIMessages-to-UIForm.patch) includes the proposal from the spec issue - if ProjectStage is Development it traverses the tree and adds UIMessages as the last child of every UIForm. The reason why I use visitTree() here is because the user might use different ViewHandler implementations (e.g. facelets-1.x) and so I can't really hook into our ViewHandler impls. Furthermore I can't really hook into our UIForm impl, because the user might use other UIForm impls (e.g. from tomahawk). Frankly, I don't really like this solution, because there are some problems with it (e.g. why have one UIMessages at the end of every UIForm? or: Is UIForm really the best place to put it?), but I wanted to provide a patch for it. For now I think it is the best to do what Mojarra currently does, even though the solution does only work when using the built-in facelets VDL. Hopefully the EG will address this issue soon and tell us what to do.
          Hide
          Jakob Korherr added a comment -

          The code committet works for the built-in facelets VDL when using <h:body> or just <body> in the view. This is exactly the way Mojarra deals with the problem (known from debugging).

          I also found out that Mojarra adds a log message with all the unhandled FacesMessages when ProjectStage is Production, which is also kinda nice. I think we should do that too!

          Show
          Jakob Korherr added a comment - The code committet works for the built-in facelets VDL when using <h:body> or just <body> in the view. This is exactly the way Mojarra deals with the problem (known from debugging). I also found out that Mojarra adds a log message with all the unhandled FacesMessages when ProjectStage is Production, which is also kinda nice. I think we should do that too!
          Hide
          Jakob Korherr added a comment -

          As long as the EG does not change anything about this when adding it to the spec, this is fixed.

          Show
          Jakob Korherr added a comment - As long as the EG does not change anything about this when adding it to the spec, this is fixed.

            People

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

              Dates

              • Created:
                Updated:
                Resolved:

                Development