Opened 13 years ago
Last modified 13 years ago
#8749 review New Feature
Passing data into a shared dialog
Reported by: | NicHolt | Owned by: | Alfonso Martínez de Lizarrondo |
---|---|---|---|
Priority: | Normal | Milestone: | |
Component: | General | Version: | |
Keywords: | Cc: |
Description
It is sometimes useful to be able to pass data to a shared dialog. For example, I have a datepicker dialog and a treeview selector dialog, both of which are invoked from several other dialogs. The getDialogValue function in the docprops dialog enables a shared dialog to be invoked, and provides a callback for e.g. passing the result to the parent dialog. However, there is no clean way to pass data - for example, the current value of an element in the parent dialog or options.
Here's how this can be achieved.
In plugins/docprops/dialogs/docprops.js:
Add a third argument to getDialogValue:
function getDialogValue( dialogName, callback, data )
Pass the data in the invocation of execCommand:
editor.execCommand( dialogName, data );
Change the following line to be generic (not just for colorDialog):
if ( editor._.storedDialogs[dialogName] )
In plugins/dialog/plugin.js
Add a data argument to show:
show : function(data)
Pass the data in the show event:
this.fire( 'show', data );
Add a data argument to exec:
exec : function(editor, data)
Pass the data in the invocation of openDialog:
CKEDITOR.tools.setTimeout( function() { editor.openDialog( this.dialogName, null, data ) }, 0, this )
And in openDialog itself:
openDialog : function( dialogName, callback, data )
And in the inline invocation of show:
dialog.show(data);
The data can be in any form, but I usually pass it as name-value pairs - for example, for the datepicker:
{ 'inputDate' : inputDate, 'dateFormat' : editor.config.dateFormat }
Attachments (1)
Change History (2)
Changed 13 years ago by
Attachment: | 8749.patch added |
---|
comment:1 Changed 13 years ago by
Owner: | set to Alfonso Martínez de Lizarrondo |
---|---|
Status: | new → review |
The patch allows to load existing data into a sub dialog, but instead of performing all those changes, moves the getDialogValue into the dialog plugin as a new method of the editor instance: openSubDialog.
The method has three parameters, the dialog name, a new callback function that it's called when the dialog is loaded, so it's possible to load the desired data at this point and the callback when the user presses OK.
I've been using this method for quite some time in the Google maps plugin without problems.
The patch modifies the doc and cell properties to use this callback and so it's initialized with the current value
Proposed patch