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