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 59046 - Better support for multiview
Summary: Better support for multiview
Status: NEW
Alias: None
Product: platform
Classification: Unclassified
Component: Text (show other bugs)
Version: 4.x
Hardware: All All
: P3 blocker (vote)
Assignee: issues@editor
Keywords: API
Depends on:
Reported: 2005-05-18 23:19 UTC by Peter Zavadsky
Modified: 2010-01-12 05:20 UTC (History)
4 users (show)

See Also:
Exception Reporter:


Note You need to log in before you can comment on or make changes to this bug.
Description Peter Zavadsky 2005-05-18 23:19:59 UTC
Currently if there is a multiview with more than one editors
(CloneableEditor's), which is our case, there is not sufficient support for some

One case we are hitting is openAt facility. In that case we need to open
appropriate component, i.e. the one the PositionRef points to, but the
implementation doesn't know that the component it works with is a multiview, and
multiview itself doesn't allow to control which editor should be opened, based
on provided PositionRef.

One solution is to *unfinale CloneableEditorSupport#openAt* method, that would
allow the subclasses to override it appropriatelly (i.e. to select the correct
editor), which would be enough for our case. See also issue #59043.

But in general, more would be needed, than just this. Currently to achieve the
multiview with more that one editor (working on different docs) is possible only
by heavy hacks. No real support is available.
Comment 1 Peter Zavadsky 2005-05-18 23:22:34 UTC
Currently this boils down, to the API request:
unfinale CloenableEditorSupport#openAt method.
Comment 2 Petr Nejedly 2006-08-11 13:58:12 UTC
Sorry but I'm going to close this as WONTFIX.
If you have multiview displaying multiple editors (over multiple documents),
you're deeply abusing the API.
Multiview is intended to allow _multiple views_ over single model (usually
document). Having multiple documents displayed through single multiview is both
against the API philosophy and against common UI patterns.
CCing Milos if he wants to comment on multiview.
Comment 3 Petr Jiricka 2006-08-11 14:17:43 UTC
> Having multiple documents displayed through single multiview is both
> against the API philosophy 

Well, that may indicate a problem with the API philosophy. Let's start with the
desired use cases, see whether they are valid, and identify API requirements
based on that, not vice versa.

> and against common UI patterns.

I can not comment on that. But shouldn't we get the experts' opinion on this? I
am cc'ing Jano.

I personally would leave this issue open as an ENHANCEMENT.

One other complaint that I heard is that it is difficult to write multiview
editors (for single document), especially the logic that synchronizes the views,
manages modified state/SaveCookie etc. It is even difficult to write singleview
editors! (Or at least more difficult than it should be.) What do you (Petr and
Milos) think about that? Would it be possible to provide some extra support in
that area? Thanks.
Comment 4 Milos Kleint 2006-08-11 14:43:40 UTC
pjiricka: regarding the easy of development of MV editors
you are right, writing a multiview editor that incorporates an source editor is
quite difficult. However at least it's possible, having multiple source editors
is IMHO impossible given the current constraints we have and under which the
multiview support was developed. The constraint is backward compatibility of
org.openide.text. In order to have multiviews play well with one or more source
editor components, we would need a complete rewrite/deprecation of

Said that, I'm not sure if marking this issue enhancement will help anything.
The issue needs to get wide support, needs to be included in planning for next
release and needs developer resources assigned (possibly across teams, as we
will break current codebase at many places)
Comment 5 Peter Zavadsky 2006-08-11 18:29:24 UTC
What kind of constraint is there regarding CloneableEditorSupport? I am not
aware of any of such.

We were able to hack the current multiview (without changes of your code) and we
use 2 cloneable editor supports (2 tabs) in one multiview components. From my
point it seems there is needed just a better implementation of current
multiview, in order to make it easier for the clients of that API.
Comment 6 jrojcek 2006-08-14 14:49:53 UTC
Re. Multiview is intended to allow _multiple views_ over single model.

I cannot comment Creator's requirement from UI point of view. I'm Ccing Dusan. 

Also I don't want to talk about general UI pattern in this case, but rather about specific cases. Then we 
can see whether it makes sense from UI point of view.

In NetBeans, we might want to design a web service editor that contains 2 views: "Java Source", "Web 
Service". This tab would open up when the user double-clicks a java file that is a web service 
implementation. The "Java Source" view would contain java code. The "Web Service" tab would contain 
web service properties describing the web service (security, etc.). Currently those properties are defined 
in a special XML file. The truth is that we haven't figured out yet have actions like "Save", "Undo/Redo" 
would work from UI point of view. Last time I heard, maybe web services would be also defined by 
annotations, which would mean that all WS properties would be also defined in java file. So this is just a 
hypothetical UI.
Comment 7 Petr Nejedly 2007-09-14 07:39:56 UTC
Milos was recently working on a support for openning particular view in MV on
Comment 8 Milos Kleint 2007-09-14 09:02:45 UTC
yes, but it involved only 1 source view per MV. for getting multiple source views per MV, the above comments apply. I
don't think this is a bug -> enhancement.
Comment 9 Antonin Nebuzelsky 2008-04-17 15:13:32 UTC
Reassigning to new module owner mslama.