Torque & Swing

[Lederrey Guillaume <Ge...@LedCom.ch>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

  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 ?

  Thanks for your help !


		Guillaume
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFA0dWgW+xV6X6No3gRAp8aAKDJEl6LoJwG/B57Zt981LUyOBvx8ACgtqJ5
C628KWbQhA/GRBfvLyoFPXY=
=8xMH
-----END PGP SIGNATURE-----

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

Re: Torque & Swing

[Lederrey Guillaume <Ge...@LedCom.ch>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Le jeudi, 17 Juin 2004 20.20, T E Schmitz a écrit :
> 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.

  Thanks for your answer !

  I already have about the same idea ... Actually, I dont have an XML 
description, because putting those informations directly in the source isnt 
that much more difficult. I agree that your solution is certainly more 
elegant !  I also use a layout manager and so on ...

  I should refine my question :

  What I'm looking for is the code to actually edit the data. Something like 
database oriented components. I would like that each time a field is edited, 
the change is reflected to the Torque object (and vice-versa). It is a bit 
more complex with list oriented components (tables or comboboxen).

  The code to do that isnt really complicated, but it is very repeatitive and 
i cant find a good way to factorize it ...

  Well, if anybody has another idea ...

	Thanks !

		Guillaume Lederrey
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFA0ivYW+xV6X6No3gRAhh+AJkB4C141hX2BXYHzgOZgzzqTqHBmACg56eT
FLnOff+5EhLS23g0g6UhQTw=
=7SUW
-----END PGP SIGNATURE-----

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

Re: Torque & Swing

[T E Schmitz <ma...@numerixtechnology.de>]

Hello Guillaume ,

> -----BEGIN PGP SIGNED MESSAGE-----
> 
>   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 
java.text.MessageFormat.

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.

--

Regards,
Gruß,

Tarlika Elisabeth Schmitz

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