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.
Design them as maximaly decoupled from DataObject. Some users may simply need to define a MultiDataObject and still reuse the infrastructure. May be XMLDataObject should not be even public!
I made an attempt to collect various issues in Ant (& apisupport/layers) which were marked unfixable pending an XML API.
First rather simple draft is in CVS. It does not contain the most required model issues :-(. Still, no idea how to expose/develop/sustain it without managerial support.
I have found out that I should be interested. I'll post on dev@openide.
We are after feature freeze of 3.4. That should mean to have all features reviewed, implemented, covered by tests and documented. I do not think that this happened for the XML API and I am not sure how likely that will happen. Please consider rollback of the API so it will not appear in release34 branch.
Let these are considered while planning next release.
Target milestone was changed from not determined to TBD
Unscheduling from my todo list. New owner is gladly welcome. Meanwhile assigning to abstract issues@xml.netbeans.org owner.
I'd like to ask what are people's current requirements for a potential XML tools API. - What things should it accomplish? - Who would be the clients of this API? - What would be the benefits? - What needs to be changed compared to the current state? Thanks.
Requirements from Ant include: 1. Ability to tweak the editor. This is really more of an editor issue, but mentioned here for completeness: want to have a delegation chain text/x-ant+xml -> text/xml -> text/plain, so Ant module can set editor MIME type to text/x-ant+xml, then get regular XML abilities (toolbar, context menu) plus its own (target toolbar, Ant context menu). 2. Ability to structurally manipulate an XML file using DOM or perhaps some other tree API (but DOM preferred for its ubiquity - could add minor helper APIs for details DOM does not cover). Must preserve exact (char-by-char) formatting of document regions not logically affected by a change, and avoid unnecessary textual changes in regions that are affected by the change. Should have option to automatically insert appropriate indentation whitespace in newly created elements, or clean up whitespace surrounding newly deleted elements. Should also have a way of determining the document position (or just line number) corresponding to a given element (or perhaps other node), or the element corresponding to a given document position. At this time I do not see any need for an API for tree visualization (e.g. Node or Node.Property implementations) from the Ant module; just a raw structure editing API would be enough, as the Ant module has its own specialized display anyway which does not follow the XML structure. 3. Code completion APIs must be cleaned up (e.g. to not require you to impl DOM interfaces as a client, since these change with every DOM release), better documented (currently usable only by trial and error), and stabilized (published w/ some assurances of compatibility, using regular spec version dep). 3a. Support XML namespaces in code completion, for NS-aware grammars. 3b. Permit CC grammar to specify popup documentation (HTML format) for a given completion item. And of course I would not want to have to subclass some XMLDataObject to get these capabilities. All such SPIs should be available independently as needed by clients.
I guess this issue is obsolete. *** This issue has been marked as a duplicate of 76045 ***
The issue is obsolete