[
https://issues.apache.org/jira/browse/WICKET-3404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12991078#comment-12991078
]
Remus Pereni commented on WICKET-3404:
--------------------------------------
I would also appreciate improving the handling of the form tag inside the modal
window.
While I do understand the simplicity of having the form already defined, that
prevents the scenario in which you can have a tabbed interface inside of a
modal window, where in each tab you can have a form. In this scenario it is
impossible to make the form element the parent of the modal window with direct
result in having forms declared inside forms.
Having a form declared inside another form while incorrect according to
specifications works on almost every browser, with one little annoying
exception, IE7 and innerHTML manipulations of the DOM which results in
unexpected JavaScript errors. As a simple use case, having Visural Wicket Rich
Text editor component *uses Nickedit which usess innerHTML a lot) inside a
form from the Modal Window in IE7.
> Improve ModalWindow form handling
> ---------------------------------
>
> Key: WICKET-3404
> URL: https://issues.apache.org/jira/browse/WICKET-3404
> Project: Wicket
> Issue Type: Improvement
> Components: wicket-extensions
> Affects Versions: 1.5-RC1
> Reporter: Sven Meier
> Attachments: ModalWindow.patch
>
>
> Currently ModalWindow's javascript generates a generic <form> tag into the
> page.
> This is done to support nested forms while preventing temporary invalid HTML
> markup in the browser, i.e. a form nested in a another form.
> IMHO this is rather inelegant, which manifests itself in the following note
> in ModalWindow's javadoc:
> "If you want to use form in modal window component make sure that you put the
> modal window itself in another form (nesting forms is legal in Wicket) ..."
> I'm always having a hard time to explain this sentence to Wicket newcomers.
> My proposal: Let go of the <form> tag in javascript with the attached patch!
> The changed code now adds ModalWindow's markup first into the HTML page and
> then replaces its content *directly* with the component's markup to show in
> the modal window (the current implementation does it the other way around).
> The proposed change would require a migration effort for some usages of
> ModalWindow though. Forms inside a ModalWindow inside another form have to be
> 'made root forms', either by overriding isRootForm() and getRootForm() or
> perhaps we could introduce a new interface (e.g. IFormSeparator) which
> signals to a form that its containment in another form doesn't make it a
> nested form.
> Note that this issue is not about esthetics only, we have reocurring usecases
> in our projects (a form inside a modal window inside another *multipart*
> form) which require quirks to make it work. I can provide more information on
> this if required.
> Further note that even standard form submits are now possible on ModalWindows
> too (might be interesting for multipart uploads directly initiated from a
> ModalWindow's form).
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
