Zope Feature discussion
[Sorry for the length of this post...] Hi, To fill people in on what I'm working on I've decided to post this long-winded "My Zope Directions" piece. At the moment, Zope has excellent aquisition, permissions and information hiding for Products. I propose to extend this for tags and filesystems. I propose that we have a new Product, called TagMethod, which allows you to define a new tag (a la Mr Zippy). This TagMethod can be added to the Methods area of a Zclass to enable the Tag for the Zclass. In addition, any sub-objects within an instance of this Zclass will be able to use this tag. This would most likely involve XML type interfaces. To make this totally useful, we may need to change the dtml syntax slightly: <dtml-var xx> --> <dtml:var xx> This allows XML style namespaces. So an interesting use would be overriding the UL and LI elements in the XHTML namespace to provide animated bullets without modifing the content. (this would work saying <dtml:var XMLstylesheet>, where XMLstylesheet registers UL, LI tags which are called when the document is rendered). A "spin-off" advantage of doing this is to allow automagic documentation of tags. Simply add a doc-string and the Zope Help system will pick it up! The second change I propose is a "Control Panel" Product which replaces the current one but acts like a User Folder. Then, you can add permissions to Products and allow users down the chain to add their own Products by creating a "Control Panel". This would also reduce Control Panel clutter as Products can be placed where they are needed. Also, you can then subclass (via Zclasses) the Control Panel to create more user friendly Add Object systems. Finally, we need a subclassable Filesystem object. When you insert one of these it "captures" the transations and stores them in the local filesystem. This way, you can "plug" filesystems together. Also, it allows better support for server-farms (servers can share filesystems). A useful example of this would be a corporate public website. Here, the top-level website defines and serves the overall "style". Subservers and their public fs databases are "mounted" into the main one. When a change in a subserver is made only the subserver fs is updated but the master server still "sees" the change. So, Public server: + Marketing --> Marketing.fs | + Tech support --> Support.fs | Protected SMB, | NFS or NDS -------- firewall ------------------------ | file server Marketing (internal) server --> MPrivate.fs: | + Public stuff --> Marketing.fs | + Private stuff --> MPrivate.fs | ... Needless to say, they don't have to be Zope fs's. You could, for example, store some properties as an OLE stream inside Word documents. PS Amos: This is also posted you-know-where Cheers Anthony Pfrunder Zope Community Development Partner
On Fri, 30 Jul 1999, Anthony Pfrunder wrote:
The second change I propose is a "Control Panel" Product which replaces the current one but acts like a User Folder. Then, you can add permissions to Products and allow users down the chain to add their own Products by creating a "Control Panel". This would also reduce Control Panel clutter as Products can be placed where they are needed. Also, you can then subclass (via Zclasses) the Control Panel to create more user friendly Add Object systems. How do you propose to solve following facts, that 1.) Installing Products are a Superuser equivalent operations as it needs filesystem access. It should be so, as Products allow arbitrary code to be executed. 2.) Products most often do install Folder Instance methods, like many of manage_* variety, but that's not a must. So in your model, this methods should be added and removed on traversal of PartControlPanel? How does this work with multiple Threads?
Finally, we need a subclassable Filesystem object. When you insert one of these it "captures" the transations and stores them in the local Again, the problem here is SECURITY. You wouldn't want to allow the non-superuser to add filesystems, as filesystem access equals to complete 100% access. (at least to the objects contained in the filesystem area, because you do have object database and could just change the security settings with a python process.) And if one would implement your propositions about Products, each user could gain access to all data, because ZOPE provides only ``cooperative'' security on Python level.
Needless to say, they don't have to be Zope fs's. You could, for example, store some properties as an OLE stream inside Word documents. Ooops, ok, when you propose to store data in Word, then you don't need to worry about security. :(
Andreas -- Andreas Kostyrka | andreas@mtg.co.at phone: +54/1/7070750 | phone: +43/676/4091256 MTG Handelsges.m.b.H. | fax: +43/1/7065299 Raiffeisenstr. 16/9 | 2320 Zwoelfaxing AUSTRIA
participants (2)
-
Andreas Kostyrka -
Anthony Pfrunder