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

[Rik Hoekstra]

> 
> So it should be the Python of reporting languages. :)

Ah!

> 
> >  Things like 'dtml-let' are dangerous in this reguard... they
> > make ou think you actually have a language worth doing anything beyond
> > reporting in.
> 
> Yes, but the problem is people *will* currently apparently use DTML
> beyond its design specifications. It's a difficult situation; if you
> don't give people dtml-let, they'll use some other feature (dtml-with
> and namespace and whatnot) to do the same. This is even *more*
> complicated.
> 
> DTML is currently moving in several incompatible directions at once.
> Under pressure of its users DTML moves to a more full-fledged
> programming language. At the same time, features are added that are
> rather ad-hoc to make specific reporting tasks more easy. The
> interaction between these two pressures causes DTML to become
> unnecessarily difficult for both programming *and* reporting tasks. Note
> that many programming and reporting tasks *are* very easy in DTML; it's
> just that too many aren't.
> 
> I'm not sure what one could do to let DTML become a conceptually pure
> reporting language. Redesign it in some unspecified fashion. Offer an
> alternative that is as easy to use as DTML; people currently use DTML as
> it's quick and easy. PythonMethods are perhaps the solution there.
> 
> We need to ponder more about what makes anything a conceptually pure
> reporting language. This topic must've been studied before, perhaps
> there's material on the net...
> 
> [sequence-item vs sequence_item]
> 
> > > 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.
> 
> Agreed.
> 
> > 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.
> 
> Agreed. We should move DTML *more* into the direction of its original
> target.
>  
> > Always measure something by the scope of its problem domain, not by what
> > people try and use it for.  The latter indicates a separate problem enirely.
> 
> Agreed.
>  
> > > Is existing DTML good enough for 'simple' scripting? I think the current
> > > confusion threshold occurs when people start needing to pass parameters
> > > to methods (and the whole quoted and unquoted thing kicks in, and suddenly
> > > they have to understand about the _ namespace, and the magic variables to
> > > pass a DTML method to make it work).
> > 
> > well, this is beyond the above outlined problem domain.  So we have a
> > seperate problem, not a DTML problem, but a lack of a solution problem.
> 
> Yes, but. I still have (admittedly completely vague) ideas about how
> DTML could be a more pure reporting language. A DTML where ugly
> constructs simply aren't *possible* (utopic, but at least we could move
> it in that direction). Instead, in this ideal DTML it'll be *natural*
> and *easy* to use a PythonMethod (or whatever), whenever you notice (and
> this should be easy) that you're going beyond DTML's abilities.
> 
> > I sound a bit harsh, but I'm trying to clarify the problem domain that DTML
> > solves (just as we're trying to be more explicit about the domain ZClasses
> > are designed to solve).  It's dangerous to take it outside its problem
> > domain, as it collapses quickly into a morass of tangled code.
> 
> Yes, but this is already happening. And worse, this causes DTML to miss
> its original reporting target as well, in some cases; witness my
> dtml-with discussion that prompted me to start the rant. That wasn't a
> deep programming problem, it was a simple reporting issue, and the DTML
> was just too confusing.

Yes. I recall it took me _days_ to discover how to make an object 
with an id provided from a request, then change to the object and 
change things in it. THis is a simple operation, and it is 
ubiquitous, but it does involve such esoteric constructs as 
<dtml-var 
"_.getitem(REQUEST['id']).manage_changeProperties(REQUEST)">

or worse:

<dtml-var "_.getitem(_['sequence-
item']).manage_changeProperties(title=REQUEST['title']">


Or something alike, because I always forget what it is.

Reading all the thread and the different remarks, I'm tempted to make 
Paul's compilation but I won't, because I do not have time. There is 
a few important conclusions to be made, however:

1. DTML may be meant to be a reporting language, but it's able to do 
many more things and used for many more things
2. There are Python alternatives, but these are not obvious, nor is 
it clear when to use what
3. Thus, there is no integration between DTML and Python in the 
framework. By this, I mean that it should be easy to do simple things 
in DTML. Then (as it goes), find out you have to do more complicated 
things, and then be able to switch to a Python alternative (be it 
Python Methods, ZClasses, External Methods, although these are 
presented in the documentation a sort of 'hack glue' ). I'm sure this 
can be done by now, or be accomplished with little effort.
IMHO, the advantage would be that it would bring the modularity Zope 
excels in in its design to programming Zope.

While it will not be possible to enforce this by technological means 
(as many have remarked), there must be a solution in design 
practices. After all, there in a product so well designed as Zope, 
there are already al lot of assumptions of what is the best place/way 
of doing.

The most easy solution to this would be something like a 'best 
practices in Zope programming' document. In it, it we could point out 
a number of 'rules of thumb' to Zope users/programmers/designers of 
'what to use when and where in programming Zope, and how to integrate 
your efforts to a coherent whole.

Then people will still get tangled up in their dtml, but at least we 
can point them out that 'the preferred way of doing this is Zope is 
not in DTML, but in Python, along such and such lines'

(I'll be happy to contribute, but I'm afraid this is too 
much/complicated for me alone)

What do you all think. Is this a direction for (at least a partial) 
solution to a very complicated problem?

Rik