Hey folks,

     I'm working on a project where I have a fairly complex, yet
fairly straightforward set of java objects that are generated by
querying a database.  I want to instantiate a JACL interpreter and
then pass it this set of objects to run a script to sort and sift the
objects and eventually select some subset (maybe a single one) of the
sub-objects, and return it. The idea here is to allow maximum
long-term configurability of how the subset is selected by letting the
user edit a TCL file.

     I'm trying to figure out is if it makes more sense to convert the
objects to a TCL data structure and pass it in that way, or to use the
TCL java method invocation package to invoke methods on the java
objects.   I'm also a little unsure as to whether the fact that JACL
is implemented in java means it'll inherently support multithreading,
or I'll have to do something tricky.

     Here's some background:
 
     The objects look sort of like this:

Customer Object:
     field1 - String primary key for customer table.
     field2 - String name
     field3 - String address 
     field4 - String etc. (zip code, favorite flavor (etc. :-)
     field5 - optional vector of info objects
          info object:
               field1 - String primary key for info table
               field2 - String info type
               field3 - String etc.
               field4 - optional vector of detail objects
                    detail object:
                         field1 - String primary key for detail table
                         field2 - String detail type, etc.
                         field3 - optional vector of comment objects
                              comment object:
                                   field1 - String comment


     Aside from the fact that the vector of info objects is done with
lazy instantiation (*) the objects are very un-OO - it's all strings.
Since it comes from the database as strings (funky old big-iron
database, don't ask, you really don't want to know) and since
everything in TCL is a string, it didn't seem to make sense to do much
parsing and casting of member data.

     (* Lazy instantiation: the objects aren't instantiated until
        somebody asks for them; then the customer.getInfo() accessor
        method checks to see if customer.info is null, and if so,
        queries the database for the appropriate data, instantiates
        the various objects below info, and stores them in
        customer.info, then returns a reference to the vector in
        customer.info)

     Most of the stuff the TCL script will be doing is things like:

1) remove all info types we don't have a definition for
2) sort info types by a numeric "value" field
3) remove all info objects that have a detail with a comment field 
     containing a given string pattern.

     Eventually, somwhere near the end of the process, probably in a
separate script invoked by a separate thread, I'll have a set of
"transformation" rules that get applied to the remaining data to generate
an HTML page or select a graphic, depending on the circumstances.

Steven J. Owens
[EMAIL PROTECTED]
[EMAIL PROTECTED]

----------------------------------------------------------------
The TclJava mailing list is sponsored by WebNet Technologies.
To subscribe:    send mail to [EMAIL PROTECTED]  
                 with the word SUBSCRIBE as the subject.
To unsubscribe:  send mail to [EMAIL PROTECTED] 
                 with the word UNSUBSCRIBE as the subject.
To send to the list, send email to '[EMAIL PROTECTED]'. 
A list archive is at: http://www.findmail.com/listsaver/tcldallas/

Reply via email to