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 59580 - Implement structured XML layer editing
Summary: Implement structured XML layer editing
Status: RESOLVED FIXED
Alias: None
Product: apisupport
Classification: Unclassified
Component: Project (show other bugs)
Version: 5.x
Hardware: All All
: P1 blocker (vote)
Assignee: Jesse Glick
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-06-03 05:00 UTC by Jesse Glick
Modified: 2005-09-05 09:51 UTC (History)
5 users (show)

See Also:
Issue Type: TASK
Exception Reporter:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jesse Glick 2005-06-03 05:00:34 UTC
I would like to experiment with structured XML layer editing in apisupport. Old
apisupport had a basic XML layer editing facility using DOM read/write access
and a special FileSystem implementation. Investigating whether it is possible to
use TAX to replace the DOM layer, and incorporate the UI in the logical view of
an NBM project, so that you could manipulate the layer like any file tree.

Advantages of TAX:

1. Looks pretty easy to use - just get a cookie from an *.xml data object and
you can make changes to the tree, which automatically result in text buffer
edits which you can save whenever you like.

2. TAX seems to preserve most text formatting of unrelated parts of the document.

Possible problems:

1. TAX exports no public packages; would need to use an impl dep. Currently it
seems only xml/core, xml/tools, and xml/tree-edit use this API. On the one hand,
that is a little scary - not many clients. On the other hand, it seems that very
few changes have been made to it recently, so it is probably stable for now.
Opinions requested on this.

2. TAX does seem to sometimes lose formatting on unrelated parts of the
document, e.g.

<foo
    bar="baz"
/>

will be rewritten to

<foo bar="baz"/>

if you make some change elsewhere in the doc. This could be a problem for CVS users.

3. XMLDataObject does not appear to reload the tree if you discard changes in
the editor (at least this is true when using xml/tree-edit); there might be
other lifecycle bugs we don't know about.

Anyway, I'd like to try it and see, so will make a branch.
Comment 1 Jesse Glick 2005-06-03 05:01:14 UTC
cvs rtag -b -r BLD200506021800 layer_visual_edit_59580 apisupport/project
Comment 2 _ pkuzel 2005-06-07 09:01:55 UTC
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.
 
Comment 3 Jesse Glick 2005-06-07 15:55:53 UTC
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.
Comment 4 Petr Jiricka 2005-06-08 10:01:43 UTC
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?

Comment 5 Jesse Glick 2005-06-10 00:47:15 UTC
Merged to BLD200506091800.
Comment 6 _ lkramolis 2005-06-16 23:05:32 UTC
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.
Comment 7 Jesse Glick 2005-08-12 07:30:26 UTC
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