[Zope-dev] DTML Syntax contd. + rant + summary

Fri, 12 Nov 1999 06:17:17 +0000

Stuart 'Zen' Bishop wrote:

> Is this using r_exec and Bastion from Python? Or do you have to roll
> your own?

Since PythonMethods live and work entirely within Zope, they aren't allowed to
import anything, and get the same restricted set of builtins as DTML, so r_exec
and Bastion are irrelevant.  All that remains is to prevent damage or improper
access to objects passed into a PM.  That's where zbytecodehacks come in.  The
compiled bytecode is scanned for forbidden operations and munged to call secured
versions of other operations.

> My summary of the thread so far would be along the lines of:
>

> [snip]

>
> Until program code can be implemented using the web interface and
> run securly in a sandbox, DTML will continue to be abused.

Even this won't be really satisfactory.  What everyone (myself included) seems to
want is the ability to use DTML or similar tags in their simplest form -- no
expressions, more declarative than procedural -- and have complex logic live
separately, written in nice normal Python.  Unfortunately, even a moderately
complex case will make you either calculate *everything* up front, and pass it to
the DTML for rendering, or else fragment the logic into a swarm of little
mini-methods.

I do all of my web work with my wife, who's a designer.  She uses Dreamweaver and
other nice Whizzywig tools to produce pretty, friendly pages, and then I install
the engine.  I've been able to come up with code and procedures which make the
DW-Zope partnership tolerable, but it still isn't nice *at all*.  As long as
we're careful, DW doesn't mess up DTML tags or get confused, but we're still
using a visual tool to edit what is essentially a *program* rather than a
*template*.  My ideal, as near as I can express it, is something like this:

<Z name="standard_html_header">
<html><head><title>The Title</title></head>
<body>
<p>This whole section is a placeholder for visual editing.  It gets replaced with
standard_html_header.</p>
</Z>
<table>
  <tr Z-in="item_list">
    <td>Item #&Z-number;</td>
    <td>Qty: &Z-qty;</td>
    <td>Price: &Z-price;</td>
    <td>Total: &Z-total;</td>
  </tr>
</table>
<form Z=relative_form method=POST>
  <input type=text name=bob Z=bob>
  <input type=checkbox name=uncle_p Z=uncle_p>
  <input type=submit name=submit value="Submit! Surrender!">
</form>
<Z name="standard_html_footer">
</body></html></Z>

Give or take the legality of the syntax and the reaction of editors other than
Dreamweaver to the "bonus" attributes and entities, what we have here is a
perfectly well-formed, intelligible HTML page.  The source isn't too hard to
read, and a browser (well, NS4.61 for Linux, anyway) renders it nicely, acting as
a sort of mock-up of the dynamic page-to-be.  Now imagine that there's a block of
code joined to this page, something like this:

Z.item_list = SQL_get_items()
for item in Z.item_list:
    item.set('total', item.qty * item.price)

Z.relative_form.set('action', '/here/there/everywhere')
Z.bob.set('value', 'Bob')
if uncle_default:
    Z.uncle_q.set('CHECKED')
if not choose_name:
    Z.bob = 'Bob'  # Replace the entire <input> tag with this fixed string.

Here, 'Z' is a magic object like '_' in DTML.  It holds the values which will
replace the &Z-entities; and allows attributes of Z-named tags to be set or
cleared.  Tags with Z-in attributes are repeated using the named value, much like
<dtml-in>.

Well, I'm done rambling now.  This is all ill-defined (how are code and page
joined?), hard to code, and quite possibly a bad idea, but I had to share it.

Thanks,

Evan @ 4-am