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.
I've discussed this idea with Ian and Yarda and here are some excerpts which provide a basic description: > > > > For example, say I have an Employee class with fields and/or get/set methods for name, > > > > address, department number, etc. Now I want to build a form file and it has some text > > > > fields, combo boxes, JTable, etc. Can I build it such that a text field is associated with > > > > the Employee's name so it is populated from there and changes to the text are propagated > > > > to the Employee object? > Something like: > 1. the user creates the form, adds all the components > 2. he creates a field in the code holding the bean reference (or something similar) There is already a "bean property" in the form wizard connection for properties. There might already be a 1 way foundation for this. > 3. he starts a tool (the add-on) that links the bean's properties to the components, implementing > both directions of updating (i.e. property change listeners on the bean and appropriate listeners > for changes via the UI on the compoenents)... > > Hmm, single tools action, single wizard, a week of work ;-) The idea is something like the existing jdbc form wizard except that it's reentrant and can work with an arbitrary java bean.
Interesting idea... I'd suggest the following scenario: 1. add a JavaBean to the form (e.g. something like the mentioned Employee class), 2. invoke a special Tools action on the bean (selected in Component Inspector) - which starts a wizard, 3. in the wizard, choose properties to be used (from a list of all available properties of the bean) and components for presentation of the properties (e.g. label + textfield pairs), 4. finish wizard - a new panel is added to the form containing all the presentation components for the properties; the right code is generated including event handlers on components (e.g. textfields) and property listener on the bean (updating the components). Is my understanding correct? Of course this would be only "one way" mechanism, there would be no extra (meta)data hold... I think this is an interesting and acceptable feature, but I don't think it is of P1 importance. I'm quite not sure I'll have time to implement it for 3.4.
Not quite.... I've been thinking about this some more and I'm not sure the property change and event notifications are the correct approach. They require more code changes and make re-entrant (2 way) editing more difficult. I like the following approach better 1) Consider adding a property for a top level bean set for the form. 2) Some property (text/existing value or special new value property) for a given component on the form can be configured to point at a field or get method for the top level bean (or if no top level one, then from an existing variable's) 3) Add a codegened (guarded) method called something like populatePanelContents. It goes through each of the "connected components" and populates the gui. For example, if there are textfields for name, address, dept number hooked up, it would look like this: private void populatePanelContents { nameField.setText(employee.getName()); addressField.setText(employee.getAddress()); deptNumberField.setText(employee.getDepartmentNumber()); } Note that some smarts will need to be added to handle - nulls - return type of employee.getXXX method - setXXX method depending on component type 4) Next, add another codegened (guarded) method called something like acceptPanelContents. It goes through and does the opposite. For example: private void acceptPanelContents { employee.setName(nameField.getText()); employee.setAddress(addressField.getText()); employee.setDepartmentNumber(deptNumberField.getText()); } The same types of issues (as mentioned in 3) would need to be handled and there could be some optimization of setting only things which have changed. 5) A user of the panel would call populatePanelContents when displaying it and acceptPanelContents on close/ok. Cancel would do nothing to the bean. If the user wants real-time updates, they could code that separately and just not call xxxPanelContents methods. This would be quite powerful and with the declarative info as discussed recently on the mailing lists, could allow for multiple types of front ends. How to invoke this: I see various stages of support we could provide: 1) Piecemeal from props 2) Incorporated into NFT for a form 3) As a tools action on an existing bean (like create form for this bean) 4) A wizard/customizer to help with 1) I think this is an important feature that could give netbeans an advantage... That is why I filed it as P1.
Set target milestone to TBD
Closing an old issue.
Why? This is still a request for something useful and would serve to distinguish the NB Form Editor from other IDEs.
Yes, this might be useful, but it is rather vaguely defined, would require better specification - which has not happened for more than 3 years. In this situation I was thinking the suggestion was forgotten. But feel free to reopen it. My feeling was this was rather a big extension of the form editor concept - actually seems to me out of scope of form editor - looks rather like a task for some framework (like JDNC, for example). Given our current amount of issues and tasks, I'm not quite sure when we could get to do something about this one.
Reopening
Changing target milestone to future.
> Yes, this might be useful, but it is rather vaguely defined, > would require better specification - > which has not happened for more than 3 years. 1. What is vaguely defined? I think Rochelle is actually proposing one possible solution, but the problem itself if very simple to define: provide a quick way to build swing forms for displaying and changing data (Java Beans). 2. Specification is needed for every feature. But that is not a reason to close a feature request ;-) 3. IMHO 3 years ago would have been too late. I think that data connectivity is a very real issue: you have number of back end technologies that produce data: web services, JDBC, CMP, new Java persistence API, etc. Look at Java Studio Creator for how data connectivity might look like. JDNC looks promissing, but the exact timeframe and the exact features are not clear. Currently you have to write the code by hand or use the "from connection" feature which is even more work then hand coding (let me know if I missed some better way). I think that even one way code generation would help (no guarded block, just generate the populate/accept methods and the Swing controls based on a Java bean definition for starters and let the user modify it as needed).
Agreed this is a very real and important use case and a valid feature request. Regarding the exact definition, here is my opinion: We need to make it very easy to create data-centric Swing applications, preferably without requiring the user to write any code. To get ideas, let's look at tools that were able to do this 10 years ago, such as MS Visual Studio (with Visual Basic) or PowerBuilder. That should give us ideas about the user model, the exact technology and implementation is up to us. > seems to me out of scope of form editor - looks rather like a task for some > framework (like JDNC, for example). It is too early to say whether this is a task for another framework, another team etc. We need to do the analysis first and then we'll see how it needs to be done and who should do it. Moreover, the JDNC project was suspended, to we can not rely on it. > Given our current amount of issues and tasks, I'm not quite sure when we could > get to do something about this one. You are implying that the other tasks and issues have a higher priority. We can not say that before we actually discuss the priorities. My opinion is that this item should end up is very high on the list, in which case we *must* find time for it.
More VOC from today's NetCat J2EE chat: "Christopher Atlan: okay, but so i can ask one other question: know someone a good tutorial about swing client access ejb?"
is this still relevent with NB6?
I believe that the ideas from the original proposal have been implemented when we introduced support for beans binding => closing as fixed.