Martijn Faassen wrote: [my Python vs DTML ideas]
Christopher Petrilli wrote:
We of course will take suggestions, but I think there's a few things that aren't terribly negotiable in our implementation of DTML/etc (this doesn't prevent other people from implementing other things, this is Open Source ;-)... the untouchables are:
* DTML is inside HTML
Of course in practice this isn't much different from the other way around: <!--#var standard_html_header--> <ul> <!--#in mylist--> <li> <!--#var sequence-item--> </li> <!--#/in--> </ul> <!--#var standard_html_header--> could (given the right syntax :) differ only syntactically from: var("standard_html_header") @@@<ul>@@@ in mylist: @@@<li>@@@ var("sequence-item") @@@</li>@@@ @@@</ul>@@@ var("standard_html_footer") except for various indentation issues of course. :)
* Safety is paramount
Understood. The half-baked proposal in my previous post was vaguely between using Python proper and something as I described above, which looks like Python but isn't Python proper, but simply (mostly!) a syntactic shuffle around of DTML. More on using Python proper in an up and coming new mail. In this mail I just argue about (radical) syntactic changes to DTML. Security/safetly is of course paramount for anything that can be edited through the web.
What this means is that your proposed syntax, to my eyes, is no better (though no worse probably) than what we have today, it is however, much more foreign to people who don't know Python. Remember, as the mantra goes, DTML is a *REPORTING* language, not a scripting language.
Yeah, I know, I know. But, just to argue, I don't think the "this is foreign to people who don't know Python" argument is very strong; DTML (the intricacies and there are quite a few) is just as foreign to people coming to Zope as Python is, and probably much less easy to understand. But that may be only me. :)
Now on to the question of what will be in the 'Python Method' product... honestly, we're only in the Inception stage, so it's pretty vague right now, but the general idea is this:
* One method == one object in the database * Operates in the namespace of its container * access to object database through self (maybe 'this'). * Expression machinery enforcement of security model * Additional safety net of catching resource DOS problems
What this means is that you can extract logic from your DTML documents and move it into a clean Python syntax, and then simply refer to it:
<!--#var pyDoSomething-->
or whatever syntax you prefer :-) This to me puts DTML back where it should be, with no major bizarre contortions in expr syntax with _foo and _.bar() that...
Agreed. This is exactly what I want! DTML back where it belongs! DTML go home! Oh, um.. :)
The hard part, and what will control time line, is the difficulty of extending/modifying the existing security mechanism (which depends on real-time modification of the AST parse tree) to work with multi-expression blocks. Honestly, I have no clue how much work this is.
Having looked at Python internals at various occasions: *swallow* Deep magic.
Note that this will operate in a "restricted execution" environment so that you can only import a subset of modules available---although the goal would be to let the administrator control which modules are available.
Yeah, I was assuming a restricted execution environment. Thanks for the info! Regards, Martijn