There is design-time code in the Woodstock project that will no longer
work in NB 6.0. The code provides support for binding to data providers.
In order to provide design-time support for binding components like
Listbox to data providers, special UI panels are referenced as part of
the configuration of the "bind to data" context menu action (vd.
"com.sun.rave.propertyeditors.binding.DataBindingHelper"). These panels
are part of a VWP module, and like all such modules, they are being
refactored as part of the move to open source. Classes that hitherto began
com.sun.rave
will begin, as of NB 6.0 milestone 8,
org.netbeans.modules.visualweb
Most third-party component libraries will not be affected by this
change, because I have split what once was a single module
(propertyeditors) into a module and a public library. The library will
preserve the "com.sun.rave" package names, and will be linked to
implementations in the module via a service provider look-up.
The library includes almost all property editors, but it cannot include
the afore mentioned data provider UI panels, because these classes have
numerous dependencies on other NB modules. They are part of the IDE, not
the component set.
What to do? The key question, it seems to me, is whether we are willing
to introduce into Woodstock a dependency on specific versions of VWP. If
we are, then an easy solution would be to refactor all references to the
UI panels in the Woodstock trunk. At that point, the Woodstock trunk
would work _only_ in NB 6.0. Branches slated for prior releases (e.g.
5.5.1) could be left alone, so that they work only in versions of NB
prior to 6.0.
If this situation is not acceptable, there are other solutions, but they
involve more work.
We could rewrite the list components so that they can be bound directly
to data providers, which I think would eliminate the need for the
special UI panels (as well as some awkward hacks in the
DataProviderPropertyResolver). This would have the added benefit of more
tightly unifying the design of the Woodstock components.
We could explore using run-time annotations to provide "hints" about
bindings, such that a data provider property resolver (or design-time
customizer) could determine whether it can convert data from a data
provider into a scalar or vector of objects, based on a constructor
signature in the annotation.
We could drop all special design-time support for data provider, and
focus instead on JPA.
// Gregory