Re: [tcljava-user] Stroing objects in an interpreter
Brought to you by:
mdejong
From: Jeff S. <js...@on...> - 2002-02-14 12:26:30
|
On Thu, 14 Feb 2002, Bas Scheffers wrote: > > puts [subst {<title>[$page getTitle]</title>}] > are you redirecting stdout for that? I was gonna do something > like ::response::println. We did redirect stdout. In hindsight that was overkill, even though it was a neat trick. Our interpreter is also heavily modified from its original sources, though in many cases we did nothing more than expose protected members by making them public. Our early experiments were influenced by CGI. My first "template" was puts {hello world} and from there we proceeded to build more complex scripts that we could develop & test in a standalone interpreter, then deploy on a web server. Soon after we abandoned that when we exposed the request/response variables, though we still occasionally rely on puts. (In general I think Jacl tries too hard to conceal its internal details. We wanted more than a black-box interpreter like tclsh; we wanted an interpreter toolkit that we could easily extend and manipulate from our content management framework.) > Though in the Vignette world, a "template" looks > something like: > ... > And something similar to a "subst" is done on the whole thing. That's what I avoided having... a "template" that isn't also a valid Tcl script. (Of course you can turn your example into a legal script just by wrapping in subst{...}, so there's no real need for this form.) With their special IF statement, etc. Vignette ends up with a language that doesn't resemble Tcl much any more. That's a shame. > I will do too. Doubt it's going to be too portable between > drivers/databases, though. Our scripts (I refuse to call them templates) never issue raw SQL or use any other direct interface to tables/columns. That is by design. If you build this on top of JDBC it will be at least as portable as JDBC. But that has annoying problems of its own... after using MSSQL we were astonished to find that PreparedStatement.setString and ResultSet.getString just don't work on Oracle CLOBs. When there is more than one way to do something (as is typical of JDBC) Oracle seems to have made up their minds that they will only support one way (and leave you to trial-and-error to figure out which). But I digress... Look, this is getting pretty off-topic for tcljava-users. Is there a better mailing list we could (ab)use? Jeff |