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: | MultiEditorSupport - editor support, which is not closely associated just with swing Document. | ||
---|---|---|---|
Product: | platform | Reporter: | _ lkramolis <lkramolis> |
Component: | Text | Assignee: | issues@editor <issues> |
Status: | NEW --- | ||
Severity: | blocker | CC: | jchalupa, jglick, mkleint, mkuchtiak, pjiricka, pkuzel, tor |
Priority: | P2 | Keywords: | API, UI |
Version: | 3.x | ||
Hardware: | All | ||
OS: | All | ||
Issue Type: | ENHANCEMENT | Exception Reporter: | |
Bug Depends on: | |||
Bug Blocks: | 17297, 21748, 21540, 23762 |
Description
_ lkramolis
2002-03-06 11:13:12 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. Set target milestone to TBD 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 intuitive. 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. |