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 107858 - [65cat] Stabilize xml/multiview
Summary: [65cat] Stabilize xml/multiview
Alias: None
Product: xml
Classification: Unclassified
Component: XML Multiview (show other bugs)
Version: 6.x
Hardware: All All
: P2 blocker with 43 votes (vote)
Assignee: issues@xml
Depends on:
Reported: 2007-06-22 16:18 UTC by Erno Mononen
Modified: 2014-11-05 09:26 UTC (History)
12 users (show)

See Also:
Issue Type: TASK
Exception Reporter:

Current Javadoc (532.05 KB, application/octet-stream)
2009-06-23 14:46 UTC, Petr Jiricka

Note You need to log in before you can comment on or make changes to this bug.
Description Erno Mononen 2007-06-22 16:18:46 UTC
Currently the xml/multiview module exposes a friend API. It has 12 intercluster friends and several external modules 
depending on it using an implementation dependency, so it should be considered to be turned into a more stable API.

See also issue 107139 for some arguments.
Comment 1 Geertjan Wielenga 2007-06-28 10:32:28 UTC
Yes, please stabilize this API. It is extremely useful in many areas of NetBeans Platform development, from Visual
LIbrary API implementations to DTD/Schema representations, to WSDL editing, to practically everything relating to
editing in any application on the NetBeans Platform. Yes, it is very complex. Part of that problem can be solved by a
tutorial. But a tutorial cannot be created until the javadoc is publicly available. An the javadoc will not be publicly
available until the API is stabilized. So please stabilize it!
Comment 2 Geertjan Wielenga 2007-06-28 10:33:27 UTC
Added myself to the cc
Comment 3 maxnitribitt 2007-06-28 11:09:34 UTC
I agree that this should be stabilized. The XML multiview API is used by many projects. It could be especially useful
when adding support for some of the tons of xml configuration files out there, especially in the context of
webapplication frameworks (Web-Leaf, Spring). 
Comment 4 Vadiraj Deshpande 2007-06-28 17:56:11 UTC
I voted for this issue. I see this API is quite useful in creating powerful XML visual editors and would like to see
this API matures soon and become public. In the current world. XML files are used almost everywhere and there is a much
need for the editor. I am using this API to develop an IDE for developing platform independent, enterprise ready and
open source installer framework called openInstaller ( 
Comment 5 tomwheeler 2007-06-29 16:00:29 UTC
I also voted for this issue, based on Geertjan's blog entry from yesterday.  I have not yet used the Multiview API, but
I can say two things about it:

1.  When I am showing platform capabilities to other developers, they are very impressed by the Multiview API.  This is
something for which there is no direct counterpart in Swing, and thus a compelling advantage to build an application
atop the platform.

2.  Most applications have some sort of structured configuration file and this is a perfect fit for allowing some users
to edit it graphically while allowing "power users" to directly edit the underlying file.  There is a Swing application
where I work that would be an ideal candidate for porting to the NetBeans Platform if we could count on the Multiview
API being stable.
Comment 6 dcallner 2008-01-24 14:02:13 UTC
Good God how can you not stabilize this component.  It's key to get people to contribute SE's to the
Open-ESB/JBI-Components Projects!!!!!!!!!!!!!!!!!!
Comment 7 willfarnaby 2008-03-25 08:25:32 UTC
I feel that it is very important to see XML Multiview stabilized, published, and well-documented with tutorials, etc.

I, and many others, could use this functionality all over the place.
Comment 8 David.m Beer 2008-06-22 23:46:42 UTC
I am looking at using the xml/multiview library quite a look and would benefit from it being made stable
Comment 9 _ rkubacki 2009-06-22 04:36:44 UTC
NBAndroid project depends on it as well. There are 16 friends now (two of them outside NB core distribution). There is
no change in method signatures between 6.5 and 6.7 but people cannot use it. I know that the API had some defect but it
is embarrassing. Note 25 votes but it does not get into
because it is a task.
Comment 10 jsnel 2009-06-22 09:52:01 UTC
My projects also heavily rely on the XML Multiview Editor module - simply because it's a *great* feature! - a decision I
made early on with the assumption that it would be made into an API module in one or two releases. Now we are almost 2
releases and more than 2 years further since Geertjan talked about it in his blog [1] without much activity, despite the
fact that this <b>P2 Defect</b> is gaining support (Top 25). But really ... what can we do about it?

No, seriously what can I do? I'm just a single developer but if I can donate some money somewhere to get this bug
resolved more quickly then so help me, I will. 

Comment 11 Petr Jiricka 2009-06-22 10:04:02 UTC
Hi Radim, good to hear from you again! One way to stabilize this API with minimal effort would be to submit it for
stabilization in the current form - it will either be approved as it is, or not. 
Meanwhile, if people are willing to use this API as a friend contract without stability guarantees, we can add more
friend modules, just let us know your module id. Should I add the Android module as a friend - and which of the 10 modules?

> this P2 Defect

Note that this issue only became a P2 defect today, previously is was a P2 task. Per the bug priority guidelines, P2
defect is not appropriate, changing to P3:
Comment 12 Geertjan Wielenga 2009-06-22 12:01:29 UTC
Given that there are so many votes for this issue, and that this issue has existed for so long, without any movement of
any kind, with even someone offering to pay money for it being fixed (and probably others would be willing too,
including me myself personally), changing it to a P3 seems strange. Or you should submit it for stabilization yourself,
rather than asking someone else to do so. 
Comment 13 Peter Nabbefeld 2009-06-22 14:28:45 UTC
Don't understand, why there're so much friends - IMO the API could at least be made public and marked unstable, just as
others, too. IMO, friend APIs should only be used for access inside of kits. Whenever an API is needed outside of a kit,
it should be public, not friend. How open is an application, that hides it's APIs to users?
Comment 14 Vadiraj Deshpande 2009-06-23 04:03:13 UTC
I agree with Geerthan. Given so many users and high number of votes, this API should become a stable API soon. I can
invest sometime to work on this.
Comment 15 Vadiraj Deshpande 2009-06-23 04:03:30 UTC
I agree with Geertjan. Given so many users and high number of votes, this API should become a stable API soon. I can
invest sometime to work on this.
Comment 16 Petr Jiricka 2009-06-23 14:42:57 UTC
Ok, starting a fast-track API review per the review steps:

The proposal is to change the current xml.multiview module, which is already a friend API, to a stable/public API. I am
attaching a Javadoc for this API. 

Let's start by collecting comments about the current state of the API to see what it would take to turn it into a stable
API. Later on, we need to decide whether we can make a long term commitment to maintaining it as a stable API, and who
should make this committment (community contributions welcome). The alternative is to publish it as an unstable API, or
not to publish it. Thanks. 
Comment 17 Petr Jiricka 2009-06-23 14:46:10 UTC
Created attachment 83933 [details]
Current Javadoc
Comment 18 Petr Jiricka 2009-06-23 15:49:23 UTC
Changing back to TASK, the number of votes or willingness to pay money is not a valid justification of a P2 bug per
Comment 19 Milan Kuchtiak 2009-06-23 17:22:10 UTC
I see several, very high level, subtasks that should be done to consolidate and stabilize this API:

MK01: separate Graphical(Swing) part of XML Multiview from XML part: the graphical part should not depend on classes
from XML part
      The goal is to enable using this graphical part separately:
      - some clients don't not want to build they editors over XMLMultiViewDataObject (WS Customization editor)
      - graphical part may be useful for other mime types (JSON, subset of java annotations etc.)

MK02: consolidate the public contract in Graphical(Swing) and XML parts of API
      - too many public methods
      - the usage is too complicated
      - implement modern design, e.g. generics, where appropriate
      - improve Javadoc
      - write more examples

MK03: simplify and specify clearly the synchronization capability of this API to avoid exhausting investigation, by the
clients, to understand how it works. Nowadays, the synchronization is a nightmare of XML Multiview.
Comment 20 David.m Beer 2009-06-23 18:34:35 UTC
I agree with your points. I may not use this API as of yet but have looked into it and found it quite difficult to
grasp. I am willing to help with reviewing guide or tutorials if necessary.
Comment 21 _ rkubacki 2009-06-24 04:25:35 UTC
We have a dependency in The problem is that adding more and more friends do not scale
- your commitment is to notify all the groups maintaining your friends before you make changes per

Defect vs. task: I am against the task. Release criteria do not care about tasks and those are often ignored for ages.
P2 might be too aggressive. Though it affects another developer's progress: people using NetBeans as a platform cannot
use it correctly and we are encouraged to look for a fix. 

Technically: we want to use XmlMultiViewDataObject and build a multiview (using DesignMultiViewDesc). 

I agree with Milan that there can be a clean-up to expose only limited set of entry points. I mentioned our use case. 
Comment 22 tomwheeler 2009-06-26 22:07:25 UTC
TW01: The MultiViewElement class has many methods are intended as callbacks for notification of window system events,
similar to those defined in the java.awt.event.WindowListener interface.  As implementing classes will likely no little
more than provide a no-op for most of those methods, I think the MultiView SPI would be improved by having an abstract
class that provides no-op (or otherwise sensible default) implementations for many of these methods, just as the
abstract WindowAdapter class does for WindowListener.

The following methods would be a good fit for no-ops:

    public void componentOpened()
    public void componentClosed()
    public void componentShowing()
    public void componentHidden()
    public void componentActivated()
    public void componentDeactivated()

while these could have simple default implementations that would work for most cases:

    // return null
    public UndoRedo getUndoRedo()  

    // return null
    public JComponent getToolbarRepresentation()

    // return CloseOperationState.STATE_OK
    public CloseOperationState canCloseElement()

    // have a transient member variable (callback) and use it to hold a 
    // reference to the MultiViewElementCallback reference supplied here
    public void setMultiViewCallback(MultiViewElementCallback mveCallback)

    // return callback.createDefaultActions()
    public Action[] getActions()

    // return Lookups.fixed()
    public Lookup getLookup()

Doing this means that a subclass need only provide implementation of one method (getVisualRepresentation()) instead of
13 as one must now do when implementing MultiViewElement.
Comment 23 sreimers 2009-06-28 10:13:44 UTC
SR01 Build a multiview Swing abstraction that is not dependent on DataObject (just uses Lookup and such APIs). This will
increase the possible 3rd party adoption.
Comment 24 tomwheeler 2009-06-28 22:05:25 UTC
Correction to TW01: public JComponent getToolbarRepresentation() should return a blank JPanel, because IIRC returning
null will case a NullPointerException in this case.  

Also, adding a transient member variable for the MultiViewElementCallback implies that the adapter class would either
provide a corresponding accessor method or that this member would have protected visibility.
Comment 25 Jaroslav Tulach 2011-08-16 09:33:57 UTC
Stalled review I guess. Return back when there is new interest in a review.
Comment 26 Geertjan Wielenga 2011-08-16 09:36:21 UTC
Lots of interest in this. People have been asking for a stabilized XML MultiView API for many years.
Comment 27 jsnel 2011-08-16 10:57:03 UTC
I agree with Geertjan, plenty of interest here but I do not have the expertise to assist in the review of the API and perhaps I am not the only one in that.
Comment 28 David.m Beer 2011-08-16 10:59:14 UTC
Would be great if this was finalised properly as an API
Comment 29 Peter Nabbefeld 2011-08-22 14:18:04 UTC
Waiting for stabilization since 4 years, already. However, some issues would probably be solved by implementing MultiViewElement.Registration.

For my purposes just thing e.g. about JavaHelp:
1. It would make sense, to make only the helpset itself visible, not the map etc.
2. Looking at the helpset as XML and as a tree of links would also be necessary.
Currently, the second could be implemented only by the use of implementation dependency. How can the first item be implemented by using only public APIs?

How can I implement DataLoaders for XML files, if the usual MimeResolver strategy doesn't work?

These questions are defining my wishes to an XML (multiview) API. Well, the last issue is not multiview specific, but I'd need it, too, in a multiview environment.
Comment 30 aa.medina 2011-10-30 19:39:40 UTC
I hope the Multiview API becomes a standard API in Netbeans. It provides important services for applications that depend heavily on XML for configuration and interactions. I am using a lot.
Comment 31 nevvermind 2014-01-01 13:30:55 UTC
Newbie NB-er here.

I can confirm that, if this API was stabilized, it would make my plugin development much easier. And it's even not JAVA related: it's PHP. There are xmls here, too.

I'd help, but currently I'm playing with NB to learn Java and viceversa.
Comment 32 Jaroslav Tulach 2014-11-05 09:26:16 UTC
Dormant, I guess.