Yet a really importan feature is not implemented in modalframe, which is in jquery.ui dialogs. that are buttons

On that way, the whole "option passing" way must be exchanged, as it does completly make no sense copying over a object element by element. The options passed to modulframe should be always completely passed through to the dialogs. This makes the plugin feature safe.

Yet, while i can pass the button element, they are not shown. Somehow the button-pane is missin.

do you have any ideas, why its missing?

i just pass the buttons element into self.options and later in the openDialog callback, i do a
.dialog('options','buttons',self.options.buttons)

But they are never show. Also, adding the buttons when the dialog is initialy created, does not change this.

Iam not new to jquery.ui dialogs at all and this should work generally..the only thing i can see is the iframe..but actually the button should be outside that iframe anyway.

Iam using the modulframe to make a proof-of-concept implementation for the dialog in the WYSIWYG Module, which will get used for every editor. As there is still research, which dialog api to use, i prefer jquery.ui dialog as iam working with it for some years now and also have written a similar API for a framework ( Foswiki ) which encapsulates jquery.ui dialogs.

I hope i can help you making this plugin more complete so WYSIWYG is taking this project as the base for the dialogs.

CommentFileSizeAuthor
#2 parent.js_.patch3.81 KBEugenMayer
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

markus_petrux’s picture

Status: Active » Closed (won't fix)

Modal Frame API uses jQuery UI Dialogs, but that doesn't mean it must support all features of that plugin. Modal Frame API already provides methods to sync the parent and the child, and you have the parent document object available from the child window, so you should be able to implement any buttons in the child document.

Off Topic: I have also written Wysiwyg plugins for TinyMCE and I have never needed a modal dialog like the one that it is implemented here. Those tend to use browser windows so the user can manage there size and position independently of the parent window, probably for usability reasons, but what do I know, heh.

EugenMayer’s picture

FileSize
3.81 KB

For anybody interested, here is the patch against the current stable.

This is an addition ability to add buttons to the dialog, using the jquery-ui pane. Its something about the usability markus, that all submit / cancel buttons show up on the same place. In addition this is additional, not forcing you to do anything.

As you dont seem to be interested in contribution, i guess i fork this one of...no idea how somebody can be that secretively.

It makes totaly no sense removing functionality which is there, until it does make the whole thing complicated.

EugenMayer’s picture

This patch also fixes a small layout problem with the outer container of the iframe

markus_petrux’s picture

Re: "As you dont seem to be interested in contribution"

It depends. Not in this case. Here's why:

1) In regards to loading animation icon... you have also included this change here, ignoring my comments in the other issue you've opened: #595646: Hide loading animation as soon as the child document is loaded, restore the animation on page transitions. It's simply a theme issue that can be solved in the theme layer.

2) When you do this: self.options = options;, you're not copying the contents of the object but a reference of that object, hence altering this data later also alters the data from the caller, which is something that may break the caller, which is something I wanted to prevent.

3) The fact that the caller of the Modal Frame API cannot pass jQuery UI Dialog options is intentional. If you look at the code of the Modal Frame API, you'll see that I had to hack a few things of the jQuery UI Dialog implementation to work properly with iframes. Also, I wanted to provide some kind of animations when the modal frame opens, closes or loads/unloads the child document.

4) buttons pane in jQuery UI Dialog is something that I do not want to support here. Sorry. Buttons should be implemented by the child document, which is something you can do. You can even position them fixed at the bottom of the modal frame. This is far easier that adding buttons in the DOM of the parent document that should alter the behavior of the child document. Again, sorry, but I do not want to open this door as it will come with a can if worms that I do not wish here.

5) Nothing stops you from using jQuery UI Dialog directly to make it work the way you wish. I do not have any obligation to accept everything people requests, mostly when I think it may not worth, it does not fit into the scope of the module, etc. Also, I'm just sharing things I do for real projects. This is open source, and you can do whatever you want with the code, except expect the developer to move in the direction you want the project to move.

6) Re: "I hope i can help you making this plugin more complete"

Well, this sentence is not very accurate because it is totally relative what "complete" means. It depends on the goals of the project, and the resources you have to do it, and maintained in the future. There are reasons why things are coded the way they are. There may be bugs, I would love to hear about them (one of the reasons I'm sharing the code) and I'll accept patches or fix them myself. I may even accept feature requests, but that's something a bit more complex, because these must be in a direction I'm interested. I have accepted a lot of feature requests, sometimes accepting patches, sometimes coding them myself. But there's something that governs all these things... I write these modules for a project I'm working on, then I may share some of these, or not. But still, these modules are subject to specific needs, and that's something I cannot happily break for no reason, or just because someone else feels this module should do something else, or something different. Also, I do have more work than I can really do, so I tend to avoid things that will generate more noise than I really support. In this case, I disagree with your request, and I have given you hints about alternative approaches. That's all I can do here.