{"action":"created","issue":{"url":"https://api.github.com/repos/ckeditor/ckeditor5-design/issues/124","repository_url":"https://api.github.com/repos/ckeditor/ckeditor5-design","labels_url":"https://api.github.com/repos/ckeditor/ckeditor5-design/issues/124/labels{/name}","comments_url":"https://api.github.com/repos/ckeditor/ckeditor5-design/issues/124/comments","events_url":"https://api.github.com/repos/ckeditor/ckeditor5-design/issues/124/events","html_url":"https://github.com/ckeditor/ckeditor5-design/issues/124","id":132149966,"number":124,"title":"Features: Commands","user":{"login":"scofalik","id":1502228,"avatar_url":"https://avatars.githubusercontent.com/u/1502228?v=3","gravatar_id":"","url":"https://api.github.com/users/scofalik","html_url":"https://github.com/scofalik","followers_url":"https://api.github.com/users/scofalik/followers","following_url":"https://api.github.com/users/scofalik/following{/other_user}","gists_url":"https://api.github.com/users/scofalik/gists{/gist_id}","starred_url":"https://api.github.com/users/scofalik/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/scofalik/subscriptions","organizations_url":"https://api.github.com/users/scofalik/orgs","repos_url":"https://api.github.com/users/scofalik/repos","events_url":"https://api.github.com/users/scofalik/events{/privacy}","received_events_url":"https://api.github.com/users/scofalik/received_events","type":"User","site_admin":false},"labels":[{"url":"https://api.github.com/repos/ckeditor/ckeditor5-design/labels/features","name":"features","color":"fbca04"}],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":1,"created_at":"2016-02-08T14:04:04Z","updated_at":"2016-02-08T15:23:03Z","closed_at":null,"body":"# Features concept\r\n\r\nThis is a part of Features concept. This issue discusses `Command`s.\r\n\r\n## Commands\r\n\r\n`Command`s are classes that allow for manipulations on Tree Model. When executed, a command performs an action on Tree Model. `Command`s should use `Batch` API to manipulate Tree Model.\r\n\r\nEach `Feature` should introduce one or more appropriate `Command`s. `Command` may introduce new `Element` or attribute, which will later be recognized and handled by feature's converters.\r\n\r\n`Command` will probably extend `Observable`.\r\n\r\n### Executing command\r\n\r\n`Command` is registered to the editor and can be executed from different parts of code without having a reference to actual `Command` object. Command execution will be available through `editor.exec( 'command_name' )` or similar call on editor instance. If a `Feature` introduces only one command, the command's name should be same as feature's name. If there are more commands, use `Feature:command`, i.e. `editor.exec( 'image:insert' )` (similarly to event naming). `Command` execution is always connected with focused editable.\r\n\r\n### Command states\r\n\r\n`Command` will have two properties responsible for it's state: (readonly) `isEnabled` and (optional, not always applicable) `isOn`. Those states are independent of themselves, so i.e. a command may be applied and disabled *(this is different from CKE4 where command had \"tri-state\" so it could be either on, off or disabled)*.\r\n\r\nIf a command is enabled, it means that it can be executed. Executing command which is not enabled should neither make any changes to Tree Model nor trigger any events. `isEnabled` value might depend on multiple factors:\r\n* a command (or corresponding feature) itself might decide that it is disabled, or\r\n* a command might be disabled because it's schema is invalid with focused editable's schema, or\r\n* a command might be marked by other command or part of code as disabled (other code disables the command).\r\n\r\nBecause a command might be \"locked\" by multiple sources, simple `isEnabled` property doesn't cut it. At one moment, a command might be enabled by itself but other commands or plugins might make it disabled anyway. We need a chain of callbacks. If any of those callbacks decides that command should be disabled, it will be disabled no matter what.\r\n*(More clarification on this subject is needed, I remember we were discussing binding events, but forgot details.)*\r\n\r\nIf a command has `isOn` property, and the property is `true`, it means that it has been executed for given editable / selection. Not every command will have this property, for some it won't make a sense.\r\n\r\nIt is little ambiguous what is the exact meaning, but this flag changes the behavior or execution method. Before `Command` is executed for the first time, `isOn` should be set to `false`. After command execution, it should change to `true`. Then, next execution should acknowledge that the command is on and apply different execution, to revert back to Tree Model state from before first command execution. Value of this state is completely dependent on `Command`. In other words, it is only a `Command`'s responsibility to introduce algorithm that decides if a `Command` is on. In most scenarios it will  simply depend either on `Selection` attributes or `Selection` position parents.\r\n\r\nCommand should have methods which will refresh state of `isOn` and `isEnabled` on demand. Making those properties as getters and trying to resolve their value each time they are accessed might be too inefficient.\r\n\r\n*(Proposal: change `isOn` to `isApplied` as it is more meaningful name and harder to confuse with `isEnabled`.)*\r\n\r\nIt was also discussed, that we may introduce a few abstract, base classes for commands which behaves similarly (i.e. `StyleCommand` for commands like `bold`, `italic`, `strike`)."},"comment":{"url":"https://api.github.com/repos/ckeditor/ckeditor5-design/issues/comments/181422962","html_url":"https://github.com/ckeditor/ckeditor5-design/issues/124#issuecomment-181422962","issue_url":"https://api.github.com/repos/ckeditor/ckeditor5-design/issues/124","id":181422962,"user":{"login":"fredck","id":630060,"avatar_url":"https://avatars.githubusercontent.com/u/630060?v=3","gravatar_id":"","url":"https://api.github.com/users/fredck","html_url":"https://github.com/fredck","followers_url":"https://api.github.com/users/fredck/followers","following_url":"https://api.github.com/users/fredck/following{/other_user}","gists_url":"https://api.github.com/users/fredck/gists{/gist_id}","starred_url":"https://api.github.com/users/fredck/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/fredck/subscriptions","organizations_url":"https://api.github.com/users/fredck/orgs","repos_url":"https://api.github.com/users/fredck/repos","events_url":"https://api.github.com/users/fredck/events{/privacy}","received_events_url":"https://api.github.com/users/fredck/received_events","type":"User","site_admin":false},"created_at":"2016-02-08T15:23:03Z","updated_at":"2016-02-08T15:23:03Z","body":"> Commands are classes that allow for manipulations on Tree Model.\r\n\r\nI don't feel that commands should be **limited** to Tree Model manipulation only. Actually, the concept of commands has nothing to do with the data model. It is actually deviated from features. Therefore commands should be the actions that perform such features.\r\n\r\nWe may have many commands that don't touch data. For example, `maximize`, `save` or `copy` could be toolbar features that should be execute as easily as any other feature.\r\n\r\nWe cannot avoid having commands, having just features, because a single feature may introduce more that one command. For example, the `link` feature may introduce the `link` and `link:remove` commands.\r\n\r\nThe commands concept works well for v4. The only problem I remember we had with it is when executing commands that accept options, like the \"font\" command. We should figure out a way to support this well, so every user action can be performed in the same way.\r\n\r\nAs for the `isOn` property, I would call it `isActive`."}}