Posted by LPCA on October 15, 2010 at 12:33am
9 followers
Jump to:
| Project: | Modal Frame API |
| Version: | 7.x-1.x-dev |
| Component: | Code |
| Category: | task |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | closed (duplicate) |
Issue Summary
Hey
suggestion:
since D7 core has taken in Chaos Tools Modal Dialog API and AJAX responder, why not convert the module to use those APIs?
Modalframe would essentially turn into a contrib module that extends Dialogs, as it does, to multiple uses, but using the built-in API.
Could also be backported to the 6.x branch, by making use of the standard ctools 6.x version.
IDK if that is doable, or even worth doing, or if Modalframe is still useful in D7 or not, but it's a suggestion anyways.
Comments
#1
One of the ideas behind Modal Frame API was to provide an extension to the jQuery UI Dialog plugin to make it work well with iFrames.
jQuery UI Dialog is also part of D7, so I do not see the need to depend on anything other than that. The question, IMO, is to see if the implementation of the Overlay module in D7 is able to cover all the needs that Modal Frame API covers. If that is not the case, we can work to make than happen, or we can port Modal Frame API to D7.
To see if the Overlay module in D7 covers all the needs, someone needs to try in D7 what it is currently doing with Modal Frame API in D6. This could be anyone, or it will be me when I have the time to port the other modules I maintain that make use of the Modal Frame API.
#2
The overlay module currently only handles admin links. There doesn't appear to be any easy way to reuse it for other parts of the site. I think the Modal Dialog API module could really step up to bridge this gap.
#3
>The question, IMO, is to see if the implementation of the Overlay module in D7 is able to cover all the needs that Modal Frame API covers.
I guess we should manage to build upon the solution in core. Currently overlay is hardcoded to work with "path_is_admin()" - but doing a little patch turning this into a hook that collects overlay-enabled paths from modules shouldn't be hard. Then we can easily build upon the overlay in core.
However I'm unsure whether overlay is able to handle non-drupal pages in the iframe too?
#4
I think that MFAPI shoud reuse overlay to cover contrib needs in popups
#5
The main issue I see with overlays, is that modalframe is often used on admin pages (line the node relationship module). So one might already be in an overlay. And there is no way to have overlays from overlays. So I think that modalframe is still need to allow of modals on admin pages.
#6
subscribing
#7
Having an overlay inside an overlay is dumb. I do think we just need a contrib that implements a simple way to re-use the core overlay - without any support for overlays in overlays what wouldn't work with the core overlay anyway.
From looking at the overlay module code, it should work like that:
- implement hook_init() and make sure it is called before overlay_init() via hook_module_implements_alter()
- implement a hook that allows modules to define additional non-admin paths to be opened in the overlay
- do not implement a custom permission, but leave that up to the modules whether they provide a path for the current user or not.
- use that to implement hook_init() like overlay_init() but taking all paths into account - including overlay paths if the user has permission.
- implement JS like the overlay module that is added via hook_overlay_parent_initialize() and changes the links to point to the overlay. A more hacky but simpler way to achieve the same would be using hook_module_implements_alter() to remove overlay_overlay_parent_initialize() + add an own hook implementation making use of the overlay JS with the own paths.
#8
Just to put the following thought/request from the editors view:
Independent of the actual solution, it would be amazing to have functionality from the "Automodal" module for auto-detected & simple use (via CSS class) of overlays and "Modal Frame CCK Editor" to edit whole nodes and unique node fields/fieldgroups - administered via UI as already possible.
#9
See #491224: Port modalframe API to Drupal 7, latest patch in #26.
Also: #1469508: Automodal Drupal 7 Port.
#10
let's leave only one issue #491224: Port modalframe API to Drupal 7