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.

Bug 8864 - XML API enhancements (model)
Summary: XML API enhancements (model)
Alias: None
Product: platform
Classification: Unclassified
Component: -- Other -- (show other bugs)
Version: 3.x
Hardware: PC All
: P4 normal (vote)
Assignee: _ pkuzel
Keywords: API
Depends on: 20532 22919
  Show dependency tree
Reported: 2000-12-11 12:57 UTC by Jesse Glick
Modified: 2008-12-22 19:48 UTC (History)
4 users (show)

See Also:
Exception Reporter:


Note You need to log in before you can comment on or make changes to this bug.
Description Jesse Glick 2000-12-11 12:57:46 UTC
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 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.
Comment 1 Jaroslav Tulach 2001-02-05 14:45:59 UTC
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.
Comment 2 Jesse Glick 2001-02-05 15:20:59 UTC
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).
Comment 3 _ pkuzel 2001-02-05 16:01:59 UTC
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?
Comment 4 Jan Chalupa 2001-03-12 12:07:37 UTC
Version: 'Dev' -> 3.2
Comment 5 Jan Chalupa 2001-05-06 08:12:24 UTC
Target milestone -> 3.3
Comment 6 akemr 2001-07-09 15:35:04 UTC
Reassign to proper address.
Comment 7 akemr 2001-09-04 07:00:51 UTC
I'm not sure about status - reassigning to Petr
Comment 8 _ pkuzel 2001-09-04 13:35:47 UTC
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.
Comment 9 _ pkuzel 2002-02-01 11:45:20 UTC
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
Comment 10 Jesse Glick 2002-02-01 13:36:09 UTC
I thought you planned to use TAX for this, and not support such a
mapping in openide itself?
Comment 11 _ pkuzel 2002-02-01 13:48:51 UTC
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
Comment 12 Jesse Glick 2002-02-03 12:08:05 UTC
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.
Comment 13 _ pkuzel 2002-04-29 09:27:59 UTC
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.
Comment 14 _ pkuzel 2002-04-29 09:35:41 UTC
Sorry for "(none requires it)", it is a bug in previous comment.
Comment 15 _ pkuzel 2003-03-18 08:38:05 UTC
It has splitted into issue 20532 and issue 22919.
Comment 16 Marian Mirilovic 2003-07-25 10:41:31 UTC
Due to new issues created - closing.