[ 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)