[Zope] Storing DTML in SQL

[robert rottermann]

Am 18.08.2010 18:56, schrieb Andrew Milton:
> +-------[ robert rottermann ]----------------------
> | I think storing dtml in a db is wrong by design.
> | I do lots of dynamic websites that are generated from external data.
> | i had no need for a single line of dtml yet ...
>
> I've seen it used a lot in PHP systems like PHP-Nuke, where the widget
> code is executed out of strings in the db. Whether it's necessary or
> not in this instance is debatable.
>
>    
there is an important difference between php based systems and zope.
a php site is made up from a bunch of code snippets embedded in html 
that are fed into a php interpreter.
where these snippets come from is unknown to the php interpreter. one of 
the reasons (I assume) that such systems tend to be riddled with 
security problems

zope is an application server that sits between the internet and the 
(physical) server on which it runs.
it so divides its univers in an unsave and a save part. everything that 
comes from the internet, that includes operations performed TTW (trough 
the web), is unsave and must be authenticated against zopes strict 
permission system.
everything that comes from the server side (eg. from files loaded from 
the server) is considered save and is not security screened (or at least 
not as tightly).

zopes application server offers you two ways to create dtml objects. TTW 
and from a file. one tightly screens one less so.
now what you propose is a third way. get the dtml objects from a database.
this could for sure be done
but..
you have to write a kind of interpreter that creates an dtml object, 
sets up its context, executes it and manipulates its own environment in 
a meaningful way.
next to that this interpreter has to set up its own security context to 
avoid to punch holes into zopes defenses.

you can imagine, this is no easy chore.

and it would probably be foolish if one tried to implement it.
dtml is just not the way to go. it is a dead end (its developer decided 
so). it is replaced by tal and zope 3 (now bluebream) components that 
are far more powerfull and flexible.
and, alas, not THAT easy to grasp

robert