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 Mon, 21 Jun 2004 10:35:51 GMT
Hello Guillaume,

Lederrey Guillaume wrote:

>>Further to our discussion about a Torque/Swing framework I happened upon
>>an article about building GUIs from BusinessObjects:
>>http://www.javaworld.com/javaworld/jw-01-2004/jw-0102-toolbox_p.html

You got my head buzzing all weekend. Yes, you are absolutely right, the
  approach described in the article would be too simplistic and suffers
from the you problems you identified. However, I think encapsulating the
getting and setting is an idea worth bearing in mind. Changing data
types is a realistic maintanance issue.

I am not coming up with any complete solutions but I would like to throw
in a few points to bear in mind.

Through our discussion I have detected a couple of flaws in imy
implementation. But I still believe that you need a multi-layered approach:
a) Front-end (gui/web)
b) business layer
c) datastore layer
d) Torque generated Base/Peer layer

c implements b; therefore b acts as a factory - I instantiate my
business objects via a factory.
c realizes data store and retrieval via d
b provides a with info on business objects. I call object specification
with their field specifications (which maps to tables and columns).

Before you do anything else you need to decide which tasks are handled
by which layer. I realize now that all the object specification and
corresponding i18n resource bundles should've gone in b not a! (If you
do a swing and a web interface you want this in one place, not two!)

>   I probably need some more thinking on the subject. They are a few points 
> that are not fully clear for me yet ... I dont understand (yet) how you can 
> use this pattern with a "load and edit" process. That is : usually in a 
> client side application, you load data from a database, modify it and save 

1) The application is driven by the GUI. Application fires up, screen
has to be populated with Fields, Combos etc., data are loaded.
2) I think a builder producing a panel per Business Object is too
simplistic. I still have the need to arrange things "manually" because
fields are grouped logically into sub-panels. But rather than obtaining
a panel from the builder one should maybe just derive the object/field
specs from the business objects and then build the gui panels based on
that information. For instance, based on each field spec I create a
label/field pair. But I lay them out programmatically as and when I need
it. Not every screen shows all fields of a Business Object anyway.
3) I lay all panels out in a two-column layout. So you can create a
JPanel subclass with a custom layout manager and all you do is add, add,
add, add (alternating label/field). That's pretty clean and simple gui code.
4) Think about FK relationships. How does your framework handle them?

>   Third problem : all builders have very similar code ...  very easy code in 
> the example, but I'm very lazzy (ok, if I was coding instead of writing here 

My granny always used to say "Wer faul ist, ist auch schlau" (="He who
is lazy is clever too")

There are many repetitive tasks. The answer, I think, is to make
extensive use of Velocity templates. Spend some time trying to
understand how this works. *It's well worth it!* You can easily modify
them and add more templates. I am generating the vast amount of my
business layer classes this way. I have also modified the existing
templates to fit my needs.
You cannot generalize everything, but you can generate a whole lot. If
you want to make a change only change a Velocity template, not 50
sources. Follow Torque's example of *always* generating a Base/Extended
class pair.

What I have generalized: In the business layer, I have one interface per
BO and a corresponding Manager interface. (The manager iterface is
hand-written because there I decide what find and delete methods etc are
available to the front-end) Each BO interface inherits from the super
interface BusinessObject, where I define methods common to all BOs.

Each abstract BO class extends AbstractBusinessObject
"abstract class AbstractBusinessObject implements BusinessObject"
In AbstractBusinessObject  I have coded "equals", "hashCode" and "toString".
I generate all BO interfaces and Abstract BO classes with Velocity.

Generic approach for toString: get Jakarta Commons Lang (and all the
other most useful *Jakarta Commons* libs). There are some toString
Builder classes. I have created a GetterToStringBuilder subclassing
ToStringBuilder. It churns out the output of all getter methods of a
class up to the superclass specified. (I can give you the code).

I'm sorry if this a jumble of tips rather than a fully fledged concept.
I think I got some ideas right but my "framework" (if I can call it
that) could do with some improvement.

-- 


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


Mime
View raw message