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 18838 - Allow "automatic glue" between java beans and the form editor
Summary: Allow "automatic glue" between java beans and the form editor
Alias: None
Product: guibuilder
Classification: Unclassified
Component: Code (show other bugs)
Version: 3.x
Hardware: All All
: P1 blocker with 2 votes (vote)
Assignee: issues@guibuilder
Depends on:
Reported: 2001-12-20 00:05 UTC by Rochelle Raccah
Modified: 2007-11-26 11:27 UTC (History)
4 users (show)

See Also:
Exception Reporter:


Note You need to log in before you can comment on or make changes to this bug.
Description Rochelle Raccah 2001-12-20 00:05:07 UTC
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
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.
Comment 1 Tomas Pavek 2002-01-03 13:48:28 UTC
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.
Comment 2 Rochelle Raccah 2002-01-03 23:36:26 UTC
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

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

private void acceptPanelContents

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

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
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.
Comment 3 Marek Grummich 2002-07-22 09:58:42 UTC
Set target milestone to TBD
Comment 4 Marek Grummich 2002-07-22 10:02:39 UTC
Set target milestone to TBD
Comment 5 Tomas Pavek 2005-05-13 17:42:54 UTC
Closing an old issue.
Comment 6 Rochelle Raccah 2005-05-13 23:59:14 UTC
Why?  This is still a request for something useful and would serve to
distinguish the NB Form Editor from other IDEs.
Comment 7 Tomas Pavek 2005-05-16 14:17:00 UTC
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.
Comment 8 Rochelle Raccah 2005-05-16 20:18:10 UTC
Comment 9 Tomas Pavek 2005-05-17 11:13:53 UTC
Changing target milestone to future.
Comment 10 Pavel Buzek 2005-11-01 21:43:17 UTC
> 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

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).
Comment 11 Petr Jiricka 2005-11-02 13:17:20 UTC
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.
Comment 12 Petr Jiricka 2005-11-23 18:04:05 UTC
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?"
Comment 13 _ alexlamsl 2007-11-23 16:39:02 UTC
is this still relevent with NB6?
Comment 14 Jan Stola 2007-11-26 11:27:05 UTC
I believe that the ideas from the original proposal have been implemented when we introduced support for beans binding 
=> closing as fixed.