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