[Zope] Augmenting Structured Text (Re: <% ... %>) ?

[Martijn Faassen]

> 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