By now, the Drupal contributed repository grew so big that there are likely multiple solutions to the same problems there. Maybe these solutions solve the tasks with different angles, have slightly different features, but at their core, they aim at solving the same issue. So it is getting harder for site builders to pick the modules they want to use (and drupal.org is planned to offer more tools in helping with the selection). When it comes to core inclusion though, one needs to very clearly define the requirements and meet core goals, such as lean and mean implementation, maintainability and reusability.
With Mark Boulton's and Leisa Reichelt's suggestion to have most of the Drupal administration interface show up in an overlay on top of the public facing webpage, we are again at such technology crossroads. Drupal 6 at least has two contributed modules to implement a similar-looking solution: Popups API and Modal Frame API. Both got their pros when I researched for possible overlay implementations, and frankly, when there are already two modules implemented for the same complex task, why would we start from scratch?
The goals for the core overlay (purposely not called a modal dialog) is to take up most of the window with a dim background on the original page content. The overlay would have a close button on its right side and possibly tabs on top to switch to different subpages (loaded via Ajax or will already be on the same page, but hidden). We don't need the overlay to be moveable or resizable. We don't need to show multiples at once, since it only makes sense to show one. However, the overlay should work well with the header so that when an option is selected, it keeps being active in the header, and the header should work so one can pick another area to work on without first closing the overlay.
This is how the overlay would look:
With different tabs or without tabs but otherwise consistent look elsewhere:
For easier evaluation of how we can meet these goals, I've ported both above mentioned modules to Drupal 7 and implemented Drupal 7 user experience "skins" for them. In the case of Popups module, it was a skin which the module already supports via an internal API, with Modal Frame API, it was an actual glue module which mapped elements marked up for being displayed in the overlay to a style similar to what Mark and Leisa suggests. Neither of them is pixel perfect to what is to be done, but the initial goal was to have D7 versions to evaluate and discuss the implementation internals, so we can fix up styling once we picked either one or a third way.
You can find my Popups module port patch at http://drupal.org/node/466732#comment-1681554 and the Modal Frame API port patch at http://drupal.org/node/491224#comment-1703366 but to make all these easier to test with the D7UX header in progress, all this code is available with the glue modules and custom skins in the D7UX code repository. You can try out both by installing with the d7ux install profile and then either turning on the "Popups API" module or the "D7UX overlay look" module. Make sure to only have one of them enabled at once and let Drupal install their dependencies. Switch between the two implementations by switching between the two modules.
Overlay implemented via popus module:
Overlay implemented via modal frame API module (the close button is not yet themed to look like on the mockups, but think of that as a minor detail):
Let's go beyond the UI and compare the modules:
| |
Popups API |
Modal Frame API |
| Started |
December 2007 |
May 2009 |
| Maintainer |
starbow: http://drupal.org/user/33290 |
markus_petrux: http://drupal.org/user/39593 |
| Contents |
Popups API, popups admin (admin mapper) and popups test modules (for human testing), skins |
Modal Frame API, Example glue module for testing |
| Based on |
Lots of custom code based on jQuery |
Small amount of custom code based on jQuery UI and jQuery |
| Codebase |
Light on PHP code, heavy on JS |
Light on both PHP and JS code, jQuery UI makes up for it |
| Overlay rendering |
Ajax request for a JSON object which contains the rendered content of the page, JS and CSS files to be loaded for the page and Drupal messages |
Ajax request for a fully rendered HTML page which is themed by the Modal Frame API module to only include the main region and some wrapper code. |
| Overlay display |
Merges rendered overlay into main HTML document; merges in CSS and JS files (possible ID collision) |
iframe element added to the page (no requirement for CSS and JS merging) |
| Stacked popups |
Supported, only one visible at a time |
Not supported |
| Dirty forms (unsaved edited form warnings) support |
Supported via custom code |
Supported via http://drupal.org/project/dirtyforms |
| Form submission in popups |
Reloads originating page (via Ajax or full reload) or runs custom callback |
Overrides form submit redirection and closes overlay |
We are obviously at crossroads with picking our ways. The Popups module approach already has numerous core patches which were suggested earlier, while Modal Frame API leverages jQuery UI to lessen custom code burden and iframes to avoid colissions in merging HTML documents, which might be more attractive.
What did I miss in my comparison? Did I miss another alternative? What do you think a core solution should look like? jQuery UI to core? Just a targeted custom implementation for our own needs? IFrames or HTML merging? JSON output or overlay specific theming? These are general conceptual questions, so I choose to write a blog post to try and start a conversation instead of using the issue queue, which would be useful for more targeted questions. However, answers to some of the questions infer answers to others. What do you think?
