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.
Expand a property DataObject, that contains more locales. Select one locale and choose Rename from the popup menu. The exception is thrown. It seems, that the list of actions is the same as on the DataObject node. Is this really supposed to work or is it just a bug? There're also filesystem actions. This brings VCS actions to individual locales, which is good. But unfortunately these actions act on all locales in the properties DataObject regardless on which locale was selected, this is a bug.
Created attachment 8957 [details] The exception thrown on rename of a locale.
Typical FilterNode surprise in NodeAction, no one is safe from them :-). Code reads that properties module tries to simulate its secondary files as standalone data objects. It means that it creates AbstractNodes for them that provide FileSystemAction, etc. What machinery do VCS actions use? I guess they grab DataObject cookie then list all files and perform an action over them. Is it public contract? Then I can return a FilteringDataObject that lists as primary file actual locale, hidding its secondaries.
The exception is eliminated. VCS operations on single locales is a low priority bug.
> What machinery do VCS actions use? I guess they grab DataObject > cookie then list all files and perform an action over them. Is it > public contract? Yes, exactly. > Then I can return a FilteringDataObject that lists as primary file > actual locale, hidding its secondaries. Yes, this looks like a good solution.
*** Issue 30453 has been marked as a duplicate of this issue. ***
I'm not sure if can create the filtering DataObject under current data systems. FileObjects are already recognized by master DataObject so I cannot construct public DataObject(FileObject pf, DataLoader loader) throws DataObjectExistsException because it always throws DataObjectExistsException. David does the new datasystems address it? Martin will CVS stick forever with DataObjects instead of file objects or defining a FileObjectCookie?
> will CVS stick forever with DataObjects instead of file objects > or defining a FileObjectCookie? I know nothing about FileObjectCookie. VCS modules work on FileObjects, but the VCS action must get the FileObjects from somewhere. Currently the only way goes through selected Nodes -> DataObjects -> FileObjects. It depends on the new DataSystems design how this path will change. I can use whatever approach that gives me currently selected FileObjects at the end.
virtual FileObjectsCookie: public FileObject[] getFileObjects(); You could grab it in your NodeAction and tralala... DataNode would automatically delegate to DataObject. You can fill it as an API request against openide.
Ken F. - not an I18N issue, this is just a plain code bug. Possible new Datasystems II would solve this sort of thing automatically - you would just get FileObject's directly from the node's lookup.
Jesse do you have specifics issue number to establish dependency on. 16389 is too general.
There is no more specific issue number currently. Ask dkonecny to file some issues under the #16389 umbrella if you think it's important.
I have updated issue 16389 to point to the most recent proposal.
I guess this is fixed with new vcs, is it not?
This was fixed in the new integration of versioning systems into NB 5.0.