Tapestry 5
  1. Tapestry 5
  2. TAP5-649

Forms containing loop components which contain no form elements still encode into t:formdata hidden field

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 5.1.0.0, 5.1.0.1, 5.1.0.2, 5.1.0.3, 5.0.18
    • Fix Version/s: 5.1.0.4
    • Component/s: tapestry-core
    • Labels:
      None

      Description

      Updating our app to 5.1 has caused us an issue with using loop components nested inside form components, we now need to provide a ValueEncoder whereas we didn't in 5.0.18 which just serialised the loop values into t:formdata. In many cases we have loops that don't have any input or form elements inside them, but that still need to be contained by the form tag in the HTML. The issue is that the loop component has a 'volatile' parameter to switch off the state saving, but this expects the iterator to still be available when the form is submitted, which it isn't and doesn't need to be.

      I think that the loop component needs the facility to be form agnostic, so that FormSupport (from the environment) is ignored / not set. My suggestion is that the volatile parameter is deprecated (can't remove for backwards compatability) and a new parameter 'formHandling' or 'formSupport' is added to the loop component which accepts three values: none, statesave, volatile. I think that this would be much clearer and concise than the current volatile boolean, which confuses everyone in my experience, but alternatively a new boolean for switching off form support would suffice.

        Activity

        Hide
        Andy Blower added a comment -

        I should have mentioned that we have worked around this temporarily to prove that our theory was correct by creating and using a UselessEncoder class with relevant loops in forms. This encoder simply returns a blank string and cut down the t:formdata in one of our forms from 9076 bytes to a mere 832 bytes!

        Since none of this extra information will ever be used, this shows how much of a wasteful overhead this can be. It would be especially bad for us because we log all activity on the website including posted form submissions. I'm glad that this exception was thrown by 5.1 and highlighted the issue.

        Show
        Andy Blower added a comment - I should have mentioned that we have worked around this temporarily to prove that our theory was correct by creating and using a UselessEncoder class with relevant loops in forms. This encoder simply returns a blank string and cut down the t:formdata in one of our forms from 9076 bytes to a mere 832 bytes! Since none of this extra information will ever be used, this shows how much of a wasteful overhead this can be. It would be especially bad for us because we log all activity on the website including posted form submissions. I'm glad that this exception was thrown by 5.1 and highlighted the issue.

          People

          • Assignee:
            Howard M. Lewis Ship
            Reporter:
            Andy Blower
          • Votes:
            1 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development