Changes between Initial Version and Version 1 of Ticket #12859
- Timestamp:
- Jan 26, 2015, 12:50:52 PM (10 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
Ticket #12859
-
Property
Status
changed from
newtoconfirmed
-
Property
Status
changed from
-
Ticket #12859 – Description
initial v1 1 1 Why CKEditor fails when I try to call some methods one after another? 2 2 3 ``` 3 {{{ 4 4 editor.setData( someData ); 5 5 // somewhere later... 6 6 editor.destroy(); 7 ``` 7 }}} 8 8 9 9 The answer, unfortunately, isn't simple. Otherwise we'd have this fixed a long time ago. This is a mix of history, backwards compatibility, architectural limitations and lack of good solutions. … … 19 19 The last thing, and actually the most unfortunate, is that throwing errors is not that good solution. It may tell you that you're doing something wrong, but it won't tell you when you can do it. 20 20 21 ``` 21 {{{ 22 22 try { 23 23 editor.setData( ... ); … … 36 36 } 37 37 } 38 ``` 38 }}} 39 39 40 40 Isn't it ugly? I think it's a terrible developer experience. A more useful approach would to be cache method calls and execute them when the editor reaches the correct state. But this would mean that for instance `editor.destroy`, which is currently a synchronous method, would become an asynchronous one because it can't be executed while editor is not ready. Moreover, to make all this possible to implement we would need to do serious changes not only in the API, but in the editor internals as well. Even the highly unsatisfactory solution with throwing errors requires significant effort to and may lead to ugly compatibility issues. 41 41 42 To sum up. I don't want say that fixing this in CKEditor 4.x is impossible, but for now we didn't have enough resources and well... courage, to attempt that. I would also risk a statement that it's late in CKEditor 4.x for such changes. But most importantly, we are aware of these problems and will definitely [ design CKEditor 5](https://github.com/ckeditor/ckeditor5-design)'s API differently.42 To sum up. I don't want say that fixing this in CKEditor 4.x is impossible, but for now we didn't have enough resources and well... courage, to attempt that. I would also risk a statement that it's late in CKEditor 4.x for such changes. But most importantly, we are aware of these problems and will definitely [https://github.com/ckeditor/ckeditor5-design design CKEditor 5]'s API differently.
