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: | Implement structured XML layer editing | ||
---|---|---|---|
Product: | apisupport | Reporter: | Jesse Glick <jglick> |
Component: | Project | Assignee: | Jesse Glick <jglick> |
Status: | RESOLVED FIXED | ||
Severity: | blocker | CC: | issues, lkramolis, mkrauskopf, mkuchtiak, pjiricka |
Priority: | P1 | ||
Version: | 5.x | ||
Hardware: | All | ||
OS: | All | ||
Issue Type: | TASK | Exception Reporter: |
Description
Jesse Glick
2005-06-03 05:00:34 UTC
cvs rtag -b -r BLD200506021800 layer_visual_edit_59580 apisupport/project Indeed, it's possible. TAX was designed for 2way XML and DTD editing (#2 is known (and crucial) bug). But to be honest it has never meet that goal. I personally prefer (read-only) DOM over Document as used in completion because it can desribe broken document. I'm biased here. On constructive note, there is no perfect solution known. None of DOM, TAX, ddbeans, JDOM and NBDocumentDOM handles 2way editing out-of-box. For TAX you can try introduce TAX element <-> Document position mapping. It was planed as definitive solution... I asked Libor to comment more. He's still #1 XML models guru. So I guess the options are 1. Use Xerces + DOM and ask users to accept some reformatting. (This is already true of project.xml files for all Ant-based project types, but with the exception of freeform projects, these don't tend to be hand-edited so often.) 2. Use TAX as is and live with a little of reformatting of attributes and whatever else is broken. 3. Use TAX but try to correct its remaining bugs somehow. 4. Write a new lightweight 2-way library, ideally using DOM as the exposed interface (to minimize the amount of outside code that needs to be rewritten). Might need a custom parser since it's not obvious to me that Xerces is appropriate for the job. Obviously #1 or #2 are preferable from the standpoint of quick development time, while #3 or #4 are preferable for long-term quality. Has this issue come up for other XML types that the IDE edits, e.g. deployment descriptors? It looks like other cases in the IDE just use #1, i.e. text -> DOM -> schema2beans -> DOM -> text, which I presume loses any trace of the original formatting. I just remember the endless bug reports I had to close as WONTFIX when the Ant module used Xerces + DOM for 2-way editing of scripts (before NB 4.0 when this feature was removed); people really seemed to dislike it, and in fact I never wanted to use it myself. Similarly for the layer editing currently in apisupport - it's kind of cool to demo, but I would never use it on an actual layer in netbeans.org CVS: I would spend more time undoing formatting changes in the document after saving changes than I would just making the appropriate edit by hand to begin with. BTW handling of broken documents is not an issue for us here, I think - if the layer is malformed, it is OK to just refuse any structure edits until it is fixed. Adding Milan Kuchtiak to CC - he knows the most about schema2beans. For deployment descriptors, yes, we just accept that formatting is not preserved. scheam2beans at least preserves comments, so this information is not lost. Milan, do you what's the schema2beans approach to formatting? Merged to BLD200506091800. Ha! TAX is alive?! It's long time but I remmember I have never been XML models guru however I would like to be. :-D TAX was designed to be standalone and easy to use XML model API AND closely tied to NetBeans at once. It was my intention to build the only one NetBeans XML model API to be used by every XML related NetBeans module. I hade to solve current formatting problems of all "XML" modules. But it was not finished. Some formatting problems remains. It may be "disadvantage" that TAX instance is available just with well-formed document. And mainly it is not so light XML model -- it is not suitable for bigger XML documents. TAX was my child but I was too proud "father" to make perfect XML model implementation. :-( It would be very pleasant to see TAX API to be used however it would be surprise to me. Branch merged, initial work done. Not yet integrated with CreatedModifiedFiles, branding view, execution-time classpath, etc. etc. TAX seems to be working out OK so far. Horribly underdocumented but most of what I needed to know I could figure out from method names and from looking at source code. committed * Up-To-Date 1.15 apisupport/project/manifest.mf committed * Up-To-Date 1.15 apisupport/project/nbproject/project.properties committed * Up-To-Date 1.28 apisupport/project/nbproject/project.xml committed * Up-To-Date 1.2 apisupport/project/src/org/netbeans/modules/apisupport/project/layers/BadgingSupport.java committed * Up-To-Date 1.2 apisupport/project/src/org/netbeans/modules/apisupport/project/layers/LayerNode.java committed * Up-To-Date 1.2 apisupport/project/src/org/netbeans/modules/apisupport/project/layers/LayerUtils.java committed * Up-To-Date 1.2 apisupport/project/src/org/netbeans/modules/apisupport/project/layers/WritableXMLFileSystem.java committed * Up-To-Date 1.6 apisupport/project/src/org/netbeans/modules/apisupport/project/ui/ModuleLogicalView.java committed * Up-To-Date 1.2 apisupport/project/test/unit/src/org/netbeans/modules/apisupport/project/layers/WritableXMLFileSystemTest.java committed * Up-To-Date 1.42 apisupport/www/new-apisupport.html committed * Up-To-Date 1.132 ide/golden/deps.txt committed * Up-To-Date 1.25 ide/golden/impl-deps.txt |