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"