[
https://issues.apache.org/jira/browse/TAP5-649?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12699738#action_12699738
]
Andy Blower commented on TAP5-649:
----------------------------------
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.
> Forms containing loop components which contain no form elements still encode
> into t:formdata hidden field
> ---------------------------------------------------------------------------------------------------------
>
> Key: TAP5-649
> URL: https://issues.apache.org/jira/browse/TAP5-649
> Project: Tapestry 5
> Issue Type: Bug
> Components: tapestry-core
> Affects Versions: 5.1.0.0, 5.1.0.1, 5.1.0.2, 5.1.0.3, 5.0.18
> Reporter: Andy Blower
>
> 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.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
