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