On Wed, Nov 10, 1999 at 07:43:44PM -0500, Christopher Petrilli wrote:
On 11/10/99 7:11 PM, Stuart 'Zen' Bishop at zen@cs.rmit.edu.au wrote:
I'm with you 100%. It makes me feel like I'm programming a reverse polish calculator sometimes :-)
It is sub-optimal, but it is not a programming language, so please don't try and hold it to those standards. DTML is a reporting language, and trying to make it do things it isn't designed to is simply going to further complicate the matter. Things like 'dtml-let' are dangerous in this reguard... they make you think you actually have a language worth doing anything beyond reporting in.
We've been talking about this around work and have pretty much agreed that DTML lets you do too much... It _lets_ you use it as a programming language, when what we should really be doing is restricting dtml to reporting stuff, make Python methods an intrinsic part of Zope and _require_ people to use python to do the really nasty stuff. DTML is _perfect_ as a reporting language and should always provide the front end to objects, but the objects themselves should be either database queries or python code. Initially we did things in DTML because it was easier than writing external methods, but if you can write python methods inside Zope and cut out a lot of the dangerous namespace games in DTML (like _, dtml-let, REQUEST.set) then you _force_ the divorce between functionality and display, get DTML looking elegant again, which it does when you don't have code like: <dtml-with skins> <dtml-try> <dtml-with "_.getattr(this(),sql.get_skin(username=AUTHENTICATED_USER.getUserName())[0].skin)"> <dtml-var standard_html_header> </dtml-with> <dtml-except> <dtml-with "_.getattr(this(),sql.get_skin(username='default')[0].skin)"> <dtml-var standard_html_header> </dtml-with> </dtml-try> </dtml-with> (This is my root standard_html_header, I'll be moving to use Chameleon which turned up the same night I actually sat down to write it up properly as an external product. Amusing coincidence.) I _shouldn't_ be doing things like this in DTML. It shouldn't even let me. The whole _.getattr(blah) sections are far beyond the reality of a reporting language, and they don't go properly with an Object Oriented paradigm either. I should instead have an object made and be going: <dtml-with "currentuser.get_skin()"> But the existing framework doesn't encourage this. If you banned _ access in anything but python methods and made it so python methods can only be used in Products, then you'd have the proper divide. DTML should call objects and database queries and display them, it should never be doing the actual program logic.
How about <dtml-python> Well, if it were my decision, I'd say "over my dead body," but it's not... HOWEVER, I'll fight this personally because I think this makes it more PHPish, and looses the point of the isolation of presentation and logic. DTML is for presentation, not logic. It's simply been moved too much into the logic side because of a lack of something suitable for that application. We are working on this, including talking with Evan Simpson abou bringing PythonMethods in line with what we need to include it out of the box. I would vigorously recommend working on THAT ,rather than trying to make DTML something it isn't designed to be.
Yep. I agree. Also, one thing that annoys me... With sql_methods I have to go: sql.get_skin(username='default')[0].skin even when the only thing the sql statement is returning is a single value and it's value _is_ ".skin". It'd be good if the database objects actually rendered as either a value or a list of values if they only had one column in the result. Then I could just go: sql.get_skin(username='default') (I keep a lot of my sql methods in a root level sql directory for neatness) This looks far nicer and is easier to understand. I keep forgetting that database queries return lists of objects regardless of what you ask them for. Perhaps even have an option in the method itself which lets you decide how to return the result, as an object, a string or an int. I was actually looking through trying to find the SQL methods code the other day, trying to find the way caching works. Whereabouts in the code that implements them? Basically we currently have a caching problem with different users coming to the site getting given someone else's preferences and I was wondering whether it's an SQL caching problem. (even though I've set cache level to 0 and turned off caching in netscape for that domain). Do the queries i.e. sql.get_skin(username='default') cache only for that given set of inputs? Or do they cache regardless of the inputs? Because we have seen some evidence that the result returned doesn't always change even when the username does and it _should_ have to go look it up again. Hmmm... This was a little longer than expected. Stop now. Need coffee.
Chris -- | Christopher Petrilli Python Powered Digital Creations, Inc. | petrilli@digicool.com http://www.digicool.com
-- Evan ~ThunderFoot~ Gibson ~ nihil mutatem, omni deletum ~ May the machines watch over you with loving grace.