This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
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.
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
Completed.