[Zope] Zope Book mentions "Fragility"

[Brad Allen]

Thanks, Paul and Dylan...but will I need a security policy if there's 
only one other developer that I work closely with? He works on the 
web pages and I work on the scripts. Eventually, we will have a 
security policy for one administrator who may use the Zope management 
interface. End users will never see the Zope management interface.

I don't follow your use of the word "magic".

My current Zope folder hierarchy looks something like this:

appRoot
     bizlogic
         product
             [several nested subfolder levels in here containing 
scripts and Z SQL methods]
             distributor
             inventory
             arrival
         customer
     pages
         [hierarchy of DTML web pages which refer to scripts under bizlogic]

There will be many web pages referring to specific paths to scripts 
to obtain results. Likewise, scripts under bizlogic will need to make 
reference to specific paths in the hierarchy of web pages. This 
structure seems like a perfect example of "fragility" because of the 
frequent need to bridge between two major branches. Does it makes 
senses to combine the "bizlogic" and "pages" branches? I'm accustomed 
to thinking in terms of keeping UI logic separate from business 
logic, so it goes against my instincts to merge the two.


>On Sun, 2003-11-16 at 09:44, Brad Allen wrote:
>>  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 "fragility" 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?
>
>The key here is discipline, especially if there is more than one person
>adding objects to the site.
>
>A shallow hierarchy might reduce the opportunity for accidental
>duplication of object IDs... but that approach does nothing to address
>"magic" names (the real problem here) and makes enforcing levels of
>access more difficult.  Since levels of access are your primary defense
>against one user breaking another user's namespace, shallow won't help.
>
>IMO, the hierarchy should be at least as deep as the number of levels of
>access you want.  You may want *more* hierarchy than that if your
>information architecture requires it... but no less.
>
>Some best practices:
>1. Write things down.  In particular, what "magic" names are
>    provided by custom objects?
>2. Design and enforce a security policy. 
>3. Reduce usage of objects as "global" variables.
>4. Create a special naming scheme for "magic" names and objects
>    that *are* used as variables.
>5. Plan on doing some troubleshooting anyway.  :-)
>
>HTH,
>
>Dylan