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.
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.
Set target milestone to TBD
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.
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.
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
reassigne to David K., new owner of editor
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.
Yes, this should be considered.
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.
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.
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.
Reassigning to new module owner mslama.