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.
We have introduced a generic interface how DataObject can provide its children. Currently two objects implement it. DataFolder and DataShadow. We are in need to have a generic support, so implementing the interface will be easier for compound data objects that will try to keep list of its children. I have created a sketch of possible interface, the implementation should store the links in xml file in similar style as DataShadow (filesystem name + resource name). The interface might not be prefect and can be changed during its usage, so I would suggest to test the ContainerSupport by changing DataShadow implementation to use it.
Created attachment 1287 [details] The skeleton - Ales, do not forget to change the @author field ;-)
The reason why most of the methods are protected is that this is SPI interface and I do not want other code than the one that creates this object to call methods add,remove,etc. methods on it. Making them public would probably be mistake (happend with MultiDataObject a time ago).
Who is expected to use this support? I do understand the intended use of the methods very well--why are the propertyChange methods abstract, when normally such things are concrete and final? Why are the read & write & createChildren methods concrete final, when normally such things are abstract? Why does getChildren return an empty array? Why would the implementation store things in an XML file, when for folders this is nonsense, and for .shadow and .group there is an existing text format that cannot simply be replaced? Maybe it needs some better documentation or discussion of the API.
Right Jesse, this has to be discussed. http://projects.netbeans.org/ps/DesOrg.html#GC
Created attachment 1298 [details] Improved version that uses URLs
Jesse, this is just support, DataFolder does not need to use it. As a support it has to offer more than plain interface, for example storage to XML. Listeners are abstract, because I think they will usually be delegated to data object that is using this support.
OK, I missed the context for this, the URL is helpful...
Target milestone -> 3.3
GroupShadow seems to be the best candidate to implement DataObject.Container. I would suggest the following requirements: 1) support the current format 2) support for relative links. URL is not bad but I'm strictly against using nbfs protocol. 3) use XML format. It has been used in project targets demo - see targets branch in projects module (it contains an implementation as well). The format is: <FileSystem systemName="G:/netbeans_home/Development"> <File name="/example"/> <File name="/icons"/> </FileSystem> if the link starts with '/' it is an absolute link (relative to the filesystem/all filesystems) otherwise it is a relative link (relative to the Container). systemName may be omitted. 4) The implementation should allow adding additional elements/attributes for subclasses (for example naming policy for group templates).
If this Support also should support project links, then I would like to allow customization in the algorithm how is the "base" or "root" name computed and resolved. The default implementation will always base it on the filesystem's system name. Development Object's implementation will be then able to create/resolve those names according to some "places" defined by the project. ContainerSupport could be also provided with a reference point to a filesystem in order to store link(s) relatively to that base point. It needs to be documented what is going to happen if some change is made to the linked DataObject properties (name, primary file).
Done, in main trunk.
x