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

[Martijn Faassen]

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.

But we should hold to the standards of simplicity, one-syntax-to-do-it,
etc, of Python. It shouldn't *be* Python, however. 

> 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.

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

>  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.

Regards,

Martijn