Bug 59046

Currently this boils down, to the API request:
unfinale CloenableEditorSupport#openAt method.

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.

> 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.

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
CloneableEditorSupport.

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)

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.

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.

Milos was recently working on a support for openning particular view in MV on line.show/openAt.

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.

Reassigning to new module owner mslama.