docs/org.eclipse.wst.doc.isv/html/plugin_descriptions_WST/sse_ui.html - gerrit/webtools/webtools.releng - Git at Google

 <!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>
	<!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>