[
https://issues.apache.org/jira/browse/WICKET-4413?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13211913#comment-13211913
]
Tomas Bilka commented on WICKET-4413:
-------------------------------------
I dont want to confuse this more then necessary, but one more comment to this.
If the component is having a permanently visible mutlipart component as part of
its outer form then i think the problem does not exist
(at least the "...Wicket tries its best to auto-detect multipart..." exception
will be gone), since the page will be marked alwasy as mutliPart
Problem is when there is no multipart component in the outer form and there is
a multipart component as part of some other, potentitally
non visible, component (like modal window).
In that case i would just override the isMultiPart as Martin suggested (and by
overriding i mean some "simple" override not needing to preserve
component scan).
Only problem I see is when in the future someone decides to add a mutlipart
component to the outer form. Then the overriden isMultiPart method
would need to be removed to re-enable component scan.
> Form.setMultiPart(false) does not set the multiPart field to 0
> --------------------------------------------------------------
>
> Key: WICKET-4413
> URL: https://issues.apache.org/jira/browse/WICKET-4413
> Project: Wicket
> Issue Type: Bug
> Components: wicket
> Affects Versions: 1.5.3
> Environment: Windows 7 (64 bit), Intel i3 platform
> Reporter: Tomas Bilka
> Original Estimate: 168h
> Remaining Estimate: 168h
>
> My expectation is that by calling setMutliPart(false) the mutliPart field in
> Form component should be set to 0.
> This line of code from org.apache.wicket.markup.html.form.Form<T>: multiPart
> &= ~MULTIPART_HARD; is probably trying to reset the multiPart to 0 (this is
> how i understand it), but it fails to do so since
> ~MULTIPART_HARD == 11111111111111111111111111111110 (initial value of
> MULTIPART_HARD is 1 or 0000000000000000000000000000001 in binary)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
