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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
