[Zope] Zope Book mentions "Fragility"

[Dylan Reinhardt]

On Sun, 2003-11-16 at 20:38, Brad Allen wrote:
> 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".

Paul and I differ a bit on what we mean by magic, it seems.  When you
use a tag like <dtml-var my_thing> and the my_thing object gets
rendered, I don't consider that magical.  It's cool, to be sure... but
it's pretty easy to figure out which object is resolving the name.

Magical behavior comes about when objects resolve names other than their
own IDs.  As one very obvious example, Folder objects will resolve many
standard names such as index_html, manage_main, manage, manage_workspace
and others.  

This behavior is "magical" in the sense that it is not  obvious in the
ZMI that those names are resolved by folders... you just have to know
about them from experience and/or reading the code.  And it's possible
that only a *careful* reading of the code may help, since objects can be
programmed to resolve arbitrary names.

The good news is that most of the built-in stuff doesn't seem to have
any inherent problems with collision among magical names.  But such
problems can easily be created, especially if you start fooling around
with Access Rules or other stuff that manipulates the traversal stack. 
And as you develop your own products, you will probably make use of your
own magic.  None of this is bad per se, but it is worth being careful.


> 
> 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]
> 

This structure makes perfect sense, but fails to take advantage of much
of what Zope is able to do for you.  Structuring this way will take a
lot longer to build and way more time to maintain.  I'd shoot more for:

approot/
    distributor/
    customer/
    priv/
        inventory/
        arrival/

Where (I'm assuming) distributor, customer, inventory, and arrival
represent different functional views of your data and/or different
levels of access to data.   Anything located in approot is accessible
from all levels, anything located deeper in the hierarchy should be
specific to the function the folder represents.

To elaborate a bit, let's say you have a set of ZSQL methods that are
broadly applicable.  You would put those in the approot **and** mark
them as only usable by some group you create at the approot level (i.e.,
not Anonymous and not Manager).  Let's call that the "ViewSQL" group. 
Don't make any users members of this group.

Now you can put "viewer" methods/templates at different levels of the
hierarchy that function with the proxy role of ViewSQL.  Users can only
access your data through the interfaces provided and your folder
structure makes it easy to present *only* the interfaces you want each
class of user to have.  Each interface is quite easy to craft, as it
merely needs to know the correct name of the ZSQL method it relies on. 
Zope handles the rest.

Designing *this* way provides a lot of flexibility, makes maintenance
about as easy as it gets and *still* manages to be security-centered. 
This is Zope's sweet spot.

>  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.

An excellent instinct... but you'll do best to maintain that separation
by which objects you use, not by where the objects are stored.  

Python (scripts and ext. methods) is your best available tool for
logic.  Templates (DTML or ZPT) should be used for presentation only.

It may help to use a naming scheme for your Python scripts & ext
methods.  If you call all your scripts "zz_*" for example, you're quite
unlikely to have accidental namespace conflicts and all your methods
will sort together at the bottom of each Folder. 

Naming schemes for templates are less important, but may be a good idea
for things that get called server-side, such as headers, footers and 
other pre-built stuff.  With templates, it's far more common that
"collisions" will be intentional.  It's quite common (and handy) to have
default versions of templates that are overridden by identically-named
replacements located lower in the hierarchy. 

HTH,

Dylan