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 21233 - MultiEditorSupport - editor support, which is not closely associated just with swing Document.
Summary: MultiEditorSupport - editor support, which is not closely associated just wit...
Status: NEW
Alias: None
Product: platform
Classification: Unclassified
Component: Text (show other bugs)
Version: 3.x
Hardware: All All
: P2 blocker (vote)
Assignee: issues@editor
URL:
Keywords: API, UI
Depends on:
Blocks: 17297 21748 21540 23762
  Show dependency tree
 
Reported: 2002-03-06 11:13 UTC by _ lkramolis
Modified: 2010-01-12 05:20 UTC (History)
7 users (show)

See Also:
Issue Type: ENHANCEMENT
Exception Reporter:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description _ lkramolis 2002-03-06 11:13:12 UTC
There is a lot of editor supports in openide: CloneableOpenSupport,
CloneableEditorSupport, DataEditorSupport, OpenSupport, EditorSupport. And all
of them are associated with swing Document and expects just one TopComponent.

In XML we have two models: swing Document and Tree Model (a.k.a. TAX); and we
open it in two different components: TextEditorComponent and TreeEditorComponent.

We use DataEditorSupport as XML editor support, but it is hard to use and we
must hack some of its code.

Please, create new editor support, which will be open for multi editor
components and models. Thanks.
Comment 1 Jesse Glick 2002-03-18 20:14:15 UTC
I think this is potentially a major API addition which needs to be considered 
carefully. I would suggest that for 3.4 it be implemented entirely in the XML module 
and its usefulness evaluated for possible inclusion in openide or openidex. I agree it 
is unnecessarily hard to create a support for dual-mode opening of an object (text & 
structural). The minicomposer example module does it and the code is ugly and probably 
not 100% correct. The Ant module also does it, in a slightly different way, and again 
minor semantics problems here have been a frequent source of bugs.
Comment 2 Marek Grummich 2002-07-22 11:27:53 UTC
Set target milestone to TBD
Comment 3 Marek Grummich 2002-07-22 11:29:35 UTC
Set target milestone to TBD
Comment 4 Jesse Glick 2002-07-31 20:04:54 UTC
A special problem is how to get the save/discard/cancel dialog right,
and how to manage closing of the components. If there are
modifications, you want to permit the user to close either the text or
non-text CloneableTopComponent on the current workspace without
prompting, so long as at least one of the editors remains open. When
the last is to be closed, you need to have the dialog appear. To me
this suggests using a clone group, but it is not obvious. I never got
it quite right in the minicomposer example, by the way; someone more
knowledgeable about the workings of TopComponent close semantics (IMHO
rather confusing) should feel free to fix the example.
Comment 5 Peter Zavadsky 2002-11-18 10:30:15 UTC
OK, currently there is a support of  one to one relationship
(model[document) to one type of TopComponent).

As I understand it right there is a need to kind of many to many
relationship. I.e. (many models[or better saying many models of the
same data] to many types of TopComponents).

To the closing problem: I think it should be hanlded like it does
properties module with its table and editor, when the last component
(of all) is closing the dialog is popped out.
Comment 6 Jesse Glick 2002-11-20 04:35:10 UTC
Yes, the closing semantics is tricky: you want to show a dialog only
when (1) the object is modified, (2) the last editor of any kind for
the object is about to be closed. Take a look at sources for the
Minicomposer (openide/api/examples/, covered in the NB book in detail)
and observe how not obvious it is to get it right - in fact the logic
there is not quite right because I could not figure out how to do it
(after playing with randomly overriding various methods for an hour or
two)! If you are considering a particular API for this, as a test
please try rewriting the Minicomposer to use that for its OpenSupport
& EditorSupport, and ensure that it actually becomes shorter and more
intuitive.
Comment 7 Marian Mirilovic 2002-12-06 17:18:20 UTC
reassigne to David K., new owner of editor
Comment 8 Jesse Glick 2003-07-21 17:34:42 UTC
May also be desirable UI changes associated with this. For example,
may want to arrange things so that when one of the views/editors for a
file is opened, the others are as well. (As individual TopComponent's?
As tabs within one TopComponent?) This behavior might be controlled at
the API level with a cookie, or might be part of the configurable
behavior of a MultiEditorSupport, etc.
Comment 9 David Konecny 2003-07-22 09:40:20 UTC
Yes, this should be considered. 
Comment 10 Milan Kuchtiak 2004-10-07 18:03:36 UTC
Currently the implementation of MultiView for the combinations

Design View - XML View
Design View - Java Source View  etc.

is tricky somehow - need to hack the editor supports.

I vote for this feature to be implemented as soon as possible.
We consider to use that for visual editors in J2EE.
(web.xml editor, EJB editor)

This is the natural enhancement to MultiView API.
Comment 11 Jesse Glick 2004-10-08 02:54:43 UTC
Just for fun I've been trying to convert minicomposer (module in
openide/api/examples) to use MultiView. Can't get it to work. Spent
several hours trying to figure out this API without success, at least
in the area of window closing which is a huge mystery. All I want is
to have the exact same behavior as a plain DataEditorSupport (i.e.
prompt me to save the file before closing if necessary), but with an
extra tab that I will manage the appearance of myself and does not
contribute to the file's lifecycle at all... no idea how to do that.

API documentation is rather poor - many method parameters have no
documentation at all, etc. There is a rather odd design whereby each
tab acts somewhat like a top-level window, incl. individual
persistence and close semantics, which just doesn't make any sense (at
least in my scenario).

Note that I have intentionally not been looking at form source code -
attempting to do it just from multiview Javadoc. I gave up.
Comment 12 Jesse Glick 2005-11-04 18:28:49 UTC
We should seriously consider a vastly simplified convenience base class for
implementing document-type views with standard semantics... the current APIs in
this area are all but impenetrable.
Comment 13 Antonin Nebuzelsky 2008-04-17 15:15:11 UTC
Reassigning to new module owner mslama.