SSE Core
The more substantial contribution of SSE is its core APIs.
Structured Documents
Once central concept is the IStructuredDocument
. It is
intended to be similar to an IDocument, but with a few significant
differences. Some changes are aimed at providing characteristics that
document programmers expect to see, such as encoding and end-of-lines
information. In addition:
The IStructuredDocument is conceptually a stream of characters made up of (divided into) IStructuredDocumentRegions. The main constraint on what types of languages are appropriate for structured documents and structured regions is whether or not it has the concept of having a syntactically determined end. This is used to know how to correctly handle reparsing (deciding what is a "safe start" and "safe end" for the reparse operation).
Parsers and re-parsers
The parser/reparser pair has a few conceptual requirements. They must be able to handle any text (legal or not) and must return regions that completely cover the input text (for example, whitespace can not simply be ignored). More difficult to implement, another constraint is that for any (correctly specified) subset of text, the reparser must give the same results that the parser would if parsed from top to bottom.
It might be useful to note, for anyone looking at detail at the parsers and re-parser implementations, for cases involving "invalid input", heuristics are often used to make these decisions so sometimes we can and do "guess right" (based on what a user might be in the process of typing) and sometimes not -- in other words, its not always easily predictable as it is for "clean" text but is based on doing a reasonable job which would not invalidate subsequent reparsing.
Structured Document Events
The StructuredDocumentEvents are similar to IDocument's DocumentEvents, but provide much more information about the nature of the change in terms of IStructuredDocumentRegions (and the ITextRegions of which they are composed). Listeners, such as DOM parsers, can make use of this to minimize the amount of reparsing/rebuilding they have to do.
Structured Models
Structured models are mostly interesting due to is extended types and implementers and exists as an abstraction to provide a consistent way to manage shared models and also to access its underlying structured document.
Node Notification and Adaption
In addition to IAdaptable and whole model state listeners, many "Node" structures in SSE related models make use of a finer level of adaption and notification. This mechanism can be used to have improved UI updates or can be used to keep related models "in synch" (for example, a DOM model change can cause a change in an EMF model, and vis versa).
Model Management
Another important contribution of sse.core is the IModelManager. Its purpose is to provide a StructuredModel, appropriate to contentType, that can be shared between many clients at runtime. This increases efficiency since each client doesn't have to (re)create their own, but just as importantly, it is an easy way for clients to all stay "in synch"--a change in the model made by one client will be known by all others clients. The other motivation for this is it allows looser coupling, since clients who may not even know about each other can share the resource (model) without passing it around to each other.