1) Try to think about swing apps from an event driven and a data
driven perspective. The procedural model implies a single starting
point and UI's usually have many simultaneous starting points.
For example, I press a key in a text field, that data has to travel to
its swing model, it may validated causing a message panel to update,
if that change flows to the data model then there may be other visible
fields that contain the same data and a property change event will be
needed to update them.
Or, you press a button to do a search. Should the button action
routine be responsible for placing all the results into the ui
components or should a change in the data model fire property changes
that result in fields updating themselves. If you decouple your data
from the components that are displaying that data and link them with
property change events then you don't have to write all the code that
moves data back and forth.
With db work being performed on a background thread there is no way to
manage a sequential change sequence. All actions must be driven by
events to ensure that each can be published and managed independently.
This sometimes gives us problems with unpredictable sequences but that
comes down to how you isolate the action routines more than the event
problem.
So, working out a cool way to map database fields onto ui components
is great. Think about that mapping being the source of the property
change events that you register.
Remember that the changing of the data model occurs at a different
time than the save or update process.
The SQL updates will be driven by some save button action so you will
have sets of SQL that performs the appropriate DB updates based on the
button pressed. Make the pressing of the button tell the data model to
save itself. This keeps the ui/data interaction as simple as possible.
From the UI's perspective all it needs to know is that it has a data
model with a get, set, load and save method on it. The rest is
encapsulated in the model. The save button just calls the save method.
You can even get rid of the load and save methods and make them
properties as well so data model.set("SAVED", true) may result in the
model saving something but its up to the model to decide. The load
process can be driven by the first access of the data model so you get
some lazy loading advantages.
2) If you are just out to learn JDBC thats cool but you can do
straight SQL with the Hibernate API as well. The advantage of using
hibernate is that it does all the copying of the result set into your
value objects for you. Just another boat load of vanilla code that you
don't have to write.
3) I don't know enough about SWT to make a choice. If I was starting a
new project that required more than, lets say, 5 panels I would use
the NetBeans RCP. Its the most mature and is based on Swing which has
a better skill base in the market place.
4) We have talked a lot of architecture. I am an Agile programmer so
would never do what I have said the first day. Only do what you need
to do and learn to build code in a way that allows it to grow. This is
the trick that Agile is teaching us and OO tried to teach us so many
years ago.
It does help to have a vision though. The designer has two mind sets,
one for their hands and one for their minds. The mind focuses on
vision and the hands focus on minimum requirements for success today.
Switching back and forth is the hard part because they have to both
exist at the same time.
Programming is so much fun isn't it?
On 4/10/07, Jim Paul <jimpaul@xxxxxxxx> wrote:
Ed,
Thank you for taking the time to answer in detail. Keep in mind I
barely know how to import a jar file in to an Eclipse project. Swing
has a lot of job postings compared to the only other thing I know of, SWT.
Also thank you for the hint of using a single model (class?) to do the
database updates.
I a procedural language I would:
Read a record. (object? model?)
Map the record into controls.
When the user presses save, map the controls back into a record.
Write the record.
Assume for now the only type of data is varchar
What if I just store the strings from the field controls in a hash
table, and generate an SQL update statement from the field names. For
example,
"Name", "Address" would be indexes into a hash table, while also
reprsenting column names in an SQL table. Pretty clever? Stupid?
As you indicated, there is very little in the way of tutorials for Swing
and JDBC. There seems to be a lot on Hibernate but I don't want to use
Hibernate yet because I also need the SQL experience.
If you were doing a GUI project, what would you use? SWT?
Jim
--
Ed
|