On 4/11/07, Jim Paul <jimpaul@xxxxxxxx> wrote:
Ed,
Thank you for taking the time to craft an answer. In the single
threaded, proprietary database (Pick), procedural world I'm usually in,
things work fine, but I guess that is because the data arrives at the
user interface very quickly. If I understand you, the data model will
change at it's own pace, depending on network and database server speed
(asynchronous, own thread is the terminology?).
The single threading would simplify the predictability but the ideal
is a set of decoupled components that can be placed on any panel and
just work. All the references from component to data bind components
to a ui scope.
The coolest solution I found we implemented on a past project in C#
winforms. It used a global event system to publish data. Arbitrary
subscribers listened for the data and displayed it. We had the ability
to cut a button from one panel and place it anywhere in the UI and it
would just work. Now that was sweet.
http://esumerfield.blogspot.com/2005/03/decoupled-ui.html
So does the data model have a reference to all of my controls (mostly
fields) so it can change their text properties when a data element
changes? Or is it something more sophisticated like firing "change"
events and registering controls to act on them?
UI components know about their swing models
(javax.swing.text.Document). Their swing models know about the data
model (your data). Each piece of data has a property change registered
for it with an associated ui component. So firing property changed for
a data item will cause a set of ui components to update themselves.
I worked on my app last night and found the default behavior of Swing
controls was pretty wild and not what I expected (changing the columns
and rows in GridLayout did wild things. Changing the size of a JFrame
had no obserable effect). Yes I would like some non-J controls that are
easier to position and have good default behavior. For example, I think
HTML tables and fields have good default behavior for laying out forms.
Any suggestions.
Swing has a very specific way of managing its layout. Each component
can have an associated Layout. The layout is responsible for deciding
where components should be placed. Each component is related to a
layout so the layout can run through each of them and ask them what
their preferences are. Some components might have some minimum size,
some just a preferred size that the layout can override if it wants
to.
There are lots of different layouts to choose from but you will only
ever use one and you will hate it but you have no choice. The
GridBadLayout is the most powerful, worst, most excellent, horrible
thing you could imagine. I will let you play to understand what I
mean.
Basically, you need to know how to craft the properties of this layout
to get anything to looks halfway decent.
There were some advances in layouts last year. NetBeans now comes
packaged with a few new layouts that don't come standard with java.
Originally SpringLayout was one of them but I think it may have been
added into jdk 1.4. Google up a few of them and see what you like. We
haven't had much luck with them but your app may benefit.
NetBeans comes with a really nice UI designer that will help you
layout your components. Eclipses Visual Editor isn't nearly as nice.
Something to consider when using visual designers is how to isolate
the code that they generate from the code that you write. We use an
XDesign base class for each XPanel class that we write. The designer
outputs code to an initialize method in the XDesign class. Then in
XPanel we override initialize, assign the instance variables with our
ui components and call the super method to lay them out. It works
pretty well.
I created a class called FieldDefinitions. It will contain the SQL
table names, field labels, data type, order of appearance, possibly the
control type.
Jim
--
Ed
|