Creates classes available to container but NOT add products menu
RegisterClass is cool But what if you don't want to register your product. When you create a product and add a ZobjectManager derived Zclass, all subsequent subclasses appear in the subobject menu but not the Products menu. I have a heap of classes. I do not want every class in the add Products menu. I do want them to be available to the top level container class. How do I do this from within python product code. Chris
chrisf wrote:
RegisterClass is cool
But what if you don't want to register your product. When you create a product and add a ZobjectManager derived Zclass, all subsequent subclasses appear in the subobject menu but not the Products menu. I have a heap of classes. I do not want every class in the add Products menu. I do want them to be available to the top level container class. How do I do this from within python product code.
well, i'm just about having the same problem. i have a bunch of (report_part-)classes that i want to get registered in a class attribute of my report class and then dynamically (setattr) extend my report instance with attributes of report_part instances. as a starter, in <ZOPEROOT>/lib/python/App/ProductContext.py, registerClass is defined in class ProductContext. later, in lib/python/OFS/Application.py, with os.path all packet directories are traversed, looking for files __init__.py A ProductContext-Object is created like | context=ProductContext(productObject, app, product) and if the __init__.py file contains a method "initialize", it is called like | initmethod=pgetattr(product, 'initialize', None) | if initmethod is not None: | initmethod(context) but i'm still confused, mostly about when happens what, do i have to define my own registrar-object, if so, where etc., and, since my needs are less than zopes product registry, i could probably do with much less code. i look also into metapublisher, which also defines field classes and has a similar behaviour (field type classes are registered in MP). it also does with basically a traversal of the products subdirectories. any further hints welcomed ------------------------------------------------------------- Who's got only a hammer sees the world as a nail hans augustin (software developer) hans@beehive.de beehive elektronische medien GmbH http://www.beehive.de phone: +49 30 847-82 0 fax: +49 30 847-82 299
chrisf writes:
... I have a heap of classes. I do not want every class in the add Products menu. I do want them to be available to the top level container class. Not sure what is "the top level container class", but I expect your want something like
class MyTopLevelContainerClass(....): def all_meta_types(self): return ( {'name' : SUBTYPE1, 'action' : CONSTRUCTOR1, 'permission' : PERM1,}, {'name' : SUBTYPE2, 'action' : CONSTRUCTOR2, 'permission' : PERM2,}, {'name' : SUBTYPE3, 'action' : CONSTRUCTOR3, 'permission' : PERM3,}, ..... ) What's returned by "all_meta_types" is a sequence of product dispatchers. Each element describes one entry in the add list. "SUBTYPEi" is what you see in the add list entry (usually the meta type), "CONSTRUCTORi" is the name of the contructor (which of course must be accessible from your "MyTopLevelContainerClass" instance). "PERMi" is the permission name protecting the constructor. A user will see the entry only when he has this permission. For your future approaches: this already has been discussed in the mailing lists, maybe not as clear as above (that's the reason, why I do it again...). Searching the mailing list archives probably would have revealed the solution. Dieter
participants (3)
-
chrisf -
Dieter Maurer -
hans