Proposal Editor, Document manager & Mode manager
This proposal comes from issue #38.
The document manager/store manages documents life-cycle.
It MUST be able to create a document under a unique id.
It means it MUST create a document instance, and COULD give to it some data provided by the user (if any). If not given, it MUST generate a unique id for the document.
The mode manager manages mode.
The user MUST be able to add modes to it.
Adding a mode involves two things:
- loading the mode module
- giving the user a way to target (retrieve) this mode
For the first point, the mode module could be specified in two ways:
- by giving the instance of the module itself: no issue with paths, it's up to the user of the manager to retrieve the module, but no possibility of lazy loading
- by giving the path of the module: in this case this would probably require the mode manager to be configured with a kind root path (path of the manager's consumer relative to the manager), possibility of lazy loading!
For the second point, the usual method is to associate a string key. But there are many other smart ways - involving slower retrieval however - to provide access to a mode:
- specify a list of names: still simple, but you can handle aliases and some typos this way
- specify a completely custom function that would be able to resolve the actual name targeted by the user: this could easily handle case, typo errors, etc.
Retrieving a mode is then simple: just provide a name and the manager will try to find a corresponding mode specification. If what has been found is not the mode module itself, it will try to load it from that (usually it's a path).
The editor manages edit sessions.
The user MUST be able to request a new edit session. For that he MUST use a document id provided by the document manager/store and he SHOULD provide information about the session.
The editor then will create an edit session and associate it to the document id.
The editor COULD provide the ability to create multiple sessions per document, and then to select the one to use upon request, and COULD also be able to set a session to be used by default.
An edit session is an object containing information about the current state of edition of a document. It MUST contain the following properties:
- the mode to use to edit the document: SHOULD be specified by the user, otherwise a default specific mode should be assigned (like
Plain Text)
It COULD also contain the following properties:
- an history of actions - to be able to handle an efficient undo/redo feature (modes should help for it)
- ...
For now a document instance is able to update itself, given a parser at its instantiation. This is contrary to the philosophy of this proposal, and this has already brought some issues in implementation.
A document should only be a simple object containing different models for its representation, as well as some other let's say generic metadata (not related to a specific mode).
Indeed, we said that a document could work in several modes, since a mode is associated to it in the context of an edit session. And the strategy to update smartly the model of a document should be specific to each mode - at least for graphs, since they are related to what the mode (parser more specifically) produces - for text content the document could still handle it itself.
So the logic of document update should be moved to modes.