Thanks, great comment!
While outlining the post, I was uncertain what to call the particular group of classes (or concern) now called the Controllers. If you look through the GitHub project, you'll find that at one point they were called Routers. I agree with you that this design is not a MVC by the traditional definition (i.e. Smalltalk's), however there are many variants out there, see for example Apple's https://developer.apple.com/library/archive/documentation/Ge..., that I didn't think it would hurt 'to add' another. As long as it's clearly defined what it is. But perhaps it is not clear.
In this design, the 'traditional controller' is already part of the front-end. One of the goals of this design is to keep the front-end only concerned with styling and the layout of the application, and not the logic or the flow. So from the front-end, the user-interactions will be forwarded down to the 'back-end' Controllers. Those controllers are responsible for the flow of the application. The back-end includes logic and models in the traditional sense, see for example the DocumentsModel (https://github.com/Fagrell/clean-editor/blob/master/lib/publ...), however there are also models that correspond to specific Components. Those "Model Components" contain logic and a state, e.g. the MenuModel referred to in the post.
Perhaps an even better separation would be to add another layer?
- UI front-end - View/Component layer -> includes the 'view and controller by the traditional definition'.
- Router/Controller layer -> includes Models for specific components and Routers (as Controllers are defined in the post). Defines the flow.
- Back-end layer -> includes models by the traditional definition.
Thoughts?
While outlining the post, I was uncertain what to call the particular group of classes (or concern) now called the Controllers. If you look through the GitHub project, you'll find that at one point they were called Routers. I agree with you that this design is not a MVC by the traditional definition (i.e. Smalltalk's), however there are many variants out there, see for example Apple's https://developer.apple.com/library/archive/documentation/Ge..., that I didn't think it would hurt 'to add' another. As long as it's clearly defined what it is. But perhaps it is not clear.
In this design, the 'traditional controller' is already part of the front-end. One of the goals of this design is to keep the front-end only concerned with styling and the layout of the application, and not the logic or the flow. So from the front-end, the user-interactions will be forwarded down to the 'back-end' Controllers. Those controllers are responsible for the flow of the application. The back-end includes logic and models in the traditional sense, see for example the DocumentsModel (https://github.com/Fagrell/clean-editor/blob/master/lib/publ...), however there are also models that correspond to specific Components. Those "Model Components" contain logic and a state, e.g. the MenuModel referred to in the post.
Perhaps an even better separation would be to add another layer?
- UI front-end - View/Component layer -> includes the 'view and controller by the traditional definition'.
- Router/Controller layer -> includes Models for specific components and Routers (as Controllers are defined in the post). Defines the flow.
- Back-end layer -> includes models by the traditional definition.
Thoughts?