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 ou think you actually have a language worth doing anything beyond reporting in.
A low-level user (one not confidant in writing external methods) shouldn't have use magic constructs like <dtml-var "_['sequence-item'].title_or_id()"> dtml-in is the main culprit - a synonyms for the magic variables that conform to python naming standards need to be created and the old ones depricated. Is there any reason why I should fix this and submit the patch for 2.1? (or 2.2?)
I agree, I don't honestly know why this is done this way. I'll discuss this Monday to see about getting them aliased to 'sequence_item', simply swapping the '-' for a '_'.
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. 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.
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. 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. Chris -- | Christopher Petrilli Python Powered Digital Creations, Inc. | petrilli@digicool.com http://www.digicool.com