On Mon, 26 Jul 1999 [EMAIL PROTECTED] wrote: Hi Steven. > Hey folks, This sounds like a good way to use Jacl. > 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 am not sure what you mean by a "Tcl data structure", but I am assuming you mean a hashtable (array). Making everything into a hashtable might make things easier for users if they are already Tcl programmers but that does not mean it will be easier to use for non Tcl programmers. To be honest, I like the way the Tcl/Java interface gives me direct access to an object using a script. If the object is not designed well, it will still be hard to use and understand. So in the end it can be difficult to decide if you want to wrap Java objects in your own custom Tcl API or if you just want to give users direct access to the Java objects. Keep in mind that you do not need to pick one or the other, you can use both. You can make a low level API that uses the Java objects directly and provide some higher level Tcl wrappers for accessing the Java objects. > 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. Jacl does multithreading but only one interp per thread is allowed. You can read up on some of the issues related to threading in the paper I wrote for the 98 Tcl conference (See section 4.3.) http://www.cs.umn.edu/~dejong/tcl/paper.html (or) http://www.cs.umn.edu/~dejong/tcl/paper.ps > 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] I hope that helps. Mo DeJong ---------------------------------------------------------------- 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/
