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
> 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
By far the majority of new deployments use zope 2 though...
> Zope maillist - Zope@zope.org
> ** No cross posts or HTML encoding! **
> (Related lists -
> https://mail.zope.org/mailman/listinfo/zope-dev )
Zope maillist - Zope@zope.org
** No cross posts or HTML encoding! **
(Related lists -