[
https://issues.apache.org/jira/browse/NETBEANS-8?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ross Lamont updated NETBEANS-8:
-------------------------------
Component/s: xml - Code
> Make api.xml.ui SPI a properly pluggable SPI.
> ---------------------------------------------
>
> Key: NETBEANS-8
> URL: https://issues.apache.org/jira/browse/NETBEANS-8
> Project: Netbeans
> Issue Type: Improvement
> Components: xml - Code, xml - Schema
> Affects Versions: 8.2, 9.0
> Reporter: Ross Lamont
> Labels: API_REVIEW_FAST
> Attachments: NETBEANS-8.diff
>
>
> h3. Primary Justification
> According to [a common SPI
> definition|https://en.wikipedia.org/wiki/Service_provider_interface], an SPI
> should be extendable by _third parties_, and can be used to enable framework
> extension and replaceable components. A typical example is the Java Service
> Provider Framework.
> As a public and official API, it is doubtful the spi portion of the XML Tools
> API UI meets this definition. Because there is no runtime extension loading
> mechanism provided, it is not really possible for third parties to provide
> pluggable behaviour for existing clients of the API.
> h3. Motivation
> XML Validation techniques have moved on a long way since the original XML
> Validation code was written. The SPI seems to imply that the Validation
> function could be replaced by code in a plugin. Whilst it could be argued
> that this should probably never have been an SPI, given that it is an
> official SPI, it should be upgraded to offer true SPI semantics.
> h3. Patch details
> The attached patch adds a factory class to the API to enable clients to
> create action cookies from third parties. An SPI interface and default
> registered implementation are also provided for third parties to implement,
> and to wrap the existing functionality.
> No existing API or SPI has been changed, although some existing javadoc has
> been updated.
> As part of the patch, org.netbeans.modules.xml.XMLDataObject has been updated
> to utilise the new functionality. Other clients tend to be very specific and
> it seems unnecessary to update these. There is a commented out stub (with
> javadoc) in the API factory class which suggests a mechanism to serve these
> more specific use cases which can be implemented if this improvement is
> agreed to have merit.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
