SSE UI
While there is a UI component to SSE, it has little API and is intended to be a relatively thin layer on top of the base Eclipse Text Editing API. SSE tries not to introduce UI API unless we've found it necessary to go beyond functionality provided by the Eclipse.
The most important, probably long-term, difference from the Eclipse
text editing component that we attempt to make all parts of the editor
configurable according to the platform content type of the input being
edited, and in many cases, based on the document partition types within
the file. This combination is the foundation of SSE's approach to
handling mixed content in a re-usable way. As such, one of the most
important areas to look at is the StructuredTextViewerConfiguration
class
and the Extended Configuration
extension point
(extendedconfiguration
) in the org.eclipse.wst.sse.ui plugin.
I mention this as a "long term" difference, since the text
infrastructure allows editors to specify whole "processors" (e.g. for
content assist) whereas our philosophy is to provide a processor that
allows clients to participate in creating the results. No implementation
exists for Content Assist at this time, but a working example of this
pattern can be found within SSE's "as you type" validation (see
org.eclipse.wst.sse.ui.extensions.sourcevalidation
extension point).
Another area we differ from text infrastructure is in syntax highlighting. We attempt to take direct advantage of StyledText widget's callbacks to achieve greater efficiency over preparing highlighting information in advance (this is the theory, we still have some implementation work to do to achieve in practice, in WTP Release 1.0).
Issues we hope to remove as differences: there are currently a number of overrides in SSE UI of Eclipse text functionality that were originally made due to limitations in Eclipse's text infrastructure (SSE dates back, in some form, to before Eclipse 1.0). Many of those limitations have since been improved upon or are improving in Eclipse's 3.1 stream. We are currently investigating transitioning to the provided infrastructure (some of which is new to Eclipse 3.1) instead of providing an incompatible workalike. These include:
Extension Points
Extended Configuration
The Extended Configuration extension point takes the loose coupling of the Eclipse SourceViewer and SourceViewerConfiguration classes one step further by allowing the viewer configuration itself to be dynamically discovered and loaded instead of being statically specified through code. The configuration class is most frequently specified according to the platform content type being edited. SSE extends the viewer configuration pattern to its outline and property sheet views and also allows for certain configurations to be specified according to document partition type and editor IDs.
Source Page Validation
Allows participants to provide an org.eclipse.wst.validation.core.IValidator
for source validation (as-you-type) via the org.eclipse.wst.sse.ui.extensions.sourcevalidation
extension point.
The enablement ("what" the validators can operate on) of the source
validators can be specified by content type ( org.eclipse.core.runtime.content.IContentType
) and partition types (
org.eclipse.jface.text.ITypedRegion.getType()
) within each
content type.
This is likely the same org.eclipse.wst.validation.core.IValidator
used for "batch" validation via the org.eclipse.wst.validation.validator
extension.
The validation messages are displayed to the user on the source page as as "temporary" annotations. These show up in the text as "squiggles" beneath the text and in the overview ruler as rectangles. The validation message itself is displayed by hovering the squiggle or rectangle.
Line Style Participants
Line Style Participants are similar to the Eclipse IPresentationRepairers, but are designed to operate on structured documents.
Editor related IDs
Structured Text editor clients can contribute actions to the editor as well as the help context id (infopop). Currently this can be done through extension points offered by the base (like org.eclipse.ui.editorActions, org.eclipse.ui.popupMenus) Infopop can be contributed by the standard infopop hooks (help context id points to actual help)
To contribute, a "target id" of some kind is needed. For Structured Text editors, the target id is generated based on the content type in the editor, type of editor, place to contribute. The target id looks like: >content type<.>editor type keyword<.>place to contribute keyword<
This are the current editor types supported followed by their keyword (the last in list are reserved for possible future use):These are the following places clients can contribute to followed by their keyword: editor popup menu : EditorContext editor vertical ruler popup menu : RulerContext outline view popup menu : OutlineContext help context id : HelpId
Here are some examples: To contribute to *xml source editor's popup menu*, use target id "org.eclipse.core.runtime.xml.source.EditorContext"
To contribute to *xsd graph editor's outline view's popup menu*, use target id "org.eclipse.wst.xsd.contentmodel.xsdsource.graph.OutlineContext"
To provide infopop for *html source page editor*, use help context id "org.eclipse.wst.html.core.htmlsource.source.HelpId"