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.
Resurrect the "Bean Patterns" functionality to some extent in 6.0
Let's ignore Beans for this release we have more important things to do I guess.
*** Issue 100028 has been marked as a duplicate of this issue. ***
It would be a pretty sad state of affairs to ignore beans with all the new functionality in the Form Editor. This needs higher priority, and it needs to be marked as a DEFECT not a FEATURE as it is an integral part of Java development as JavaBeans are required every where including EL in JSP, Bean Binding, NetBeans Module Development (even TCs are JavaBeans).
This is little too general statement. Could you please specify which features of the old Beans module you want to see be brought back? Obviously saying that all is not the right answer :-). Thanks
Well, from a JavaBeans perspective the "Bean Patterns" Node needed to be enhanced and expanded not removed. All the BeanInfo editor is needed. The other features of being able to add properties need to be available as well. The nice thing about all those features is they aid the developer in JavaBean development. One of two things can happen here. The features can remain visible as now and be enhanced a little bit more in the future or the "Bean Patterns" Node can have a sub-node for the BeanInfo Editor there, and the BIE not be shown in a separate dialog. All the functionality in the beans module at least which is accessible from the sub-node in the explorer view is extremely useful. So either we see what we see in NB 5.5 or we see: SomeClass.java -Bean Patterns (with a nice Java Bean icon ... context menu "Add BeanInfo" and "Remove BeanInfo" if BeanInfo is available ... needs undo or can rely on local history) --someProperty (these are available as they help with beans with no BeanInfo) --someOtherProperty --Bean Info (if a BeanInfo is added to the bean this becomes enabled ... this contains the information from the dialog Bean and BeanInfo nodes, is there any real use for multiple BeanInfos returned by the getAdditionBeanInfo method?) ---Properties ---Event Sources ---Methods Then we can add methods, properties, and event sources from this area. So, not only can we edit the BeanInfo information, but we can also add the entities (methods, properties, event sources) here so we can manage them right away. This will make the BeanInfo editor that much more useful. The sub-classes will still need their sub-nodes visible under the .java files, and then the "Bean Patterns" node will need to be available for them. I don't like it, but I would even settle for a NavigatorPanel being registered for .java files. The only issue here is without the Java API allowing us to tie into the Navigator panel with some type of an SPI or API to allow adding a Node in the Members hierarchy in the Members panel for each class we will need to examine the class file for all sub-classes and display the full hierarchy in the BeanInfo NavigatorPanel. Which seems to move the UI consistency issues to a different level. I think having the nodes available in the explorer view is better for now until something can be worked out with the Java project or something else can be figured out. So, that all being wrote, is there a resource need here? Do you want some help designing and building this? Can you move design discussions to the community wiki? The given URL seems to be some VPN access only URL as I can not access it. This is a must have for NB 6.0 as Beans are used every where, and this pushes the ease of use out the door in favor of the developer doing all the BeanInfo work by hand. I think the other features such as Customizers and Editors should be able to be started from the BeanInfo editor instead of just being able to have their class names entered. So, we need a scheme to allow the user to select a class name from he known classpath, enter in the name, or create a new customizer or property editor. This will make it that much more efficient for developers working on beans. Also, properties and events can have differently named methods than the standard bean patterns. These should be able to be defined and chosen by the developer. There seems a lot we can do here to make JavaBean development better instead of worse by removing features.
>This is little too general statement. Could you please specify which features of >the old Beans module you want to see be brought back? Obviously saying that all >is not the right answer :-). Thanks Just some comments. This is part of the problem with not asking users before removing a feature or features. You used the terms "general statement", "old Beans module", and "Obviously". Yet, if you were to ask JavaBean developers which features they want to remove from the BeanInfo and Bean Patterns editor you would more than likely get a much different set of responses. NB 6.0 is not out yet. The features are in NB 5.5, so it isn't exactly old functionality. I can't think of any of the Bean Info editor functionality I want to live without. I use it all the time, and I certainly do not want to end up typing the monotonous code associated with a BeanInfo class over and over again. BeanInfos are commonly and generally needed with JavaBeans. I have answered numerous questions on the topic over the course of the past few years on the NB users mailing lists. I have shown people how to create JavaBean libraries for inclusion in the IDE and in the palette using the BeanInfo editor. I have been planning a tutorial which covers this as I have answered it quite a number of times. The features not only save time, but they help newbies get up to speed on JavaBeans development.
OK I see, all the functionality is needed. Now the only problem is to find some volunteers who will port it to 6.0. Thanks for the long description. It is a little surprise to me that someone likes the guarded block based beaninfo. I might try to do at least something myself. But there is very little time so as said before we need some volunteers. BTW: IMO asking the whole user base if you can remove a feature is nonsense. There is always someone who will say you should not. The right question sounds very differently. But it is probably not "politically correct" to discuss this in open source bug tracking system.
Yes, you are going to have some dissenters with any question. The main point is that a few not make major decisions for the whole without good input. Otherwise who is the IDE helping? We have got to get to the point where we are getting more community feedback. Yes, talking about it here isn't politically correct, but we have to start some where. Anyways, we can deal with general community issues in a different place and time. I'll volunteer to help work on the features as they are important to me. I have some features I'm to help with in the Form Editor as well. So, these will tie me up pretty much in all my spare time ... day job isn't working on NetBeans features, but instead I use the IDE for my daily job, and I contribute where I can. We need to talk to some of the folks who were part of removing the sub-nodes on Java files I suppose. That is unless you have some good ideas as how to support it better. I like the BeanInfo being under Java nodes because this helps work on multiple beans at the same time as the view remains static while working on multiple files. If we put it in a NavigatorPanel what will happens is: 1) User selects a .java file. 2) The first NavigatorPanel is shown (Members Panel) 3) The user has to select from a combo-box the Bean Info panel. Currently (5.5) the user can have multiple files expanded to the "Bean Patterns" node. They still have to access the BeanInfo Dialog however. To me it would be more productive to have the BeanInfo editor et. al under the .java file "Bean Patterns" sub-node to make it more useful for working on multiple files. As far as guarded blocks are concerned, I don't mind so much as it keeps me from having to do so much manual labor. However, there may be some who object. We can either tell them they can still add the BeanInfo manually and do it all by hand, or we can look into the new Java support and see if there would be some way of not forcing it to be guarded block protected (we would have to be able to discern the BeanInfo patterns through programming though...might be more trouble than it is worth). Do we need to setup a wiki page on the public wiki to start working on the design? Others viewing this comment, do you have any ideas about the UI of BeanInfo editing?
I should add to the user actions list: 4) When the user selects another .java file or comes back to a file they were previously on steps 1-3 must be repeated every time. Not very efficient for developer time when working on a bean library.
Hello, one of my wife's gripes about NetBeans is that she does not like the intermediate nodes under java nodes - she would like to have there directly methods/fields under the java node. One might ask the obvious question: Where have all the looks gone? Long time passing Where have all the looks gone? Long time ago Where have all the looks gone? Girls have picked them every one When will they ever learn? When will they ever learn? David
Do you want to know? :-) I think you know.
Beans resurrection branch created and first very basic rewrite to Retouche checked into it. For more info about status and to discuss the issue please go to: http://wiki.netbeans.org/wiki/view/Beans_90907Experiment
I created new issue 103550 which is somehow connected to this one, though not duplicate of this. I believe that the current state of explorer window (that java files don't have children) is ok. The place for java file structure is in Navigator. And as I described in issue 103550, there should be and option to show beans properties in Navigator and Members windows. Concerning the Bean Patterns node: I think its location was quite non-intuitive. I discovered that there is such thing in NetBeans after long time of using IDE. So perhaps it should be somewhere else, maybe as separate view (window) opened via context action, based on the old Bean Info Editor, or somehow merged with Navigator and/or Members view?
Your issue is a duplicate. This issue is going to address it. Please see the wiki page referenced in this issue.
*** Issue 103550 has been marked as a duplicate of this issue. ***
I need to explain what I wanted in issue 103550 in more details: My idea was to have a "lighter" version of Bean Info: instead of Bean Patterns node I just wanted to add new node type into Navigator and Members window. Now there are "field", "method" and "constructor" nodes. I wanted to add "property" node type, and the new filtr to turn on/off showing properties nodes. This is because I don't treat all the getXXX and setXXX methods as real methods. Semantically, they are not the real methods, but they simply constitue the property. So in order to have the clear view of class members (in navigator or members window) I should be able to see one property node instaed of each setX/getX pair (or getX if read only) methods. Displaying setX/getX methods make Navigator/Members tree bloated. This means that we need some new filter to switch between combinations like: 1.display all methods ("real" and getters/setters) - as it is now 2.display "real" methods only and properties 3.possibly other combinations (only "real" methods and no properties, or only properties and no methods) This becomes a bit complicated, but I believe it could be really useful. Perhaps we need to have two new filters: "Hide setters/getters" and "Display/Hide properties" - this should enable us to display all views mentioned above. The Bean Info And Bean Editor I treat as some separate and more coplicated/detailed thing. But it should not be thrown away, obviously. BTW: the wiki mentioned in this issue is not reachable: before Access Denied, now I get Server not found.
I got a "deal breaker" comment at JavaOne today from a visitor to the NetBeans pod. He said he wants to recommend NB for his entire team, but refactoring won't rename a bean property. If you rename the field, the getter and setter is not changed. His workaround was to open the class node and rename the bean node, but that's gone in 6.0 M9.
vaughn: AFAIK workaround to rename a property via the Beans node does not help much. Yes it renames field + getter/setter but without any refactoring. We would like to add this to the Rename Refactoring action.
Some improvements done in the branch: 1) Tree does not collapse any more 2) Icons for classes 3) Handles innerclasses 4) Types for properties shown See screenshot
Created attachment 42277 [details] screenshot
To me this would make sense to be consistent and have all bean work within the bean patterns navigator panel. The beans module really needs to add support for refactoring as we are getting ready to add to the form module. Then refactoring renaming of a bean pattern method would need to be thought out. To the regular refactoring it would just appear to be a method name which alerts refactoring support in other modules, and to the beans module it would be renaming a property or one of the setters or getters which would in turn create a refactoring transaction and alert other modules. I suppose renaming of standard property patterns in refactoring would be fine, but obviously the beans module needs to be aware of the refactoring to update property descriptors etc if they are being used which would need to be the case if we start supporting the user using methods outside standard property patterns (for instance methods which begin with can instead of is). We need to allow the user to choose at refactor time whether to keep the method under control as a property setter or getter (a pattern set/get/is doesn't have to be used and the read/write method can be determined by a PropertyDescriptor) or if they want this method to no longer be part of a property. We would also need to determine if the methods parameter set is changed whether it matches anything a property can use. If not then some how the user needs to be informed (if controlled under BeanInfo) this method will not be able to be used as a property setter or getter...anyways, that is the general idea, to have it tied to refactoring.
>BTW: the wiki mentioned in this issue is not reachable: before Access Denied, >now I get Server not found. Yes, not the one in the URL, but the one mentioned in comments on http://wiki.netbeans.org. Petr, can we set the nb wiki page to the URL, or is the link in the URL needed by your team?
Feel free to change the URL. All that "we need" refactoring/beaninfo means. You will do it? Just for record for me this is out of scope for 6.0 for sure. Except rename refactoring will probably rename getters and setters as Jan Pokorsky mentioned that's all.
Petr, "we need" really just means what we need to do. I don't think all of it can be done by 6.0. I have committed to helping the form project implement refactoring support. After that I will be glad to work on this part as I can. In the wiki I added refactoring support as part of the "future" section.
I've installed 6.0 M9 and cann't find the BeanInfo-Editor. I thought this was an bug or the BeanInfo-Editor is moved to an other place - but now I read (coincidentally) that the BeanInfo-Editor should die - is this realy true? I used the BeanInfo-Editor to generate and modify *BeanInfo.java for my custom Beans (=Swing Controls - added to GUI-Palette), toogle include Properties and Methods, configure Properties (Expert, Hidden, Description, Property Editor Class ...). There is a lot of code generated by the BeanInfo-Editor in *BeanInfo.java - would be very painfull to code this. It's very important for me that I could use the BeanInfo-Editor in future (maybe as plugin or submenu of a submenu of a...)
I meant to post another note earlier than this. I wrote Petr and we decided we are both too busy for this to make it into the 6.0 release, but directly after, if I remember correctly, and definitely for me (I don't want to put words in Petr's mouth), the plan is to release an update through autoupdate to add it back, and then moving forward past 6.0 this should be available again.
Wade is right I think if we start working on it after feature freeze we should be able to releas it on AU in parallel with 6.0
Thank you very much! I'm happy :-)
Just wanted to add my voice to this issue, I too will miss the BeanInfo Editor/Generator. Anything that can help me code a BeanInfo is good! Bring it back from the dead!
*** Issue 105410 has been marked as a duplicate of this issue. ***
Possible workaround: Rename application to NyetBeans (http://www.m-w.com/dictionary/nyet) Seriously though, the Java Tutorial relies on this feature, as can be seen at this page. http://java.sun.com/docs/books/tutorial/javabeans/properties/properties.html I was just about to learn how to make Bean Properties, but it looks like I'm dead in the water since I already upgraded to 6.0 beta 1.
You marked the issue as started. Does it mean you are going to work on it? If not mark it as NEW again and don't do such changes in the future. If yes feel free to contact directly me if you have questions.
I'm sure he did this on accident. I think he hasn't used IZ or something. Notice he was working on the JB tutorials from java.sun.com and couldn't do them, so I would say that he is fairly new to Java and isn't working on the IDE. Lets just leave it as started, and I'll see what I can do now. I will be working on it more after Oct. 27, but hopefully I can do a bit between here and there. No guarantee on how long I will take though...work work work ;-). I think at this point it is more important to work on than the other features of form (Matisse) which the guys don't have working for refactoring, and I will then hopefully have more time to work on form later as it is more complicated than this anyways.
Sorry if I marked the status wrong. It thought with so many posts and the "Beans resurrection branch created", it must have been a mistake that it was still marked "NEW". To me, "NEW" would mean nobody had even evaluated the report. Maybe "LATER" would have been a better description. I'm not new to Java. Just new to Beans and your bug tracking system. In any case, I won't touch the status anymore.
The Bean Patterns is a funcinalidade very useful, can't be removed.
I have to concur with the rest of the comments here that this is a very strange move to make. It seems to me as if all features which are important to serious java programming (for me this includes at least both javadoc and javabeans) have been left out of 6.0 for reasons I fail to understand. Its really nice that NB can generate a lot of code on its own but what added value does that really hold when it will only turn out to be seriously harder to customize that code? And thats not even touching the subject of writing custom javabeans. To me this is a major step backwards, enough to ignore 6.0 for now.
To be honest I don't understand the last comment at all. 1) "javadoc and javabeans have been left out of 6.0 for reasons I fail to understand" - We did not have enough time/people to rewrite it. As I said several times it was not removed. It was not rewritten and thus it does not work in 6.0. Do you still fail to understand it? Are you offering help? This is open source you are welcome to send patches. Other way of having beans back soon would be to find some programmer and pay him for rewriting it. There is a free market all around you (I suppose). Are you offering money? 2) "Is really nice that NB can generate a lot of code on its own but what added value does that really hold when it will only turn out to be seriously harder to customize that code?" - Does this mean that you find it better to open some pseudo wizard for a property and type the FQN of the class (not doing any typo) and have the getter/setter than writing the fields using CC and then generate all the setters and getters after pressing Alt+Insert? Also please notice that the getters and setters are possible to generate directly from code completion. 3) The GUI of bean info editor, bean property editors and autocomment was horrible and we should think twice before we put it back. Believe me I can judge it as I'm the original author of it. :-)
Not to try to turn this into an endless argument but no; I don't understand. NB is, as you stated yourself, an open source project and fully written and setup by volunteers. It doesn't need to have a christmas release perse so that the sales will go up because its hitting the market right on primetime. Therefor one would think (or assume) that the individuals contributing to it won't be pushed or stressed to get certain things out "right on time according to schedule". And when it comes to essential parts like javabeans and javadoc I sincerely do not understand why its not being given more priority. I think it might even be better to postpone the entire release by a few months in order to generate more time and opportunities than to leave essential parts like these out. I understand the /reasons/, I don't understand /why/. Sometimes small things can make big differences. Alas; just my opinion on the matter. Can't elaborate more than that; anything beyond this will merely turn out into "I said, you said" which is pointless.
Nice try. We could certainly postpone the whole release. This would: a) make lot of people who do not care about beaninfo (other things work) wait for several months for 6.0 b) make absolutely no difference for those who do care about the old beans stuff. This is planed for 6.1 or for autoupdate if the 6.1 is too late. I.e. these guys will have the feature exactly at the same time as in you r proposal. Sometimes blindly follow the rules described in the Open Source classic books do not make much sense. I'm all for "release when it is ready". But in something of the size of NetBeans 6.0 you better consider one or few modules a product not the whole thing. Did you try 6.0 and the features which replace beans and autocomment? If yes what is exactly the feature you miss? If not then ... you should try it first. And last but not least, as you did not answer the important questions: "Do you offer help?" "Do you offer money?" I suppose the answer is no for both. Therefore we should really end the discussion. Thank you for sharing your opinion. The world is full of smart guys who will give me wise advices what to do and what not to do.
Is the same branch being used or should I work in the trunk? Is the plan in the Wiki, or at least what we have in the wiki, still relevant?
I've just resurrected beans module in NetBeans trunk. In fact I've only merged bug90907_experiment branch to trunk. Now Navigator has a new panel: Beans Panel. As for wiki page. This page is live. Not up-to-date but live. Now we are going to review the page, create plan a short UI spec.
*** Issue 123194 has been marked as a duplicate of this issue. ***
Is the beans development mailing list being utilized? I wrote to it to subscribe, but I haven't seen any messages. I didn't know where design discussions etc were taking place. I didn't know what was planned and what or who was doing what right now, but wanted to work on some feature etc.
I updated wiki page with current status.
As well, this feature is demonstrated too by Sun Java Tutorial, see http://java.sun.com/docs/books/tutorial/javabeans/introspection/index.html. There is any chance to get this as a patch or update for 6.0 or 6.0.1, or will be necessary wait until 6.1?
+1 vote to bring that beans support back!
Fixed.