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
Pros: api calls more accessible, callable from any page, consistent response, lightweight
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
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.
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