ICEfaces
  1. ICEfaces
  2. ICE-329

Components must be contained within a form

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Minor Minor
    • Resolution: Invalid
    • Affects Version/s: 1.5
    • Fix Version/s: 2.0-Beta2
    • Component/s: ICE-Components
    • Labels:
      None
    • Environment:
      Operating System: All
      Platform: All

      Description

      If you have a page with components bound to backing beans and you want to update
      those via server-side render calls, it seems that the components MUST be
      contained with a form for the render calls to actually facilitate an update in
      the browser. Without a containing form, the page does not seem to update.

      I'm not sure what the inherent issues might be in implementing or changing this
      behaviour but it probably should at least be documented somewhere once we
      understand the exact parameters of the behaviour.

        Issue Links

          Activity

          Hide
          Deryk Sinotte added a comment -

          A test case has been checked into the repository

          repo/support/iraptor/1000/332

          Show
          Deryk Sinotte added a comment - A test case has been checked into the repository repo/support/iraptor/1000/332
          Hide
          Chris Brown added a comment -

          Further analysis is required on this. I have a hunch that the form in this case
          could be replaced by any component tag (that supports children) or html tag
          (that supports children). But that's just a comment on the work-around and I
          don't think we've made it close to the solution or even the real problem.

          I think the problem is:

          h:outputText instances are rendered as text nodes, text nodes do not support ids
          when there is no surrounding naming container, there is no id on the h:outputText
          the update is being sent to the browser, in this case it should be a "body swap"
          the bridge is failing to apply the change for some reason

          I think our first step is to verify that the domupdate is being sent to the
          browser, and is a body swap.

          Show
          Chris Brown added a comment - Further analysis is required on this. I have a hunch that the form in this case could be replaced by any component tag (that supports children) or html tag (that supports children). But that's just a comment on the work-around and I don't think we've made it close to the solution or even the real problem. I think the problem is: h:outputText instances are rendered as text nodes, text nodes do not support ids when there is no surrounding naming container, there is no id on the h:outputText the update is being sent to the browser, in this case it should be a "body swap" the bridge is failing to apply the change for some reason I think our first step is to verify that the domupdate is being sent to the browser, and is a body swap.
          Hide
          Adnan Durrani added a comment -

          I guess, the following tastcase is not checked in to the repository:
          repo/support/iraptor/1000/332

          Show
          Adnan Durrani added a comment - I guess, the following tastcase is not checked in to the repository: repo/support/iraptor/1000/332
          Hide
          Adnan Durrani added a comment -

          tastcase=testcase

          Show
          Adnan Durrani added a comment - tastcase=testcase
          Hide
          Adnan Durrani added a comment -

          I ran the testcase, and I identified that ICEFaces properly pushing the data
          to the client whether form has been used or not, and sending proper DOM
          updates, but browser does not seem to be applying it. The following DOM update
          being sent by the ICEFaces, when no form is used in the JSF page.

          1 ^<P id="icesoftXhtmlID12">Wed Mar 15 09:50:59 MST 2006<br></P>
          1 ^<P id="icesoftXhtmlID12">Wed Mar 15 09:51:00 MST 2006<br></P>
          1 ^<P id="icesoftXhtmlID12">Wed Mar 15 09:51:01 MST 2006<br></P>
          1 ^<P id="icesoftXhtmlID12">Wed Mar 15 09:51:02 MST 2006<br></P>

          So I am assining this bug to Mircea.

          Show
          Adnan Durrani added a comment - I ran the testcase, and I identified that ICEFaces properly pushing the data to the client whether form has been used or not, and sending proper DOM updates, but browser does not seem to be applying it. The following DOM update being sent by the ICEFaces, when no form is used in the JSF page. 1 ^<P id="icesoftXhtmlID12">Wed Mar 15 09:50:59 MST 2006<br></P> 1 ^<P id="icesoftXhtmlID12">Wed Mar 15 09:51:00 MST 2006<br></P> 1 ^<P id="icesoftXhtmlID12">Wed Mar 15 09:51:01 MST 2006<br></P> 1 ^<P id="icesoftXhtmlID12">Wed Mar 15 09:51:02 MST 2006<br></P> So I am assining this bug to Mircea.
          Hide
          Mircea Toma added a comment -

          Right now ICEFaces relies on the presence of forms in JSF templates.

          Show
          Mircea Toma added a comment - Right now ICEFaces relies on the presence of forms in JSF templates.
          Hide
          Steve Maryka added a comment -

          Add to known issues.

          Show
          Steve Maryka added a comment - Add to known issues.
          Hide
          Ken Fyten added a comment -

          Assign to Mircea, target v1.1. This seems like a duplicate of 454 to me.

          Show
          Ken Fyten added a comment - Assign to Mircea, target v1.1. This seems like a duplicate of 454 to me.
          Hide
          Ken Fyten added a comment -

          Lower priority, out of scope for v1.1. release.

          Show
          Ken Fyten added a comment - Lower priority, out of scope for v1.1. release.
          Hide
          Ken Fyten added a comment -

          JSF Standard Behavior:

          1. All JavaServer Faces pages are represented by a tree of components, called a view. The view tag represents the root of the view.
          2. All JavaServer Faces component tags must be inside of a view tag, which is defined in the core tag library.
          3. The form tag represents an input form component, which allows the user to input some data and submit it to the server, usually by clicking a button. 4. All UI component tags that represent editable components (such as text fields and menus) must be nested inside the form tag.

          So, 1st question, do ICEfaces 2.0 components conform to the above spec., or do all ICEfaces comps. need to be in a form regardless?
          2nd question is what happens with none-editable components such as tabSet, that do have a selectedIndex value?

          Show
          Ken Fyten added a comment - JSF Standard Behavior: 1. All JavaServer Faces pages are represented by a tree of components, called a view. The view tag represents the root of the view. 2. All JavaServer Faces component tags must be inside of a view tag, which is defined in the core tag library. 3. The form tag represents an input form component, which allows the user to input some data and submit it to the server, usually by clicking a button. 4. All UI component tags that represent editable components (such as text fields and menus) must be nested inside the form tag. So, 1st question, do ICEfaces 2.0 components conform to the above spec., or do all ICEfaces comps. need to be in a form regardless? 2nd question is what happens with none-editable components such as tabSet, that do have a selectedIndex value?
          Hide
          Ken Fyten added a comment -

          The limitations outlined above (input and action components must be included in a form) are recognized as standard within JSF. As such, ICEfaces complies with this standard.

          Show
          Ken Fyten added a comment - The limitations outlined above (input and action components must be included in a form) are recognized as standard within JSF. As such, ICEfaces complies with this standard.

            People

            • Assignee:
              Unassigned
              Reporter:
              Deryk Sinotte
            • Votes:
              1 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: