On 19/08/10 09:37, robert rottermann wrote: > 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 >
By far the majority of new deployments use zope 2 though... > > > > > _______________________________________________ > Zope maillist - Zope@zope.org > https://mail.zope.org/mailman/listinfo/zope > ** No cross posts or HTML encoding! ** > (Related lists - > https://mail.zope.org/mailman/listinfo/zope-announce > https://mail.zope.org/mailman/listinfo/zope-dev ) > _______________________________________________ Zope maillist - Zope@zope.org https://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope-dev )
