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.
|Summary:||Separate and rearchitect property sheet|
|Product:||platform||Reporter:||_ tboudreau <tboudreau>|
|Component:||Explorer||Assignee:||Jaroslav Tulach <jtulach>|
|Severity:||blocker||CC:||jglick, jtulach, phrebejk, raccah, tpavek|
|Issue Type:||TASK||Exception Reporter:|
|Bug Depends on:||29447|
Description _ tboudreau 2003-06-07 21:08:19 UTC
This project has the following goals: - Make the entire property sheet API model driven - eliminate the dependancy on Node.Property, et. al. Currently PropertySheet has a hard dependancy on Node.Property, and PropertyPanel is model driven with an incidental dependancy on Node.Property. This schism is responsible for a huge amount of code complexity in the PropertySheet package, and a number of hacks. A new implementation should be self consistent - Provide a lightweight property rendering infrastructure usable by components such as TreeTableView (and of course PropertyPanel) - Split the property infrastructure into two pieces - - a property SPI library providing interfaces modeling properties and property containers - a property sheet implementation library with a public API for property rendering, etc. Providers of properties will not need to cart around a property sheet implementation if used outside NetBeans. - Eliminate the dependancy Looks has on Node.Property - interfaces will need to be compatible with Node.Property/PropertySet such that they may implement these interfaces (no more performance killing model instances created to bridge Node.Property and the current PropertyModel, and no more hacks such as the ReusablePropertyModel in the new PropertySheet code) - Provide a bridge to the existing property sheet/property panel API and deprecate that API. - Allow objects to flexibly provide properties without needing to depend on Nodes Open questions: - Is the PropertyEnv stuff even useful? The hinting mechanism FeatureDescriptor.getValue(String) should be covered by the new interfaces. In that case, the only value it has is as an object specific to a single rendering case that may be used to transmit values needed only in that use case. AFAIK nobody uses it in this capacity. - Would a Looks-like mechanism be good here for modifying or suppressing properties? This would eliminate the use of FilterNode only for the purpose of altering the property set of some nodes. AFAIK the only difference between nodes and properties is that properties are leaves, and only one level of hierarchy is supported (PropertySet->Property). It would be relatively easy to preserve the semantic difference, which is useful to programmers, but eliminate the implementation difference (with the exception of perhaps a requirement to maintain the hierarchy limitations of properties). Properties could be an alternative sub-hierarchy of a node provided by the look. In this case, Node.Property/Set need not implement the new property interfaces, Looks could simply provide a compatibility bridge.
Comment 1 _ tboudreau 2003-08-24 01:05:19 UTC
Comment 2 Jaroslav Tulach 2010-10-08 04:05:46 UTC
I see no driver right now to do this.