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: | XML API enhancements (model) | ||
---|---|---|---|
Product: | platform | Reporter: | Jesse Glick <jglick> |
Component: | -- Other -- | Assignee: | _ pkuzel <pkuzel> |
Status: | CLOSED WONTFIX | ||
Severity: | normal | CC: | issues, jtulach, lkramolis, pkuzel |
Priority: | P4 | Keywords: | API |
Version: | 3.x | ||
Hardware: | PC | ||
OS: | All | ||
Issue Type: | ENHANCEMENT | Exception Reporter: | |
Bug Depends on: | 20532, 22919 | ||
Bug Blocks: |
Description
Jesse Glick
2000-12-11 12:57:46 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. 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. |