db-torque-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From T E Schmitz <mail...@numerixtechnology.de>
Subject Re: Torque & Swing
Date Thu, 17 Jun 2004 18:20:49 GMT

Hello Guillaume ,

>   I have found Torque recently, and it is really helpfull to handle my 
> databases connections !  I am developping a database oriented application in 
> Java/Swing. What I am missing is a simple way to connect my Torque objects to 
> my Swing forms.  I've search the net for an open source framework that does 
> it, but I can't find it. It seems that all work is web/html oriented ...
>   Do you have any links to that kind of framework ? Or some design patterns 
> for doing that ?

I can't point you to any out of the box solutions but here are some of 
the concepts I came up with. Just beware that I chose this approach for 
my first Java (Torque+Swing) project and when I started out I didn't 
know about "frameworks". However, a few months down the line, I realize 
now that what I was looking to set up was something like a framework.

My goal was to automate some of the repetitive GUI work based on the 
information that already exist in the XML schema. For the GUI though you 
need a few more parameters for every field.

Based on the Torque/Velocity concept, I have simply added more 
templates, which generate a whole lot of additional code used in the 
database, business and application layers.

I generated an XML config file, from the schema, which contains some 
extra field information needed for the GUI. The generated config file is 
a *Base.xml, additional manually entered information (for instance I 
have minimum/ maximum display widths) goes in the corresponding *.xml 
file. Both XML files are pulled up via Jakarta Commons Configuration. 
For VARCHAR columns the GUI fieldspec contains, for instance, the length
of the field. For NUMERIC fields, I generate a format (###.##). From the
XML schema I also know whether a field might be a required field.
The label text information is read from ResourceBundles - the properties
are tied to the FieldSpecification by naming conventions.

I have created a class FieldSpecification, which keeps all this config
information for each display field, and based on that, associates the
right formatter with a JFormattedTextField. For instance, for String
fields, I have a length formatter, which doesn't allow exceeding the
specified number of characters.

I have another class, which creates the field and its label based on the
FieldSpecification and returns those to the GUI. Unless otherwise
instructed, a JFormattedTextField or JCheckBox is created depending on
field type.

As I keep on using the same components and virtually always lay them out
in the same way, I have written a layout manager, which requires me only
to add the components (alternating label, field, ...), which are then
displayed in two columns.

Error messages for required fields are produced from SQLException and
some error message parsing :-( . The additional information I pass in a
wrapped and re-thrown exception might contain the field that violated a
NOT NULL constraint. The field is identified via the generated
FieldSpecification used to parameterize a localized error message using 

Thus, the main GUI application code is not cluttered by layouting or
error handling code.

Admittedly this is not as sophisticated as it could be. What you'd 
probably really want is a field description file which would be a 
superset of the Torque schema. Ideally you would incorporate field 
information for data validation (range checking etc.)

With the right mix of generated and generic code you can produce you can 
reduce the clutter and produce a much more readable application code.



Tarlika Elisabeth Schmitz

To unsubscribe, e-mail: torque-user-unsubscribe@db.apache.org
For additional commands, e-mail: torque-user-help@db.apache.org

View raw message