Re: [editing] CommandQuery Object and Event

On Fri, Jun 6, 2014 at 1:29 PM, Piotr Koszuliński <
p.koszulinski@cksource.com> wrote:

>
> TL;DR
> 1. Let's drop execCommand and queryCommandState. They have no real value
> for developers and clearly conflict with cE=minimal. JavaScript frameworks
> will be created which will allow implementing totally custom and
> customisable commands.
> 2. Expose necessary APIs and architecture so all necessary commands can be
> implemented in JavaScript. Currently I can think only about copy, cut,
> paste which someone may want to disabled in some conditions. Maybe also
> undo and redo, because I can imagine that advanced editor's logic may be
> too complex to use native undo manager (but maybe I'm wrong - I haven't
> read undo manager's spec). Basically, it would be nice if we were able to
> control state of commands that should appear in browser menu bar or context
> menu, but that does not have to be based on currently existing commands API.
>
>
To give an example.

1. User presses down key.
2. A command event with commandType == 'moveSelectionDown' is fired.
3 a. If app does not execute preventDefault(), then the default action is
executed by browser. The default action means executing e.g.
selection.move( DIRECTION_DOWN ) or any other more complex code but using
exposed APIs.
3 b. If app executes preventDefault(), then it can call selection.move(
DIRECTION_DOWN ) and the result should be identical. Or it can
preventDefault() and e.g. execute selection.move( DIRECTION_END_OF_DOCUMENT
)

The idea is to expose necessary functions in form of
selection/element/whatever methods and use these methods. The same may be
achieved by execCommand() and related methods, but: a) backward
compatibility, b) not standardised, c) too high-level in some cases, d) not
the best API design ever, e) problem with extensibility.


-- 
Piotrek Koszuliński
CKEditor JavaScript Lead Developer