Please use the Apache issue tracking system for new NetBeans issues (https://issues.apache.org/jira/projects/NETBEANS0/issues) !!
Bug 94902 - Convert property editors module to use SPI and library of property editor interfaces
Convert property editors module to use SPI and library of property editor int...
Status: VERIFIED FIXED
Product: obsolete
Classification: Unclassified
Component: visualweb
5.x
All All
: P2 (vote)
: TBD
Assigned To: Gregory Murphy
issues@obsolete
:
Depends on:
Blocks: 90449
  Show dependency treegraph
 
Reported: 2007-02-07 23:16 UTC by Gregory Murphy
Modified: 2007-08-15 20:39 UTC (History)
0 users

See Also:
Issue Type: TASK
:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Gregory Murphy 2007-02-07 23:16:17 UTC
VWP packages a number of property editors together in a module. The editors have
been used in the past by other, third-party component developers, who were given
the module JAR so that they could compile design-time code that is intended for
use with VWP. This gives rise to a number of issues:

    * We need a means of refactoring all classes in the property editors module
(changing "com.sun.rave" to "org.netbeans.visualweb"), while still allowing
extant third-party component libraries to function correctly in VWP.

    * Ideally, we also need a better means of making property editors available
to third-party component developers. The current editors have dependencies on
modules in org.openide, and it is generally not appropriate to treat a NB module
as though it were a third-party library.

To resolve these issues, it is proposed to split the property editors module
into a library of property editor interfaces, and a module of property editor
implementations. VWP will guarantee to always provide an implementation
appropriate for each of the interfaces. Package names in the module can be
refactored independently of the names in the library, which can remain stable.
Though the editors in the libray will provide no functionality, for component
development all that is needed is that the class be present in the compile-time
class path.

To make this architecture as flexible as possible, it is also proposed to
introduce a new interface, PropertyEditorResolver, defined in its own library.
This interface defines a single method which, given a Java Beans
PropertyDescriptor, returns a property editor class which is appropriate for
editing the described property. VWP will provide one implemenation of this
resolver, which knows how to match interfaces in the VWP property editor library
with implementations in the VWP property editor module. It will also know how to
provide reasonable defaults for properties of JSF components. However, third
party component developers who wish to override the default resolutions can
provide a module with their own implementation of PropertyEditorResolver.

When Insync introspects a component for the first time, it will perform a lookup
to obtain all implementations of PropertyEditorResolver. For each component
property, it will ask each resolver, in order of priority, for an editor. If a
resolver returns an editor, the editor is used. If it returns null, the next
resolver is asked. If no resolver returns an editor, the global Java Beans
PropertyEditorManager will be queried for an appropriate editor.
Comment 1 Gregory Murphy 2007-03-02 19:02:24 UTC
Library of property editor interfaces is now defined. The wrapper module is at
./propertyeditors/api, and the library that it wraps is at
./propertyeditors/api/library.

The resolver module and library are in ./propertyeditors/resolver
Comment 2 Lark Fitzgerald 2007-08-15 20:39:19 UTC
Completed.


By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2014, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo