<!doctype html public "-//W3C//DTD W3 HTML//EN">

<html><head><style type="text/css"><!--

blockquote, dl, ul, ol, li { padding-top: 0 ; padding-bottom: 0 }

 --></style><title>Zope Book mentions

&quot;Fragility&quot;</title></head><body>

<div>Hi, I'm a Zope newbie, still in the process of reading the

documentation and working on my first Zope project. I'm at the stage

of organizing all my scripts and DTML documents in a folder hierarchy,

but am unclear on how to design against the &quot;fragility&quot;

issues discussed in the Zope book. Should I try to avoid a deep folder

hierarchy and go with something more flat (but less well-organized?)

Does anyone have any recommendations for me?</div>

<div><br></div>

<div>Thanks!</div>

<div><br></div>

<div>(see below for the excerpt from the Zope book)</div>

<div><br></div>

<div><br></div>

<div

>http://zope.org/Documentation/Books/ZopeBook/2_6Edition/ScriptingZop<span

></span>e.stx</div>

<div><br></div>

<div><font face="Verdana" size="-3" color="#000000"><b>Fragility<br>

<br>

</b>Over-use of context acquisition can also lead to fragility. In

object-oriented terms, context acquisition can lead to a site with low

cohesion and tight coupling. This is generally regarded as a bad

thing. More specifically, there are many simple actions by which an

unwitting developer could break scripts that rely on context

acquisition. These are more likely to occur than with container

acquisition, because potentially every part of your site affects every

other part, even in parallel folder branches.<br>

<br>

For example, if you write a script that calls another script by a long

and torturous path, you are assuming that the folder tree is not going

to change. A maintenance decision to reorganize the folder heirarchy

could require an audit of scripts in<i> every</i> part of the site to

determine whether the reorganization will break anything.<br>

<br>

Recall our Zoo example. There are several ways in which a zope

maintainer could break the feed() script:<br>

<br>

<b>Inserting another object with the name of the method<br>

</b>This is a normal technique for customizing behavior in Zope, but

context acquisition makes it more likely to happen by accident.

Suppose that giraffe vaccination is controlled by a regularly

scheduled script that calls Zoo/Vet/LargeAnimals/giraffe/feed.

Suppose a content administrator doesn't know about this script and

adds a DTML page called<i> vaccinate</i> in the giraffe folder,

containing information about vaccinating giraffes. This new<i>

vaccinate object will be acquired before Zoo/Vet/vaccinate.

Hopefully you will notice the problem before your giraffes get

sick.<br>

<b>Calling an inappropriate path<br>

</b>if you visit<i>

Zoo/LargeAnimals/hippo/buildings/visitor_reception/feed</i>, will the

reception area be filled with hippo food? One would hope not. This

might even be possible for someone who has no permissions on the

reception object. Such URLs are actually not difficult to construct.

For example, using relative URLs in standard_html_header can lead to

some quite long combinations of paths.<br>

<br>

Thanks to Toby Dickenson for pointing out these fragility issues on

the zope-dev mailing li</font></div>

</body>

</html>