Tapestry
  1. Tapestry
  2. TAPESTRY-1131

Hidden Component (maybe all FormComonents?) don't get ids assigned on a page basis.

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 4.1.1
    • Fix Version/s: 4.1.1
    • Component/s: tapestry-core
    • Labels:
      None

      Description

      1. create a component with a form containing a hidden field
      2. instantiate this component twice on the same page
      3. look at generated source.

      notice that both hidden fields have the same id. This screws up javascript trying to use javascript functions to get the unique hidden field.

        Activity

        Patrick Moore created issue -
        Hide
        Andreas Andreou added a comment -

        Yep, this indeed happens...

        In tacos this was fixed by introducing a parameter in AjaxForm
        that would make name and id generation depend on component's idPath (instead of id)
        Here's the changeset: http://fisheye3.cenqua.com/changelog/tacos?cs=348

        I'm thinking of a less intrusive solution for Tapestry...
        Perhaps in formSupport.getElementId...

        Show
        Andreas Andreou added a comment - Yep, this indeed happens... In tacos this was fixed by introducing a parameter in AjaxForm that would make name and id generation depend on component's idPath (instead of id) Here's the changeset: http://fisheye3.cenqua.com/changelog/tacos?cs=348 I'm thinking of a less intrusive solution for Tapestry... Perhaps in formSupport.getElementId...
        Andreas Andreou made changes -
        Field Original Value New Value
        Assignee Andreas Andreou [ andyhot ]
        Hide
        Andreas Andreou added a comment -

        A recent step forwards (i hope) has been the
        org.apache.tapestry.form.FormSupportFactory interface that is now responsible
        for generating FormSupport implementations.

        This has allowed me to try alternative implementations, one being MultipleFormSupport
        which works by prefixing all form elements with the form's clientId (on render and then
        again on rewind)

        Here's how this would then be configured - overriden

        <implementation service-id="tapestry.form.FormSupportFactory">
        <create-instance class="org.apache.tapestry.form.MultipleFormSupportFactory"/>
        </implementation>

        I'm missing a few unit tests before committing

        Show
        Andreas Andreou added a comment - A recent step forwards (i hope) has been the org.apache.tapestry.form.FormSupportFactory interface that is now responsible for generating FormSupport implementations. This has allowed me to try alternative implementations, one being MultipleFormSupport which works by prefixing all form elements with the form's clientId (on render and then again on rewind) Here's how this would then be configured - overriden <implementation service-id="tapestry.form.FormSupportFactory"> <create-instance class="org.apache.tapestry.form.MultipleFormSupportFactory"/> </implementation> I'm missing a few unit tests before committing
        Hide
        Andreas Andreou added a comment -

        BTW, the 'new' MultipleFormSupport is an ugly copy-paste of 'FormSupportImpl' mostly due to
        the fact that _cycle is private in FormSupportImpl

        Making it protected saves more that 750 lines... the other solution is for the subclass to also keep
        a copy of that field, when it's passed in the contructor - still ugly!

        Show
        Andreas Andreou added a comment - BTW, the 'new' MultipleFormSupport is an ugly copy-paste of 'FormSupportImpl' mostly due to the fact that _cycle is private in FormSupportImpl Making it protected saves more that 750 lines... the other solution is for the subclass to also keep a copy of that field, when it's passed in the contructor - still ugly!
        Hide
        Jesse Kuhnert added a comment -

        You do have commit access, so if making _cycle non private solves the problem then I'd just change it.

        p.s. If MultiFormSupport does work out it seems more logical to just make that the default behavior in FormSupportImpl doesn't it?

        Show
        Jesse Kuhnert added a comment - You do have commit access, so if making _cycle non private solves the problem then I'd just change it. p.s. If MultiFormSupport does work out it seems more logical to just make that the default behavior in FormSupportImpl doesn't it?
        Andreas Andreou made changes -
        Status Open [ 1 ] In Progress [ 3 ]
        Andreas Andreou made changes -
        Fix Version/s 4.1.1 [ 12312021 ]
        Hide
        Jesse Kuhnert added a comment -

        I'm assuming that this has been fixed already but not closed?

        Show
        Jesse Kuhnert added a comment - I'm assuming that this has been fixed already but not closed?
        Jesse Kuhnert made changes -
        Resolution Fixed [ 1 ]
        Status In Progress [ 3 ] Resolved [ 5 ]
        Hide
        Andreas Andreou added a comment -

        This works great for me, but it has demonstrated another issue when some Tapestry's script files try to
        use the clientId in order to create javascript identifiers for variables.

        I'll open a new issue describing this.

        Show
        Andreas Andreou added a comment - This works great for me, but it has demonstrated another issue when some Tapestry's script files try to use the clientId in order to create javascript identifiers for variables. I'll open a new issue describing this.
        Mark Thomas made changes -
        Workflow jira [ 12388024 ] Default workflow, editable Closed status [ 12567938 ]
        Mark Thomas made changes -
        Workflow Default workflow, editable Closed status [ 12567938 ] jira [ 12591820 ]
        Transition Time In Source Status Execution Times Last Executer Last Execution Date
        Open Open In Progress In Progress
        27d 22h 7m 1 Andreas Andreou 27/Nov/06 02:09
        In Progress In Progress Resolved Resolved
        14d 17h 27m 1 Jesse Kuhnert 11/Dec/06 19:36

          People

          • Assignee:
            Andreas Andreou
            Reporter:
            Patrick Moore
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development