Skip to main content
Jump to: navigation, search

Difference between revisions of "XQuery Development Tools/Where to Start"

 
(7 intermediate revisions by the same user not shown)
Line 24: Line 24:
 
|
 
|
 
* org.eclipse.wst.xquery.launching
 
* org.eclipse.wst.xquery.launching
−
* org.eclipse.wst.xquery.launching.<b><i>your_own_plugin</i></b>
+
* org.eclipse.wst.xquery.launching.<b><i>your_launching_plugin</i></b>
 
|
 
|
 
* <code>XQDTInterpreterInstallType</code>
 
* <code>XQDTInterpreterInstallType</code>
 
* <code>XQDTInterpreterInstall</code>
 
* <code>XQDTInterpreterInstall</code>
−
* add the <code>org.eclipse.dltk.launching.interpreterInstallTypes</code> extension point in <b><i>your_own_plugin</i></b> and provide a reference to your implementation of <code>XQDTInterpreterInstallType</code>
+
* add the <code>org.eclipse.dltk.launching.interpreterInstallTypes</code> extension point in <b><i>your_launching_plugin</i></b> and provide a reference to your implementation of <code>XQDTInterpreterInstallType</code>
 
|
 
|
 
* the <code>org.eclipse.wst.xquery.launching.zorba</code> plug-in
 
* the <code>org.eclipse.wst.xquery.launching.zorba</code> plug-in
 
** <code>ZorbaInstallType</code>
 
** <code>ZorbaInstallType</code>
 
** <code>ZorbaInstall</code>
 
** <code>ZorbaInstall</code>
−
 
 
* the <code>org.eclipse.wst.xquery.launching</code> plug-in
 
* the <code>org.eclipse.wst.xquery.launching</code> plug-in
−
* <code>XQDTJavaInterpreterInstallType</code>
+
** <code>XQDTJavaInterpreterInstallType</code>
−
* <code>XQDTJavaInterpreterInstall</code>
+
** <code>XQDTJavaInterpreterInstall</code>
 +
|-
 +
! Custom "Add Interpreter" Dialog
 +
|
 +
* The XQuery processors might be very different in terms of where they are located (local/remote), the libraries needed to run, the framework they are based on, etc. The default <code>AddLocalInterpreterDialogBlock</code> might not be satisfactory for some processors due to the string assumption that the processor must have executable file available on the local machine. To allow other processor types, one might need to define his own UI controls and logic when adding such a processor in XQDT.
 +
* XQDT allows vendors to provide an entire UI component to meet the processor's need.
 +
|
 +
* org.eclipse.wst.xquery.debug.ui
 +
* org.eclipse.wst.xquery.debug.ui.<b><i>your_debug_ui_plugin</i></b>
 +
|
 +
* <code>AbstractAddInterpreterDialogBlock</code>
 +
* add the <code>org.eclipse.wst.xquery.debug.ui.interpreterInstallTypeAddDialogBlock</code> extension point in <b><i>your_debug_ui_plugin</i></b>, provide a reference to your implementation of <code>AbstractAddInterpreterDialogBlock</code> and associate it to your <code>IInterpreterInstallType</code> ID.
 +
|
 +
* plug-in <code>org.eclipse.wst.xquery.ui.zorba</code>
 +
* <code>ZorbaTemplateProposalComputer</code>
 +
* <code>ZorbaTemplateCompletionProcessor</code>
 +
* <code>ZorbaTemplateAccess</code>
 +
* <code>ZorbaTemplateContentType</code>
 +
* <code>ZorbaTemplateContext<code>
 +
|-
 +
! Running XQuery
 +
|
 +
* Having new XQuery processor type defined (an <code>IInterpreterType</code>), a vendor must also provide the logic on how to start the process executing the XQuery code. This will build the command line that will be executed by the operating system.
 +
|
 +
* org.eclipse.wst.xquery.launching
 +
* org.eclipse.wst.xquery.launching.<b><i>your_launching_plugin</i></b>
 +
|
 +
* <code>IInterpreterRunner</code> or <code>AbstractInterpreterRunner</code> referenced from your <code>IInterpreterInstall</code>. This runner is only needed for the "run" mode (not for "debug" mode). See the <code>XQDTJavaInterpreterInstall</code> example for a sample implementation.
 +
|
 +
* the <code>org.eclipse.wst.xquery.launching.zorba</code> plug-in
 +
** <code>ZorbaInstall</code>
 +
** <code>ZorbaRunner</code>
 +
* the <code>org.eclipse.wst.xquery.launching</code> plug-in
 +
** <code>XQDTJavaInterpreterInstall</code>
 +
** <code>XQDTJavaInterpreterRunner</code>
 
|-
 
|-
 
! Semantic Checker
 
! Semantic Checker
Line 45: Line 78:
 
* org.eclipse.wst.xquery.launching
 
* org.eclipse.wst.xquery.launching
 
|
 
|
−
* <code>ISemanticValidator</code>
+
* <code>ISemanticValidator</code> or <code>AbstractLocalInterpreterSemanticValidator</code>
−
* <code>AbstractLocalInterpreterSemanticValidator</code>
+
 
* your <code>IInterpreterInstall</code> needs to implement <code>ISemanticValidatingInterpreterInstall</code> and provide an instance of your <code>ISemanticValidator</code>
 
* your <code>IInterpreterInstall</code> needs to implement <code>ISemanticValidatingInterpreterInstall</code> and provide an instance of your <code>ISemanticValidator</code>
 
|
 
|
 
* <code>ZorbaSemanticValidator</code>
 
* <code>ZorbaSemanticValidator</code>
 
* <code>MarkLogicSemanticValidator</code>
 
* <code>MarkLogicSemanticValidator</code>
 +
|-
 +
! URI Resolving
 +
|
 +
* The XQuery processors resolve the module/schema URIs in an implementation specific way. This feature allows vendors to provide their own logic for URI resolving to match their processors's logic. The URI resolving is used for example in code assist in order to find the functions for code completion.
 +
|
 +
* org.eclipse.wst.xquery.core
 +
* org.eclipse.wst.xquery.launching
 +
* org.eclipse.wst.xquery.launching.<b><i>your_launching_plugin</i></b>
 +
|
 +
* <code>IXQDTUriResolver</code> or <code>XQDTUriResolver</code>
 +
* add the <code>org.eclipse.wst.xquery.core.uriResolver</code> extension point in <b><i>your_launching_plugin</i></b> and provide a reference to your implementation of <code>IXQDTUriResolver</code>
 +
|
 +
* <code>ZorbaUriResolver</code>
 +
* <code>MarkLogicUriResolver</code>
 +
|-
 +
! Vendor code templates
 +
|
 +
* Vendors can provide their own templates (code snippets) to be added to the default set of templates shipped with the core of XQDT.
 +
* Moreover, vendors can resolve template variables in different ways. E.g. providing only in scope variables in a place where a variable is expected, etc.
 +
|
 +
* org.eclipse.wst.xquery.ui.<b><i>your_ui_plugin</i></b>
 +
|
 +
* <code>ScriptCompletionProposalComputer</code>
 +
* add the <code>org.eclipse.dltk.ui.scriptCompletionProposalComputer</code> extension point in <b><i>your_ui_plugin</i></b> and provide a reference to your implementation of <code>ScriptCompletionProposalComputer</code>. See the Zorba implementation for the complete extension point implementation.
 +
* <code>ScriptTemplateCompletionProcessor</code>
 +
* <code>ScriptTemplateAccess</code> (reads and caches the templates from disk)
 +
* <code>ScriptTemplateContextType</code>
 +
* add your <code>ScriptTemplateContextType</code> to the <code>org.eclipse.ui.editors.templates</code> extension point in <b><i>your_ui_plugin</i></b>. In the same extension point, provide also the .xml and .properties files where the templates will be read from. See the Zorba implementation for the complete extension point implementation.
 +
* <code>ScriptTemplateContext</code> (allows you to resolve template variables)
 +
|
 +
* plug-in <code>org.eclipse.wst.xquery.ui.zorba</code>
 +
* <code>ZorbaTemplateProposalComputer</code>
 +
* <code>ZorbaTemplateCompletionProcessor</code>
 +
* <code>ZorbaTemplateAccess</code>
 +
* <code>ZorbaTemplateContentType</code>
 +
* <code>ZorbaTemplateContext<code>
 
|-
 
|-
 
|}
 
|}

Latest revision as of 09:45, 28 May 2010

What is the "Where to Start" page?

This page gathers a list of features of XQDT and the place in the project where this feature is implemented or where the developer should first look and start understanding and debugging the functionality.

Feature table

NOTE: For all the classes below we have omitted the fully qualified name to keep the descriptions shorter. For example, XQDTInterpreterInstallType refers to org.eclipse.wst.xquery.launching.XQDTInterpreterInstallType. Eclipse helps you find these types with the "Open Type" dialog (available under the "Navigate" menu or by pressing the key combination: Ctrl-Shift-T). In case you find more classes having the same name (though not the case so far), just choose the one from our project, that is, having a package name starting with: org.eclipse.wst.xquery.

XQDT features
Feature name Feature description Plug-ins involved Need to implement Sample implementation
New XQuery Processor Type
  • A new XQuery processor type (called "interpreter" in DLTK terms) allows you to define you own logic for:
    • execution environment (local, like in Zorba or Saxon; or remote, like MarkLogic Server)
    • processor validation (e.g. only allow executables called zorba.exe to be added as the Zorba processor type)
    • launching configuration (e.g. add custom launching parameters to your processor type upon execution)
  • org.eclipse.wst.xquery.launching
  • org.eclipse.wst.xquery.launching.your_launching_plugin
  • XQDTInterpreterInstallType
  • XQDTInterpreterInstall
  • add the org.eclipse.dltk.launching.interpreterInstallTypes extension point in your_launching_plugin and provide a reference to your implementation of XQDTInterpreterInstallType
  • the org.eclipse.wst.xquery.launching.zorba plug-in
    • ZorbaInstallType
    • ZorbaInstall
  • the org.eclipse.wst.xquery.launching plug-in
    • XQDTJavaInterpreterInstallType
    • XQDTJavaInterpreterInstall
Custom "Add Interpreter" Dialog
  • The XQuery processors might be very different in terms of where they are located (local/remote), the libraries needed to run, the framework they are based on, etc. The default AddLocalInterpreterDialogBlock might not be satisfactory for some processors due to the string assumption that the processor must have executable file available on the local machine. To allow other processor types, one might need to define his own UI controls and logic when adding such a processor in XQDT.
  • XQDT allows vendors to provide an entire UI component to meet the processor's need.
  • org.eclipse.wst.xquery.debug.ui
  • org.eclipse.wst.xquery.debug.ui.your_debug_ui_plugin
  • AbstractAddInterpreterDialogBlock
  • add the org.eclipse.wst.xquery.debug.ui.interpreterInstallTypeAddDialogBlock extension point in your_debug_ui_plugin, provide a reference to your implementation of AbstractAddInterpreterDialogBlock and associate it to your IInterpreterInstallType ID.
  • plug-in org.eclipse.wst.xquery.ui.zorba
  • ZorbaTemplateProposalComputer
  • ZorbaTemplateCompletionProcessor
  • ZorbaTemplateAccess
  • ZorbaTemplateContentType
  • ZorbaTemplateContext<code>
Running XQuery
  • Having new XQuery processor type defined (an <code>IInterpreterType), a vendor must also provide the logic on how to start the process executing the XQuery code. This will build the command line that will be executed by the operating system.
  • org.eclipse.wst.xquery.launching
  • org.eclipse.wst.xquery.launching.your_launching_plugin
  • IInterpreterRunner or AbstractInterpreterRunner referenced from your IInterpreterInstall. This runner is only needed for the "run" mode (not for "debug" mode). See the XQDTJavaInterpreterInstall example for a sample implementation.
  • the org.eclipse.wst.xquery.launching.zorba plug-in
    • ZorbaInstall
    • ZorbaRunner
  • the org.eclipse.wst.xquery.launching plug-in
    • XQDTJavaInterpreterInstall
    • XQDTJavaInterpreterRunner
Semantic Checker
  • After the syntax check is complete without errors, a particular XQuery processor is allowed to report other errors in the XQuery code. E.g. function not available, namespace not declared, variable not defined, or even more complex problems that a particular processor may detect.
  • org.eclipse.wst.xquery.core
  • org.eclipse.wst.xquery.launching
  • ISemanticValidator or AbstractLocalInterpreterSemanticValidator
  • your IInterpreterInstall needs to implement ISemanticValidatingInterpreterInstall and provide an instance of your ISemanticValidator
  • ZorbaSemanticValidator
  • MarkLogicSemanticValidator
URI Resolving
  • The XQuery processors resolve the module/schema URIs in an implementation specific way. This feature allows vendors to provide their own logic for URI resolving to match their processors's logic. The URI resolving is used for example in code assist in order to find the functions for code completion.
  • org.eclipse.wst.xquery.core
  • org.eclipse.wst.xquery.launching
  • org.eclipse.wst.xquery.launching.your_launching_plugin
  • IXQDTUriResolver or XQDTUriResolver
  • add the org.eclipse.wst.xquery.core.uriResolver extension point in your_launching_plugin and provide a reference to your implementation of IXQDTUriResolver
  • ZorbaUriResolver
  • MarkLogicUriResolver
Vendor code templates
  • Vendors can provide their own templates (code snippets) to be added to the default set of templates shipped with the core of XQDT.
  • Moreover, vendors can resolve template variables in different ways. E.g. providing only in scope variables in a place where a variable is expected, etc.
  • org.eclipse.wst.xquery.ui.your_ui_plugin
  • ScriptCompletionProposalComputer
  • add the org.eclipse.dltk.ui.scriptCompletionProposalComputer extension point in your_ui_plugin and provide a reference to your implementation of ScriptCompletionProposalComputer. See the Zorba implementation for the complete extension point implementation.
  • ScriptTemplateCompletionProcessor
  • ScriptTemplateAccess (reads and caches the templates from disk)
  • ScriptTemplateContextType
  • add your ScriptTemplateContextType to the org.eclipse.ui.editors.templates extension point in your_ui_plugin. In the same extension point, provide also the .xml and .properties files where the templates will be read from. See the Zorba implementation for the complete extension point implementation.
  • ScriptTemplateContext (allows you to resolve template variables)
  • plug-in org.eclipse.wst.xquery.ui.zorba
  • ZorbaTemplateProposalComputer
  • ZorbaTemplateCompletionProcessor
  • ZorbaTemplateAccess
  • ZorbaTemplateContentType
  • ZorbaTemplateContext<code>
Retrieved from "https://wiki.eclipse.org/index.php?title=XQuery_Development_Tools/Where_to_Start&oldid=202884"

This page was last modified 09:45, 28 May 2010 by Gabriel Petrovay.

Back to the top