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