db-torque-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alan Hodgkinson <a...@softxs.ch>
Subject Suggestion: A change to Torque (populate & XML)
Date Fri, 10 Jan 2003 18:01:49 GMT

  To Cocoon users: Sorry for the off-topic post. 
  This is just a heads up to let you know what _may_ 
  be coming and to solicit your lobbying efforts for 
  the Torque changes I am proposing below.

Dear All,

I'd like to have some new functionality in Torque. My 
ultimate goal is to implement the enhancements necessary 
to make Torque a useful component when developing with

  I'm not hung up in implementing the changes exactly
  as suggested here. I've written the following mainly 
  to clarify my ideas and solicit better suggestions 
  from those who know more. That said, I've tried to 
  keep things simple by separating my requirements from 
  the solution and suggesting a 'small-footprint' change 
  that I can quickly get up and running.

  I just want a solution for my requirements and I'm 
  willing to write and test the code and DOCUMENT 
  whatever we collectively decide to do. But, barring
  other suggestions, my analysis thus far shows that 
  I do require changes to Torque (and I'm not a Torque 

  On the non-technical side, I'd like the community,
  particularly the Cocoon users (who will get a new tool 
  for their toolbox), to share the benefits. After all, 
  the Torque-ers have already helped me.


1.1 Populate Torque objects, e.g. objects which extend 
   BaseObject, automatically from a Map or Hashtable. 

     // users is an instance of a Users Torque object
     // generated by Torque.

     users.populate( myHashFromMyCgiInput );
     if ( user.isValid() ) { // isValid is business logic
     } else {
       throw new BadUserInputException(); // or whatever..

   Ideally the populate() method would accept String 
   representations of fields and convert them to the 
   appropriate native types (as well as accepting native 

1.2 Allow Torque objects to emit SAX events to a
   Content handler. 

   Note: most Cocoon processing is done via SAX events.

     // myContentHandler is a Cocoon transformer that
     // ultimately transforms it's input into fancy 
     // HTML suitable for web browser presentation.
     // It has been opened and a document has already 
     // been started

     myUser1.toXml( myContentHandler );
     myUser2.toXml( myContentHandler );
     myCompany1.toXml( myContentHandler );

     // ..etc.. until done.. then close the document.

   The toXml() method merely emits the tags and content 
   associated with to it's database record. E.g. the 
   table name '<user>' and the contained fields, 
   '<Userid>1</Userid><Username>joe</Username>' etc..

   Note: If you accept this, then you'll get XML as 
   Strings more or less for free. (And you'll get free 
   Steak Knives too.. :)


  Read the first disclaimer again: I'm open to other,
  better solutions.

2.1 Populate()

  With a bit of Java (and personal :) introspection and some 
  helpful suggestions from the list members, I feel I can 
  implement the populate method. The tricky part will be
  getting all the type conversion working.

  This task would be made MUCH easier if there were a 
  method getFieldNames(), that returns null (or throws an 
  exception) in BaseObject. It would be over-ridden by all 
  the Torque generated classes). 

  This would allow applications to use Torque objects in a 
  generic way. They could simply iterate over all the fields, 
  using BaseObject's (overridden) getByName method.

2.2 Sax events

  Given the getFieldNames method in BaseObject, it becomes
  a trivial exercise to implement the SAX event generation
  directly in BaseObject. It is would also be trivial to 
  implement a toXml method, that returned the XML as a
  String. (..and you'd get free Steak Knives too. :)

  The only problem is to get the table name (for placing in
  the top-level XML tag). The easiest solution would be to 
  add a null (or exception-throwing) method getTableName to 
  BaseObject, which would be overridden by the generated 
  Torque objects.

  Note: since I pan to use Cocoon, I have no need of filtering 
  or forcing the XML to conform to any particular layout. 
  Cocoon allows me to easily use XSLT to perform any required 


3.1 Add to BaseObject.java:

    public List getFieldNames() { return null; }
    public String getTableName() { return null; }
  They could alternatively throw a 'not implemented' 
  exception the way getByName currently does.

    void populate( Map or Hashtable ) { ... }
    void toXml( ContentHandler ) { ... }
    String toXml( ) { ... }
      or toXml( Writer ) { ... }

  I'll supply tested code with Javadoc for these methods.

3.2 Add to Object.vm:

    public String getTableName() { return "$table.Name"; }

  I'll need to test to ensure that the Torque/velocity variable
  name is correct.

3.3 Collect the free Steak Knives :)

   Sorry, but we're all out of Steak Knives :(. 

   ..but I will write a few paragraphs of documentation for 
   the Torque web site and some Cocoon Wiki documentation when 
   I get this working with Cocoon. (That's BETTER than steak 
   knives, right? :)


4.1 Is there a Torque committer willing to 'sponsor me'?
  No, not to sponsor me to become a commiter, just to commit 
  the changes.

4.2 I'll supply the changes in whatever format is easiest.

Best wishes and thanks in advance (especially for reading 
this far),



  Nothing happens in a vacuum: Others have helped. In particular:
    Michael Bain - For sharing your introspection based solution.
    Gareth Boden - For sharing your Betwixt based solution and 
      giving me a bunch of insights.
  Without your efforts, I would have been stuck. Thanks guys!

P.P.S. Sorry if this is a duplicate posting. I originally mailed 
to the dev list at 10:30 this morning, and now at almost 18:00 
I've yet to see it on the list.

View raw message