Forum OpenACS Q&A: Response to A Template-Based ACS

Collapse
Posted by Don Baccus on
Let me clarify (by repetition) my thinking - I stated that the object-oriented paradigm's a natural way of thinking about problems like the design of a uniform interface for modules.  That's not a call for using an object-oriented language, nor to try to implement an object-oriented model in Tcl.  The last thing on my mind is to suggest using anything other than Tcl for the ACS.  I have an abstract curiousity in [incr Tcl], as I mentioned in an earlier thread, and a similar curiousity about Python, but that's it.

And I'm heartily in the camp that dismisses the notion that the object-oriented paradigm fits all problems - just as I dismiss the equally narrow view (rarely heard, these days) that it fits no problem, or the "it's only good for GUIs" variant of that argument (also rarely heard, these days).

I suspect that templating is a problem area where the object-oriented paradigm makes no sense, which is one reason I've not thought about it much.  Studying Zope might make the problems obvious, I don't know, might be a good reason to take a look!

And I agree with Ben's comments regarding plopping objects on top  of the relational model, though I've never personally tried to do such a thing (and doubt I will).

So I actually suspect that object oriented paradigm might help with our thinking about a uniform module interface, and that's about it.  In reality, any implementation scheme we come up with has to plug-n-play with the existing ACS anyway, IMO - I'm not up for rewriting the ACS, if we try to do so I'll never get to finish my personal site work!

As far as language wars, screw it in my mind.  The toolkit should be written in a single language as much as possible, given the fact that we're already stuck writing in two languages (SQL and Tcl)!  And generating HTML, XML, and even some Javascript, and the Practical Map Server (which we should integrate at some point, at least in the sense of building some examples using the Postgres JDBC interface) is written in Java.  Hell, there's even a little Perl, now.

See ... it's already a mess!  I suppose one could argue that adding code in one more language (Python) won't significantly add to that tower of Babel, but I'd be hard to convince.