Modalframe is a great API used for many modules, but there is no way to alter the default settings of existing modal windows.
I found this problematic using existing modules with the modalframe API requirement. In my case one of them was the nodereference explorer module where the size and properties of open windows were locked in the application and I needed to define new sizes to fit the web design.
This patch intent to add a kind of alter for the modalframe settings, but as the settings and behavior of this module run mostly in the js part of the code there is not a direct translation of an _alter function. Thus, there is a hook function that can be called from any custom module that adds some overriding values that will be passed to the parent.js part of the module when it have the same url than in the hook. The modal frame properties that theoretically could be overrided would be the defined with the options.
I was able to make this work with width, height, autoFit and draggable.
This would be an example of how to use this override settings
/*
* hook_modalframe_override_js
*/
function mymodule_modalframe_override_js(&$override_js) {
$override_js['/noderelationships/search/place/field_image_reference']= array(
'autoFit' => FALSE,
'draggable' => FALSE,
'width' => 400,
'height' => 400,
//'customDialogOptions' => array('show' => 'fade', 'resizable' => FALSE, 'position' => 'right'), // that is not working
);
return $override_js;
}
(It should be possible to pass new values for the jQuery UI Dialog settings but I was unable to make any change to the existing ones, I think that the format of js array values passed with drupal_add_js(*,'setting') affects to that )
The most difficult part of this it is looking for the right url of the modalframe. You need to check the existing module code to find the right values, or see the url that your are clicking or executing when the modal window is open.
Of course this is an open proposal to extend the features of this fantastic module (thank you, by the way for your all so incredible modules).
I am using this in a devel server and it should be very useful for customizing any existing module that uses Modalframe API.
Comment | File | Size | Author |
---|---|---|---|
#2 | modalframe_override_js.patch | 1.25 KB | jcmarco |
Comments
Comment #1
markus_petrux CreditAttribution: markus_petrux commentedGiven the fact that this API is being used by a lot more modules than I could have never imagined, I agree that such a feature could be useful to cover even more use cases. :)
Though, I think we would have to use a method to alter this settings in javascript land. Maybe, the Modal Frame API could use a function to build the settings object, and this function could be overridden by other modules. It could be implemented like the Drupal.theme() stuff. ¿?
Comment #2
jcmarco CreditAttribution: jcmarco commentedDamn! the patch was lost!
Comment #3
brenda003I'm not sure the best method this should be implemented, but this patch and hook are working great.
Comment #4
markus_petrux CreditAttribution: markus_petrux commentedhmm... it seems to me my comment at #1 was missed here.
Let's say the page contains 2 different methods to open modal frames, implemented by different modules. They could now co-exist well. However, if we alter the settings for one of those implementation, how do we prevent the other implementation from using the altered settings?
Comment #5
jcmarco CreditAttribution: jcmarco commentedBecause settings are defined by url. (that is the only way I found to define an alter)
If each module are adding settings for different url's then there were no collisions.
Of course if there are two modules adding alters to the same url, then it will happen the same that now with a form_alter, the module with higher weight win.
Comment #6
markus_petrux CreditAttribution: markus_petrux commentedOh. I see. However, it does not look obvious how to pass options. There's a critical dependency on how these options have to be handled that it seems to me it could generate hard to debug situations when different modules use this hook in different ways.
I think we could be more confortable with something like the following mini-patch applied to
modalframe/js/parent.js
:Now, any module could do the following in its own javascript file sent to the parent window:
Comment #7
aufumy CreditAttribution: aufumy commentedI find the patch in #2 more useful for my case then #6.
However, having both patches applied might be fine as well.
My use case is that I want to alter noderelationships behaviour in my custom module.
So the likelihood that another custom module is altering noderelationships behaviour is small to negligible in my case.
Comment #8
Michsk CreditAttribution: Michsk commentedi would personally prefer a global overwrite option, to keep the overall feeling the same. And of course a option for a module to define it's own style but that again could be overwritten by the global options.
Comment #9
liquidcms CreditAttribution: liquidcms commentedfor my $0.02 worth.. i prefer a hook since i would rather work in php than js.
tried patch in #2 and it applied fine; but couldn't sort out which url to add; plus i can see this will be a pain as i have many places i use popups to edit... so would need to figure out url for each and add many many entries.
possibly, at very least.. an overall site config for maxWidth and maybe max Height (although i think width is more important of the 2) wouldn't be a bad idea.. and one that accepts % or px?
Comment #10
Alex Andrascu CreditAttribution: Alex Andrascu commentedI'm really looking forward to see this one implemented as a hook too.
+1
Comment #11
slucas CreditAttribution: slucas commentedHello,
I've look at your example implemention of the #2 new hook.
I've patched modal frame module with #2.
I want to use it on some of noderelationship module edit field.
But I don't know where to find the url, as it's not a real page and I don't know where it is in the node relationship module
function archiref_form_modalframe_override_js(&$override_js) {
$override_js['/noderelationships/search/place/field_image_reference']= array(
'autoFit' => FALSE,
.....
Comment #12
slucas CreditAttribution: slucas commentedI've found solution to my question
look at the $GLOBALS variable
but now the second problem is when there is nid in the url how do I adress all nids ? with one alteration
Comment #13
dsnopekI agree with @markus_petrux: this should be in Javascript. Automodal does a Javascript hook-like-thing. We could probably reuse the same pattern that's used there. Since this is a new feature and there isn't a satisfactory patch, let's address it in the Drupal 7 version first.