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: | OpenCookie inaccessible from XMLDataObject | ||
---|---|---|---|
Product: | xml | Reporter: | jalex000 <jalex000> |
Component: | Code | Assignee: | issues@xml <issues> |
Status: | NEW --- | ||
Severity: | blocker | CC: | rkubacki |
Priority: | P2 | ||
Version: | 5.x | ||
Hardware: | All | ||
OS: | All | ||
Issue Type: | ENHANCEMENT | Exception Reporter: | |
Attachments: | Test case for cookies available in XMLDataObjects |
Description
jalex000
2007-05-18 00:15:11 UTC
#104228: Testing the XMLDataObject has OpenCookie IDE:------------------------------------------------- IDE: [19.6.07 11:20] Committing "XMLDataObjectTest.java" started Checking in XMLDataObjectTest.java; /cvs/openide/loaders/test/unit/src/org/openide/loaders/XMLDataObjectTest.java,v <-- XMLDataObjectTest.java new revision: 1.5; previous revision: 1.4 My use case still does not work in 6.0M9, and comparing it with your unit tests, I found that you actually get different cookies in the XMLDataObject depending on whether the file is in the system filesystem or on a real disk-based filesystem. Concretely (assuming /path/to/file.xml exists): FileObject fo = FileUtil.toFileObject(new File("/path/to/file.xml")); DataObject xmlDo = DataObject.find(); Then xmlDo has an EditCookie, but no OpenCookie. If, instead, as in your test, the FileObject is stored somewhere in the system filesystem, just the opposite is true: the DataObject has an OpenCookie, but no EditCookie! I don't have time at the moment to track this further, but this difference isn't expected, is it? The data object in my test is on regular local file system. Maybe, we are talking about different XMLDataObject? What is your xmlDo.getClass()? Created attachment 44074 [details]
Test case for cookies available in XMLDataObjects
You're right - I'd forgotten that I never tracked down what TestUtilHid.createLocalFileSystem() did. Sorry about the misinformation. I've attached the test code I've been using. Invoke the static method OpenCookieTest.foo() to try. The output under either NetBeans 5.5 or 6.0M9 is: Did NOT find open cookie Found edit cookie class org.netbeans.modules.xml.core.XMLDataObject Found open cookie Did NOT find edit cookie class org.openide.loaders.XMLDataObject ... so I'm getting an org.netbeans.modules.xml.core.XMLDataObject. The critical difference seems to be the origin of the FileObject. If it's obtained via FileUtil.toFileObject(), I get an org.netbeans.modules.xml.core.XMLDataObject, with the cookie content shown above. If it originates via FileUtil.createData(), as in your test case, regardless of whether the underlying filesystem, I get a org.openide.loaders.XMLDataObject, which as shown has an OpenCookie, but no EditCookie. Indeed, if I uncomment the code at the end of my setup() method, obtaining a new FileObject for the same file from FileUtil.toFileObject(), I get another org.netbeans.modules.xml.core.XMLDataObject. So basically the problem is with the non-openide implementation of XMLDataObject. I guess the org.netbeans.modules.xml.core.XMLDataObject could be modified to have OpenCookie. I would say that there's a pretty compelling argument to be made that the cookie set of org.netbeans.modules.xml.core.XMLDataObject ought to be a superset of org.openide.loaders.XMLDataObject. It looks like that is the intent anyway, but the lazy instantiation code is not quite working right. See my comments on this in the original bug report. It is possible that the original intent was to use OpenCookie to open specialized editor (tree structure editor in the past) and EditCookie for text editors. The implementation of opencookie was plugged into dataobject from additional modules. Maybe consulting other XMLDO subclasses can help to find proper way how to deal with this. I am afraid that if there are some subclasses in the IDE it would be too risky to make changes here at this moment. I would like to revisit this post 6.0. |