What to do with the Beans Module
Current State (6.1 dev)
Beans module functionality split into several parts:
- DONE Issue 122104 Bean Patterns nodes moved to navigator
- 70% Issue 115824 Beans Templates
- DONE Issue 122114 Add Bean Property feature
- 0% Issue 122094 Bean Info Editor. Current Idea is to use 5.5 Bean Info Editor as a new view in Editor (similarly to Design View for Swing forms)
- 0%,Nice to have Issue 100758 Beans Refactoring
See Issue 90907 for more information.
- Beans module has been removed from the 6.0 release
- Some support for beans is in editor (e.g. getter/setter generation on Alt+Insert)
- There is demand for resurrecting it
- Time and resource is limited we need to decide what we put back and what we will ignore.
- Rewrite is non trivial
- Not all features in the old module are state of the art
- branch bug90907_experiment was created to experiment with Beans module ressurection
- Wade Chandler WC01 I know in the old editor generating the getter/setter didn't allow the getter/setter to be named differently than the standard bean patterns. For most things this is good, but for some properties such as certain boolean properties being able to have a different read method makes sense. Especially for situations where the word can makes more sense than "is" and relatively similar situations.
- In the old editor a dialog would come up which allowed the user to change the method names. The issue from a bean perspective was that if the user chooses a name for the reader or writer which isn't in the standard patterns there was no linkage in a BeanInfo class which would allow this to remain the read/write method. The developer would see the property show up as a read only property or write only (rather strange) in the bean patterns. We could use this same concept and if the methods do not match standard bean patterns add the read/write methods to the property descriptor returned from the BeanInfo. I suppose doing it for one would force us to have to generate PropertyDescriptors for all properties at that point.
What's wrong with the old module
- Too much GUI.
- Wizards for properties and event sources look old and ugly
- Wizards for properties only offer "well known" listeners
- BeanInfo is using guarded blocks (hard to avoid)
- Generated code is not templates based and thus not customizable by user
- Wade Chandler WC02 In the item "Too much GUI" are you referring to the dialog for the BeanInfo editor? I know I mentioned this in IZ as something which could be moved to the Nodes, and I suspect in this case the ideas mentioned in the issue will be included as nodes in the navigator view on the members NavigatorPanel. Is this correct, or will we have our own Nav panel? We are using a NavigatorPanel named "Bean Patterns", and it has its own tree view
- Move Beans to navigator
- Add as many beans features into editor as possible.
- Add property node expansion
- Add filtering
- Remove the property sheet
- Use free marker + Retouche for code generation
- I don't know what ever to make it better...
- Wade Chandler WC03 In the item "Add as many beans features into editor as possible", do you have any ideas yet as to which ones and how they will be accessed? Do you want me to conceptualize or do you want me to wait on a specification from you?
- Wade Chandler WC04 In the future I think the following would be good (I'll add more to this same comment as we work on this)
- Allow bean customizers to be created by launching the new file wizard starting on the step after a JPanel has been selected as the UI form to create. The class will be registered as the class to return for the customizer class from the BeanDescriptor.
- Allow custom property editors to be created by launching the new file wizard starting on the step after a JPanel has been selected as the UI form to create. The class will be registered as the class to return for the property editor from the returned PropertyDescriptor for that property in the getPropertyDescriptors array.
- Allow users to define the read/write methods of their beans. This comes in real handy for boolean properties where "is" doesn't make sense starting the method name. I have at different times had to think really hard to get is to work correctly as the boolean method name starting word so I didn't have to do much manual work in BeanInfo code.
- Add refactoring support to the beans module: we need to allow the user to use refactoring along with renaming a property or event method and we need to listen for them as well