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.
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.
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!
Added myself to the cc
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).
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 (openInstaller.org).
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.
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!!!!!!!!!!!!!!!!!!
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.
I am looking at using the xml/multiview library quite a look and would benefit from it being made stable
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 http://qa.netbeans.org/bugzilla/dashboards/top-voted.html because it is a task.
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. [1] http://blogs.sun.com/geertjan/entry/xwork_xml_in_multiview_editor
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: http://wiki.netbeans.org/BugPriorityGuidelines
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.
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?
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.
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.
Ok, starting a fast-track API review per the review steps: http://openide.netbeans.org/tutorial/review-steps.html#fast 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.
Created attachment 83933 [details] Current Javadoc
Changing back to TASK, the number of votes or willingness to pay money is not a valid justification of a P2 bug per http://wiki.netbeans.org/BugPriorityGuidelines.
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.
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.
We have a dependency in org.netbeans.modules.android.xml. 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 http://openide.netbeans.org/tutorial/api-design.html#life 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.
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.
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.
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.
Stalled review I guess. Return back when there is new interest in a review.
Lots of interest in this. People have been asking for a stabilized XML MultiView API for many years.
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.
Would be great if this was finalised properly as an API
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.
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.
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.
Dormant, I guess.