[Zope] Augmenting Structured Text (Re: <% ... %>) ?
Martijn Faassen
M.Faassen@vet.uu.nl
Tue, 15 Jun 1999 18:34:33 +0200
> 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