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.
There is a lot of automatic refreshing which XMLDataObject should do which it does not. As an example, if you register some info processor class for a DTD; then recognize a *.xml file with that DTD, so that it generates the specified cookies and/or special node with your processor; then change the registered info for that DTD (= public ID), the existing *.xml file is not refreshed, though new *.xml files with that DTD will be handled correctly (or if you invalidate the original one). This causes problems both for testing modules (you have to go through extra steps besides reloading the module to see changes, since you must force existing XMLDataObject's to be re-recognized); and for some code in org.netbeans.core.windows.toolbars: it ought to be possible to register a processor class for a public ID whenever you like, and have existing XMLDataObject's with that DTD suddenly get your processor, fire PROP_COOKIES or whatever, and have FolderInstance recognize the new cookies in the folder and rescan and refresh itself correctly. Currently the processor for toolbars must be registered very early in IDE initialization, before anyone might recognize any of the toolbar XML files.
I think we should a bit change the way how IDE handles XMLDataObjects. So I would like to introduce something like XMLCookie (has method getDocument () and maybe more) XMLSupport (which will implement this) XMLDataObject (which composes this together) I would like Petr Kuzel, to comment this a bit, before we do it.
This could be a fairly big change (cf. thread with me & Petr K. on nbdev), but I think it would be really cool. Something like org.openide.src provides: DOMCookie (getDocument, getStatus, addPropertyChangeListener, PROP_STATUS, PROP_DOCUMENT, prepare -> Task), DOM mutation events on document -> regenerate source & add SaveCookie, ... anyone interested in this should look at the Ant module (esp. AntProjectSupport) and the kinds of things it currently must do without help (nothing in XMLDataObject is usable for it currently).
I would like to start requirements thread on the topic at nbdev@ before we will implement it. There are more competing implementation ideas: -supports approach (Yarda) -compound data objects (Svata, Hrebejk) -Infos as described by Libor Well defined requirements should precede implementation decision. Ales could you start it?
Version: 'Dev' -> 3.2
Target milestone -> 3.3
Reassign to proper address.
I'm not sure about status - reassigning to Petr
Now listening at enviroment lookup and firing PROP_COOKIE accordingly. Second part i.e. XMLDocumentCookie that mimics EditorCookie is not implemented. So changing to an enhancement.
It is not still introduced. I am not sure if XMLCookie should have: _org.w3c.dom.Document_ getDocument() throws IOException; etc. methods. Simply not sure if DOM is right choice. The DOM model Java mapping has repeating back compatability problems. Also the model itself is not perfect.
I thought you planned to use TAX for this, and not support such a mapping in openide itself?
TAX is not suitable to be referenced by OpenIDE APIs. On the other hand in OpenIDE API exists XMLDataObject that should have attached a XMLCookie if exists. A side API cannot force XMLDataObject behavioural change. Or do you think that XMLDataObject should not have attached it?
IMHO it's acceptable to leave XMLDataObject alone and ask that modules wishing to make use of the new structural API depend on the TAX library (and ask for an implementation using OpenIDE-Module-Requires). Or something similar, e.g. depending on XML Core. Then some XML modules would be required in order to make XML structure editing possible. After all, we are adding a brand-new feature here.
This issue is about: 1) XML models, 2) two way editing and 3) XMLDataObject role. 1. The part related to model is now deferred and waiting for MDR repository that promisses to solve modeling problems. 2. The part related to two way editing introduces requirement for possition support during filling model and generating text representation from it. Does MDR integration module introduces something like it (#22919)? 3. The XMLDataObject role can be better defined by #20532. I can see two use cases (none requires it): A) XMLDataObject is dedicated to system XML files. User's XML files are handled by modules (dataloaders and dataobjects). It is moreless current state. B) XMLDataObject handles all XMLs (system and users). To achieve it: it must be fully extensible by modules and modules must be aware of system XML files. I doubt that it is possible. I prefer A) approach, it leads to XML cookies standartization (API) and set of SPIs supporting cookie providers. Besides, I think that current loaders.XMLDataObject subclassing by user's XML data object providers is evil. It would be better solved by SystemXMLCookie defining all stuff required for system XML files.
Sorry for "(none requires it)", it is a bug in previous comment.
It has splitted into issue 20532 and issue 22919.
Due to new issues created - closing.