| <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> |
| <html> |
| <head> |
| <meta |
| http-equiv="Content-Type" |
| content="text/html; charset=ISO-8859-1"> |
| <title>SSE UI</title> |
| <link |
| rel="stylesheet" |
| type="text/css" |
| href="../sources/formate.css"> |
| </head> |
| <body> |
| <p class="ueberschrift">SSE UI</p> |
| <p>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.</p> |
| |
| |
| <p>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 <code>StructuredTextViewerConfiguration |
| class</code> and the <code>Extended Configuration</code> extension point |
| (<code>extendedconfiguration</code>) in the org.eclipse.wst.sse.ui plugin.</p> |
| |
| |
| <p>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 |
| <code>org.eclipse.wst.sse.ui.extensions.sourcevalidation</code> extension point).</p> |
| |
| |
| <p>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).</p> |
| |
| |
| <p>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:</p> |
| |
| <ul> |
| <li>An improved "undo" experience. SSE has a unified Undo stack based |
| on the resource being edited and allowing participants to provide |
| their own operations on the stack for complex operations. It seems |
| "touch and go" if the base provided function will suffice, but we are |
| still early in our investigation.</li> |
| <li>validateEdit per resource, not per editor instance</li> |
| <li>Unified selection. SSE has a ViewerSelectionManager designed to |
| coordinate selection among the editor's parts (text view, content |
| outline, property sheet) and handle the mappings from Node selection |
| to Text selection (and vice-versa). It has been a while since we've |
| looked hard at if the base provided support will suffice, but that is |
| also in plan to investigate before release 1.0.</li> |
| <li>Historically, several others which have a already been migrated, |
| such as "openOn" or hyperlink navigation and context-sensitive |
| preferences.</li> |
| </ul> |
| |
| <p class="schema">Extension Points</p> |
| <p><b>Extended Configuration</b></p> |
| <p>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.</p> |
| <p><b> Source Page Validation </b></p> |
| <p>Allows participants to provide an <code>org.eclipse.wst.validation.core.IValidator</code> |
| for source validation (as-you-type) via the <code>org.eclipse.wst.sse.ui.extensions.sourcevalidation</code> |
| extension point.</p> |
| |
| |
| <p>The enablement ("what" the validators can operate on) of the source |
| validators can be specified by content type ( <code>org.eclipse.core.runtime.content.IContentType |
| </code>) and partition types ( <code> |
| org.eclipse.jface.text.ITypedRegion.getType()</code> ) within each |
| content type.</p> |
| <p>This is likely the same <code>org.eclipse.wst.validation.core.IValidator</code> |
| used for "batch" validation via the <code>org.eclipse.wst.validation.validator</code> |
| extension.</p> |
| <p>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.</p> |
| |
| <p><b> Line Style Participants </b></p> |
| <p>Line Style Participants are similar to the Eclipse |
| IPresentationRepairers, but are designed to operate on structured |
| documents.</p> |
| <p><b>Editor related IDs</b></p> |
| |
| <p>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)</p> |
| |
| |
| <p>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<</p> |
| |
| |
| This are the current editor types supported followed by their keyword |
| (the last in list are reserved for possible future use): |
| |
| <ul> |
| <li>source page : source</li> |
| <li>graph page : graph</li> |
| <li>table page : table (reserved)</li> |
| <li>design page : design (reserved)</li> |
| <li>wysiwyg page : wysiwyg (reserved)</li> |
| </ul> |
| |
| |
| <p>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</p> |
| |
| |
| <p>Here are some examples: To contribute to *xml source editor's popup |
| menu*, use target id "org.eclipse.core.runtime.xml.source.EditorContext"</p> |
| |
| |
| <p>To contribute to *xsd graph editor's outline view's popup menu*, use |
| target id |
| "org.eclipse.wst.xsd.contentmodel.xsdsource.graph.OutlineContext"</p> |
| |
| |
| <p>To provide infopop for *html source page editor*, use help context id |
| "org.eclipse.wst.html.core.htmlsource.source.HelpId"</p> |
| |
| </body> |
| </html> |