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 )

Reply via email to