[Zope-dev] Re: [Zope] DTML Syntax contd. + rant

[Evan Gibson]

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.