Modal dialog windows have become pretty commonplace on the web these days, ranging from simple alerts to confirmation alerts to full embedded forms. There are a myriad of javascript libraries available for generating modal dialogs (jQueryUi, bootstrap, thickbox, fancybox, prototype window, simple modal, modalbox, jqModal, Livepipe UI, Lightboxwindow, Submodal, Wingo, Highslide, Greybox, …need I go on?), but it’s still up to the developer to handle how to postback data from these dialogs. For being such a common web element, doing so can be surprisingly tricky at times. There are several different methodologies, and I’ll reserve judgement of which choice is best for your application. There seems to be a time and place for each of these methods, and there are probably a lot more. These are a few that I’ve come across most frequently, with a comparison of the pros and cons of each.
For the purpose of this exercise, we’ll assume we have a parent window that is a dashboard page of sorts. It has a list of objects that displays various information about the object, along with an edit button. The edit button should popup a modal dialog that contains a form allowing the user alter and save the object, triggering the parent window to update the newly edited information about the object.
So let’s begin…
XHttpRequest + json
This is generally thought of as the cleanest and lightest approach, and is used most often these days. The form submit method will be bound, and trigger an XHttpRequest containing the post data. Simple forms might package the post data manually, or there may be an automated way to serialize the data from the form. The data is posted to an api method that exclusively generates a json response, allowing the javascript method to handle both the success and error cases. Generally, on success, a refresh is triggered in the parent page.
Pros: api calls more accessible, callable from any page, consistent response, lightweight
Cons: Requires an api, or at least a controller method that generates a json response. A separate controller is required to render the form, can be more complicated, requires 2 server roundtrips in order to update the data and refresh the parent, unless you add some javascript to update the parent view based on the new data.
Post form in parent
The parent page will container a form with a hidden action input element. The dialog form submit method will be bound to populate that input with a unique action key corresponding to the specific action being performed in the dialog. The form elements in the dialog will be serialized or copied into the parent window (or if the dialog is simply inline html, the form is simply submitted as usual). On the server, the postback controller will lookup the action parameter, and perform the required action. If successful, the parent page will continue to be re-rendered, showing the newly updated information.
Pros: Reduces callback and refresh to a single call
Cons: complicated, ties modal forms to parent page, less accessible, difficult to handle form errors
* One note, when using this method, I would never handle the action directly in the postback controller. It’s better to create an action handler class that can be included and instantiated from the postback controller. This can help decouple the modal forms from the parent page, breaking the interdependence between the parent page and the modal dialog.
form.serialize() to post
This is somewhat of a hybrid between the XHttpRequest+json and a standard non-async form postback. The thought is to code the controller as if it were a regular round-trip server form, and use a javascript plugin to automatically bind to the form, serialize the data, and post the data to the controller via an XHttpRequest. Whatever HTML the server sends back is used to replace the current dialog content, which allows for easy server-side handling of form errors. The one exception is when handling the success case, where the dialog should be closed and trigger a refresh in the parent. This generally requires some special handling, which adds a slight amount of complexity.
Pros: Reduces complexity in form posting. Turns regular form into a ajax form without much fuss, incapsulates mvc into tight package specific to functionality
Cons: Clutters controller code by changing return type depending on whether successful or not.
iframe
This method invokes a lot of negative emotion in programmers, often causing arguments that degrade to personal assaults on the core quality of an individual, rather than their coding preference. It’s true that this method is often abused, and can be a lazy approach that becomes a substitute for a well thought-out one. But there are certain cases when an iframe makes sense, especially when content from other sites are involved. Generally speaking, if we have full control of the server code and it’s interaction with the front-end, this approach is a bit heavyweight and resource intensive. The thought is to simply wrap the dialog content in an iframe, isolating it’s interaction from the parent page and making standard form posts affect only the content in the iframe. It’s generally a pretty simple approach, but does incur a lot of overhead. For practical purposes, I only use this method when I have an legacy popup that handles it’s own postback, and we have no time or budget to modernize and convert it to one of the methods above.
Pros: simple – just wrap dialog contents in an iframe.
Cons: easy to abuse, communication between parent window can be tricky, so getting the dialog to close can be problematic, Subject to browser quirks and security issues, heavyweight
