Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

How to document which editor interfaces are required by specific features? #303

Closed
Reinmar opened this issue Aug 19, 2016 · 1 comment · Fixed by ckeditor/ckeditor5-core#116
Labels
type:feature This issue reports a feature request (an idea for a new functionality or a missing option). type:improvement This issue reports a possible enhancement of an existing feature.
Milestone

Comments

@Reinmar
Copy link
Member

Reinmar commented Aug 19, 2016

This issue is based on #302.

The ckeditor5-core package is just a framework for creating RTEs. Final implementations, called also creators, are provided by other packages. Those creators extend base classes (atm it's Editor and StandardEditor) exposed by the core.

Now, on each level (Editor -> StandardEditor -> ClassicEditor) we've got a different set of properties available. E.g. Editor doesn't have keystrokes property because it's UI related. It appears in StandardEditor which is understood as "browser based editor with a single editable".

Most features are split into their "engine" and "full" parts. The BoldEngine provides only the command, schema and converters. It's compatible with editors which have document and commands and editing properties, so by Editor's children (there's a trick – Editor's constructor doesn't set editing property but defines it and says that it must be set). However, Bold requires much more – keystrokes and ui. It will work with StandardEditor and every other editor implementing the same interface.

What we're missing are definitions of these interfaces and features defining what kind of interface they need. Without them, end-developers won't know what kind of creator is needed for the set of features that he/she is using.

The easiest solution will be to create a set of standard interface definitions and in each feature's documentation define which interface must be provided.

We can also automate this by introducing new properties. E.g. Editor could have a implements property which is an array of strings (interface names) and feature requiresEditor (or something more intuitive) which defines which interfaces the editor must fulfill. If requirements are not met, we could throw an error.

@Reinmar Reinmar added type:improvement This issue reports a possible enhancement of an existing feature. status:discussion type:feature This issue reports a feature request (an idea for a new functionality or a missing option). status:confirmed labels Aug 19, 2016
@Reinmar Reinmar mentioned this issue Aug 19, 2016
@Reinmar
Copy link
Member Author

Reinmar commented Sep 12, 2016

Related ticket: #327.

pjasiun pushed a commit to ckeditor/ckeditor5-core that referenced this issue Jan 15, 2018
Fix: Removed `StandardEditor` class in favor of `DataInterface` and `ElementInterface` mixins. Added `EditorWithUI` interface. Closes #115. Closes #113. Closes ckeditor/ckeditor5#303.

BREAKING CHANGE: `StandardEditor` class is removed. Use `Editor` class with `DataInterface` and `ElementInterface` mixins.
@Reinmar Reinmar added this to the iteration 14 milestone Jan 15, 2018
mlewand pushed a commit that referenced this issue May 1, 2020
Fix: Removing rows in complex tables should properly move cells from removed rows. Closes #6502.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type:feature This issue reports a feature request (an idea for a new functionality or a missing option). type:improvement This issue reports a possible enhancement of an existing feature.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant