Re: Confused on how to reference info stored in a JFrame
jamestechinfo@yahoo.com wrote:
[...]
My dbInfo class populates all its info into the appropriate lists
correctly. I cannot, however, get my components to see this info.
For example, I have a VendorBox, which is a JComboBox that selects the
vendor for the invoice.
My original vendorBox grabbed its vendor information directly from the
database by storing its own JDBC info and generating the SQL statement
itself. This worked fine, but is not very modular, I had to add code
to every other component that dealt with this info which would to
reference the specific VendorBox on that JFrame form. If I could get
the components to see the dbInfo for the form, I could just store the
reference to VendorBox as dbInfo.invoiceVendor and any other component
could have easy access to it by simply knowing where dbInfo was.
[...]
It seems you may not quite have grasped the idea of
separating the "view" from the "model." Instead of extending
JComboBox with a VendorBox that understands your application's
data (and may even own it, in some sense), use an ordinary
JComboBox and connect it to a VendorComboBoxModel that extends
DefaultComboBoxModel (or implements ComboBoxModel "from scratch.")
This separation addresses your problem with every gadget
needing to talk with every other gadget. Instead, each talks
to the ComboBoxModel instance, fetching data from it and posting
updates to it. To stay current with updates made, an "interested"
component registers various kinds of event listeners on the model.
When some part of the model changes, the model notifies all the
relevant event listeners, and they in turn update their
components. A lot of the pre-canned listeners and events are
strongly connected to GUI actions -- ActionListener and such --
but something like a ChangeListener makes a pretty good way to
connect components to data models.
The separation also allows non-GUI parts of your program to
interact with the model. You mentioned a bar code scanner that
(presumably) isn't managed through Swing, but its classes could
perfectly well look something up in a database and send the
information to the model, which would in turn notify all the
components that had declared an interest by registering an event
listener. Going the other way, if the operator makes a selection
or types in a text field or something, the data could update the
model -- and if the database has registered an event listener for
the update, it will be notified of the change and can generate
some SQL to update a table or something.
Reading between the lines of your frustration, I have a hunch
you might benefit from a couple sections of the Java Tutorial:
http://java.sun.com/docs/books/tutorial/uiswing/components/model.html
http://java.sun.com/docs/books/tutorial/uiswing/events/index.html
.... and there's also a worthwhile article at
http://java.sun.com/products/jfc/tsc/articles/architecture/
--
Eric.Sosman@sun.com