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