Opened 15 years ago

Closed 15 years ago

Last modified 14 years ago

#3480 closed Bug (invalid)

setData and getData events are not fired correctly

Reported by: Senthil Owned by:
Priority: Must have (possibly next milestone) Milestone: CKEditor 3.0
Component: General Version:
Keywords: Oracle Doc Cc: Senthil


We have a use case to change the editor data(ex: have to change the image source) before editor loads the html data. When i try to use the setData event it only gets fired during the form post (it supposed to be fired during the editor initialisation but its not doing)

Also the getData is getting fired for both the editor initialisation and the form post (it supposed to be fired only for the form post but its been fired for both form post and the editor initialisation).

This is stopping us to implement our business logic, please give high priority for this issue to fix.

Change History (4)

comment:1 Changed 15 years ago by Artur Formella

setData and getData are fired not by accident.

getData is fired every time "editor.getData()" is called, setData is fired every time "editor.setData()" is called.

We won't change it because we can't, but we can create new events for you.

Could you tell us what you need?

comment:2 Changed 15 years ago by Martin Kou

Yes, the way setData and getData are fired right now are actually correct in the editor's view. But there may be usability issues for developers.

The intention of setData and getData events are to allow developers to modify the data that's inputted to the editor and outputted from the editor. setData() is used for data input, and so the setData event intended for developer to modify data that's inputted to the editor. getData() is used for data output, and so the getData event is intended for developer to modify the output data.

So right now, if all you intend to do is the following, it would work:

  1. Initialize editor with no contents.
  2. Hook setData and getData handlers after editor is initialized, probably at the instanceReady event.
  3. Some AJAX response triggers setData() to load some data.
  4. Modify the data to be loaded via the setData handler.
  5. Some user action triggers getData() to get data from the editor.
  6. Modify the data to be returned via the getData handler.
  7. Data is submitted to the server via AJAX calls.

The problem is... that's not the only way data is set into and retrieved from the editor.

At step 1, users usually would like to load the data from some textarea in the page. The editor does not call setData to do this, and so there's no setData event. Even more confusingly, the editor actually calls getData() to do it, and so there's a getData event fired from this.

At step 7, many users would like to submit a traditional HTML form with the editor's data instead of using AJAX calls (and thus, getData()). For some reason, the editor actually calls both setData() and getData() here, and so both setData and getData events are fired for data output.

So this is very confusing for a developer working with traditional forms or webpages, rather than working on a mainly AJAX site.

comment:3 Changed 15 years ago by Frederico Caldeira Knabben

Resolution: invalid
Status: newclosed

The current behavior of the "getData" and "setData" events is correct. The key thing is having full knowledge of them to understand the sense of it.

The first thing to keep in mind is that events are not exclusively made for end developers' usage. They are also (and mainly) part of the editor execution process. Due to the editor nature, being highly modular and plugin based, events are fired and consumed by its code. End developers can then use those events, but must also consider the reason why we have them.

So, "getData" and "setData" are related to "data", of course. But, where it is and what's data inside the editor?

To better understand it, we can visualize the editor as a closed "box", with no UI, with "data" inside of it. That data is the initial data we have set when creating the editor instance. There are no events being fired at this point as that data is an intrinsic startup property of the editor.

Then, we start loading plugins, and one of them is responsible for the UI creation. Actually, we have a plugin that is responsible for managing the editing space only inside the editor UI (the editingblock plugin). At startup, this plugin loads and renders the "wysiwyg" editing block, which is the "rich editing area" in the editor UI. At this point, this editing area must be filled with the data, which is inside our editor "box". So, the editingblock plugin calls "getData()" to retrieve it... the "getData" event is fired.

Then the editing area has data being modified. But the data inside the editor "box" is not automatically updated when the user makes changes to the editing area. It actually remains just like its initial state.

At some point, the end developer decides to call "getData()" for her own needs. By doing this, we need to synchronize the editing area data with the data inside the editor "box". So, before anything else, the editingblock plugin calls setData() with the updated data... the "setData" event gets fired. Now, having the updated data in the editor "box", the "getData" event is fired for the end developer call.

comment:4 Changed 15 years ago by Artur Formella

Keywords: Doc? added
Note: See TracTickets for help on using tickets.
© 2003 – 2022, CKSource sp. z o.o. sp.k. All rights reserved. | Terms of use | Privacy policy