Nope! the method calling the manage_* method can have proxy roles setup for it so that it can call manage_* methods for users who do not have the capability to call that manage_* method. Also, any user can be assigned access to the manage_* methods needed on a particular document/method/object by giving them the rights do what you need to do, such as the Change Properties and Add properties rights (might also need the manage_properties right, but I dont think so) via the security tab inside Zope... did this help?
Hi again,
Is it true that you have to have the Manager role to use any methods that start with manage_?
If so, that's pretty unhelpful, almost as unhelpful as the DocString limitation :-(
cheers,
Chris
Jon Franz wrote:
Nope! the method calling the manage_* method can have proxy roles setup for it so that it can call manage_* methods for users who do not have the capability to call that manage_* method.
That doesn't help if they want to use the methods directly ;-)
Also, any user can be assigned access to the manage_* methods needed on a particular document/method/object by giving them the rights do what you need to do, such as the Change Properties and Add properties rights (might also need the
manage_properties right, but I dont think so) via the security tab inside Zope...
I was slightly off first time. I think they may need the 'view management screens' perimission, which isnt' quite as bad, but is still a little superfluous... cheers, Chris
Hello, I have a problem with my Data.fs (ZODB). Always, after I change the ZODB (add + delete), I can not pack the database. When I press the "PACK" button in the managment screen, it will return to me that the Database was packed in previous time (and it wasn't). So my database get larger and larger all the time. Best regards, Harry PS: I have the Zope 2.2.2 in this system.
Hi, I am trying to figure out ZPatterns and because I rather work with Python Products when with Zclasses I am trying to convert the EmployZ product to Python. So far I got half the way there, the Rack recognizes the DataSkin And on newItem in the Specialist it a new slot gets created and I can see them and their ID. Now the problem is creating a Propertysheet in the DataSkin that gets stored in the Rack. I packet my work so far and put it on Zope.org: http://www.zope.org/Members/johanc/ZPatterns/EmployX/EmployX-0.0.1.tgz I look at the ZPattern Products that I know are out there, but they don't seem help me any futher. Regards, Johan Here's my to classes: < EmployX (DataSkin)> __doc__ = """EmployX product module. See README.txt for more details.""" __version__ = '0.0.1' from Globals import HTMLFile from Globals import MessageDialog from Globals import Persistent import OFS.SimpleItem import Acquisition import AccessControl.Role from Products.ZPatterns.DataSkins import DataSkin #from Products.ZPatterns.PropertySheets import VirtualSheets manage_addEmployXForm = HTMLFile('dtml/EmployXAdd', globals()) def manage_addEmployX(self, id, title='', REQUEST=None): """Add a EmployX to a folder.""" self._setObject(id, EmployX(id, title)) if REQUEST is not None: return self.manage_main(self, REQUEST) class EmployX( DataSkin, #VirtualSheets, ): """EmployX object. """ meta_type = 'EmployX' # Necessary? _isRackMountable = 1 #_properties=( # {'id':'first', 'type': 'string'}, # {'id':'last', 'type': 'string'}, # {'id':'emp_id', 'type': 'string'}, # {'id':'salary', 'type': 'string'}, # ) manage_options = ( {'label': 'Edit', 'action': 'manage_main' }, {'label':'Debug','action':'debug'}, {'label': 'View', 'action': 'index_html'}, {'label': 'Security', 'action': 'manage_access'}, ) _v_manage_options_label_index = ExtendedManagmentTabs.createManageIndex(manage_options=manage_options) __ac_permissions__=( ('View management screens', ('debug','manage_tabs','manage_main')), ('Change permissions', ('manage_access',) ), ('Change EmployX' , ('manage_edit',) ), ('View EmployX', ('',) ), ) def __init__(self,id): """initialise a new instance of BeingBoring""" DataSkin.__init__(self,id) def debug(self): """ Print object's __dict__ """ result = "" for k, v in self.__dict__.items(): result = "%s\n%s : %s" % (result, repr(k), repr(v)) return result manage_main = HTMLFile('dtml/EmployXEdit', globals()) def manage_edit(self, title, REQUEST=None): """does this really need a doc string?""" self.title = title if REQUEST is not None: return self.manage_main(self,REQUEST,management_view='Edit') editInstance = HTMLFile('editInstance', globals()) editInstanceForm = HTMLFile('editInstanceForm', globals()) index_html = HTMLFile('index_html', globals()) def initialize(context): """Initialize the EmployX product. """ context.registerClass( EmployX, constructors = ( manage_addEmployXForm, manage_addEmployX), icon = 'www/item.gif' ) # We need this so that this class will show up in the list of classes # Customizers can customize. (Thanks Steve) context.registerBaseClass(EmployX) < EmployXManager(Specialist)> __doc__ = """EmployXManager product module. See README.txt for more details.""" __version__ = '0.0.1' from Globals import HTMLFile #from Globals import MessageDialog #from Globals import Persistent from Products.ZPatterns.Specialists import Specialist manage_addEmployXManagerForm = HTMLFile('EmployXManagerAdd', globals()) def manage_addEmployXManager(self, id, title='', REQUEST=None): """Add a EmployXManager to a folder.""" self._setObject(id, EmployXManager(id, title)) if REQUEST is not None: return self.manage_main(self, REQUEST) class EmployXManager(Specialist): """Thing that manages EmployX""" meta_type = "EmployXManager" newItemForm = HTMLFile('newItemForm', globals()) index_html = HTMLFile('index_html_manager', globals()) def addNewItem(self,emp_id,REQUEST=None): """ttw""" ob = self.newItem(emp_id) #ob.addPropertySheet('Basic') #ob.propertysheets.Basic.manage_changeProperties(REQUEST=REQUEST) #if REQUEST.has_key('first'): ob.first = REQUEST['first'] #else: ob.first = '' #if REQUEST.has_key('last'): ob.last = REQUEST['last'] #else: ob.last = '' #if REQUEST.has_key('emp_id'): ob.emp_id = REQUEST['emp_id'] #else: ob.emp_id = '' #if REQUEST.has_key('salary'): ob.salary = REQUEST['salary'] #else: ob.salary = '' if REQUEST is not None: return self.manage_main(self, REQUEST) def initialize(context): """Initialize the EmployXManager product. """ context.registerClass( EmployXManager, constructors = ( manage_addEmployXManagerForm, manage_addEmployXManager), icon = 'www/item.gif' )
Johan Carlsson wrote:
Hi, I am trying to figure out ZPatterns and because I rather work with Python Products when with Zclasses I am trying to convert the EmployZ product to Python. So far I got half the way there, the Rack recognizes the DataSkin And on newItem in the Specialist it a new slot gets created and I can see them and their ID.
Now the problem is creating a Propertysheet in the DataSkin that gets stored in the Rack.
The attributes of a Persistent DataSkin will get stored in the Rack without too much extra work.
class EmployX( DataSkin, #VirtualSheets, ):
You need to derive EmployX from DataSkin and some Zope persistent class such as SimpleItem. Otherwise, it won't be persistent. -- Steve Alexander Software Engineer Cat-Box limited http://www.cat-box.net
Hi, I am trying to figure out ZPatterns and because I rather work with Python Products when with Zclasses I am trying to convert the EmployZ product to Python. So far I got half the way there, the Rack recognizes the DataSkin And on newItem in the Specialist it a new slot gets created and I can see them and their ID.
Now the problem is creating a Propertysheet in the DataSkin that gets stored in the Rack.
The attributes of a Persistent DataSkin will get stored in the Rack without too much extra work.
class EmployX( DataSkin, #VirtualSheets, ):
You need to derive EmployX from DataSkin and some Zope persistent class such as SimpleItem. Otherwise, it won't be persistent.
Accualy I don´t have to do that. Have a look at Itamar Shtull-Traurings and Heiko Stoermers FlatDatabase: class EntryDataSkin(DataSkin): """ Flat Database entry. """ meta_type = "Entry DataSkin" ... def manage_change(self, REQUEST, RESPONSE): """ Change properties """ for prop in self.database_properties.propertyMap(): name=prop['id'] if REQUEST.has_key(name): if 'w' in prop.get('mode', 'wd'): value=REQUEST.get(name) setattr(self, name, value) <<<< RESPONSE.redirect(REQUEST.URL1) But as I noticed the "properties" was saved as attributes not as properties in a propertysheet. I can live with that, but I still would like to know if and how to use propertysheets provided by a DataManager inside a Pyhton DataSkin? Johan
Johan Carlsson wrote:
Hi, I am trying to figure out ZPatterns and because I rather work with Python Products when with Zclasses I am trying to convert the EmployZ product to Python. So far I got half the way there, the Rack recognizes the DataSkin And on newItem in the Specialist it a new slot gets created and I can see them and their ID.
Now the problem is creating a Propertysheet in the DataSkin that gets stored in the Rack.
The attributes of a Persistent DataSkin will get stored in the Rack without too much extra work.
class EmployX( DataSkin, #VirtualSheets, ):
You need to derive EmployX from DataSkin and some Zope persistent class such as SimpleItem. Otherwise, it won't be persistent.
Accualy I don´t have to do that. Have a look at Itamar Shtull-Traurings and Heiko Stoermers FlatDatabase:
def manage_change(self, REQUEST, RESPONSE): """ Change properties """ for prop in self.database_properties.propertyMap(): name=prop['id'] if REQUEST.has_key(name): if 'w' in prop.get('mode', 'wd'): value=REQUEST.get(name) setattr(self, name, value) <<<< RESPONSE.redirect(REQUEST.URL1)
But as I noticed the "properties" was saved as attributes not as properties in a propertysheet.
That's another way of doing it. It is a bit less transparent. I find it more straightforward to make my classes SimpleItems and PropertyManagers, as it means I can just call manage_changeProperties() without writing extra methods.
I can live with that, but I still would like to know if and how to use propertysheets provided by a DataManager inside a Pyhton DataSkin?
There are two kinds of PropertySheet in Zope: DAV propertysheets Propertysheets that go with ZClasses There are also Properties for objects that are PropertyManagers, such as DTML Documents. There is an important difference in how these different types of properties work: DAV Propertysheets are independent Persistent objects Propertysheets that go with ZClasses and also PropertyManager propertysheets are stored as attributes in the objects they belong to. Therefore, in ZPatterns, you use AttributeProviders to do stuff with PropertyManager properties and ZClass-style propertysheets. You use SheetProviders to do stuff with DAV Propertysheets. If you're using ZClass-style propertysheets, you need to use DataSkin Attribute Propertysheets, rather than the default Common Instance Propertysheets. In your case, I suggest making your class Persistent, and using PropertyManager properties. The reason to use ZClass-style propertysheets is if you want to easily partition your properties into sets of properties with different permissions. -- Steve Alexander Software Engineer Cat-Box limited http://www.cat-box.net
But as I noticed the "properties" was saved as attributes not as properties in a propertysheet.
That's another way of doing it. It is a bit less transparent. I find it more straightforward to make my classes SimpleItems and PropertyManagers, as it means I can just call manage_changeProperties() without writing extra methods.
Ah, I see. But why do I need SimpleItems, isn't PropertyManagers sufficient?
There are two kinds of PropertySheet in Zope: DAV propertysheets Propertysheets that go with ZClasses
There are also Properties for objects that are PropertyManagers, such as DTML Documents.
There is an important difference in how these different types of properties work:
DAV Propertysheets are independent Persistent objects
Propertysheets that go with ZClasses and also PropertyManager propertysheets are stored as attributes in the objects they belong to.
Therefore, in ZPatterns, you use AttributeProviders to do stuff with PropertyManager properties and ZClass-style propertysheets.
You use SheetProviders to do stuff with DAV Propertysheets.
If you're using ZClass-style propertysheets, you need to use DataSkin Attribute Propertysheets, rather than the default Common Instance Propertysheets.
In your case, I suggest making your class Persistent, and using PropertyManager properties.
But making it presistent doesn't that lock the objects to be stored in the ZODB? I may want to change storage to SQL later.
The reason to use ZClass-style propertysheets is if you want to easily partition your properties into sets of properties with different permissions.
Still confused but on a higher level ;-) Johan
Johan Carlsson wrote:
Ah, I see. But why do I need SimpleItems, isn't PropertyManagers sufficient?
It makes your class play nicely with Zope. So, it can work with DAV, be copied and pasted, properly work with traversal, work with ZDOM, be Owned, support undo, work with Acquisition, and manage roles. Take a look at the source to lib/python/OFS/SimpleItem.py You can omit some of this if you know for sure in advance that you will be using instances of your class only with Specialists in Racks. However, ZPatterns is set up so you can use the same DataSkin class with instances stored in a Rack or stored as normal Persistent objects in the ZODB.
In your case, I suggest making your class Persistent, and using PropertyManager properties.
But making it presistent doesn't that lock the objects to be stored in the ZODB? I may want to change storage to SQL later.
No it doesn't tie the object to the ZODB if you're using a Specialist. That's the magic of ZPatterns. -- Steve Alexander Software Engineer Cat-Box limited http://www.cat-box.net
Ah, I see. But why do I need SimpleItems, isn't PropertyManagers sufficient?
It makes your class play nicely with Zope.
So, it can work with DAV, be copied and pasted, properly work with traversal, work with ZDOM, be Owned, support undo, work with Acquisition, and manage roles.
Which isn't a bad thing. At the moment I'm aiming at the lest amount of functionality. Next thing I want to do is adding Zope-awareness and put objects in a Folder/wCustomizer . How hard is it to move a Simple Item DataSkin to a Customizer? BTW. After I have done that successfully I intend to make the DataSkins Plugins instead of Zope Items. That's the my goal at this point.
Take a look at the source to lib/python/OFS/SimpleItem.py
You can omit some of this if you know for sure in advance that you will be using instances of your class only with Specialists in Racks.
However, ZPatterns is set up so you can use the same DataSkin class with instances stored in a Rack or stored as normal Persistent objects in the ZODB.
In your case, I suggest making your class Persistent, and using PropertyManager properties.
But making it presistent doesn't that lock the objects to be stored in the ZODB? I may want to change storage to SQL later.
No it doesn't tie the object to the ZODB if you're using a Specialist. That's the magic of ZPatterns.
Ahhh, good. Magic is a wonderful thing, but it also makes understanding a bit harder ;-) About the ZClass still of propertysheets, is that when I add a OFS.PropertySheets.PropertySheets attribute to my object? Can I use the OFS.PropertySheets.PropertySheets for that and does it play with ZPatterns? I use PropertySheets for allot of multi language support, storing properties in separate languages PropertySheets. Johanc
Steve Alexander wrote:
Johan Carlsson wrote:
You need to derive EmployX from DataSkin and some Zope persistent class such as SimpleItem. Otherwise, it won't be persistent.
Accualy I don´t have to do that.
Looking more closely at DataSkins.py, I see that class DataSkin derives from Persistent. So, I was wrong -- please ignore what I said about needing to derive from Persistent :-) -- Steve Alexander Software Engineer Cat-Box limited http://www.cat-box.net
You need to derive EmployX from DataSkin and some Zope persistent class such as SimpleItem. Otherwise, it won't be persistent.
Accualy I don´t have to do that.
Looking more closely at DataSkins.py, I see that class DataSkin derives from Persistent.
So, I was wrong -- please ignore what I said about needing to derive from Persistent :-)
Whoooha! I added PropertyManager to EmployX and it saves properties? Is this correct? - The objects are stored presistently in the Racks storage (BTree). - The attributes (and the propertysheet which is a attribute) are managed by the "PersistentAttributes" attribute provider. (Can I verify this by some kind of inspection?) - If I would create Attribute Providers (with SkinScripts) they could redirect the storage to what ever storage i like. Hm, I realize that I'm still very confused and the only way out of that is "doing stuff" and see what happens. Johanc PS. I uploaded the latest version of EmployX if anybody want to have a look. Its working now and should do basicly the same thing EmployZ does (except minor cahnges). http://www.zope.org/Members/johanc/EmployX
Johan Carlsson wrote:
Whoooha! I added PropertyManager to EmployX and it saves properties?
Is that a question? I'm not sure I can answer that.
Is this correct? - The objects are stored presistently in the Racks storage (BTree).
With the way a rack is set up by default, yes. You just say in the Rack what class it should store.
- The attributes
(and the propertysheet which is a attribute)
The properties in a propertysheet are stored as attributes. The propertysheet is a view on an instance's data.
are managed by the "PersistentAttributes" attribute provider.
The PersistentInternalAttributeProvider stores the attributes of an instance in a dict in the Rack. I had a conversation with Phillip Eby on this list a couple of months ago about exactly how PersistentInternalAttributeProviders and PersistentExternalAttributeProviders work. You should be able to find the messages in the list archives.
(Can I verify this by some kind of inspection?)
You can look through the ZODB from a python interactive prompt, and look inside a Rack's BTree to see how things are laid out. I think there are some HOT TO documents on looking in the ZODB from the python interactive prompt.
- If I would create Attribute Providers (with SkinScripts) they could redirect the storage to what ever storage i like.
Yes. You may want to set the Rack up differently, that is, so it doesn't store Dataskins persistently, but accesses them based on an id. Look at a Rack's tabs.
Hm, I realize that I'm still very confused and the only way out of that is "doing stuff" and see what happens.
I guess so :-) There's also reading the source code... which may or may not help clarify things. -- Steve Alexander Software Engineer Cat-Box limited http://www.cat-box.net
participants (5)
-
Charalampos Gikas -
Chris Withers -
Johan Carlsson -
Jon Franz -
Steve Alexander