Re: [Zope-dev] Proposed interface: Restricted creation
Toby Dickenson wrote: > I have a beautiful hack to do this for python products.. Which is exatly my point - you should not need to go through hoops in order something so simple. -- Itamar S.T. [EMAIL PROTECTED] Fingerprint = D365 7BE8 B81E 2B18 6534 025E D0E7 92DB E441 411C ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Proposed interface: Restricted creation
On Wed, 05 Jul 2000 19:42:38 +0300, Itamar Shtull-Trauring <[EMAIL PROTECTED]> wrote: >Shane Hathaway wrote: > >> The place where this is needed most (IMHO) is for ZClass factories. So >> there needs to be a way to create meta type filters through the Web. > >Yes, but in Python products too, where you have Items that should only go in >specific ItemHolders. This is very common. I have a beautiful hack to do this for python products.. Firstly, this code goes in your product __init__ def register__class(context,klass,**kwargs): meta_type = _register_product_specific_type(context,klass,kwargs) if meta_type: _meta_types_registry = _meta_types_registry+(meta_type,) def _register_product_specific_type(context,klass,kwargs): """Hijack and abuse the product registration system for our own product-specific type. The mechanism for creating instances of this product is established, but the type is not entered in the global availability list. """ # Register the class old = Products.meta_types[:] apply(context.registerClass,(klass,),kwargs) new = Products.meta_types if new[:-1]==old: # A new meta_type was added to the end of the global list, as expected. # Remove it, and return it Products.meta_types = old return new[-1] else: # Something unexpected happened. The safest thing to do is leave it alone return None Then, in your ObjectManager derived container, add def all_meta_types(self): return _meta_types_registry Then use register_xxx_class(context,.. in place of context.registerClass. Toby Dickenson [EMAIL PROTECTED] ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Proposed interface: Restricted creation
At 12:01 PM 7/5/00 -0400, Shane Hathaway wrote: >Itamar Shtull-Trauring wrote: >> I propose a Restricted Creation Interface - when an ObjectManager constructs >> it's Add list in manage_main, it first checks with each addable class if >> it's instances can be added in this specific ObjectManager. > >The place where this is needed most (IMHO) is for ZClass factories. So >there needs to be a way to create meta type filters through the Web. > >On the other hand, the plugins framework by Phillip Eby solves this >problem in a nice way. I'm hoping to eventually modify the plugins >framework so it's more accessible for ZClass development. I am too. :) If you have any ideas on how to make a ZClass constructor object that could work with PlugIns, I'm all ears. Right now, PlugIns have to be Python classes, although I think that it might be possible to make the PlugIn registry walk the entire ZClass registry, looking for things with a __plugin_kind__. That's something I'll want to look into when I get a chance. If you'd like to champion getting PlugIns into Zope as a standard feature, I am willing to contribute the code for ZPL use. Personally, given the small handful of other things I'd like to do to polish off PlugIns (such as documentation), I'm not sure now is the right time for making such a transition. ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Proposed interface: Restricted creation
Shane Hathaway wrote: > The place where this is needed most (IMHO) is for ZClass factories. So > there needs to be a way to create meta type filters through the Web. Yes, but in Python products too, where you have Items that should only go in specific ItemHolders. This is very common. > On the other hand, the plugins framework by Phillip Eby solves this > problem in a nice way. I'm hoping to eventually modify the plugins > framework so it's more accessible for ZClass development. Do you have > an application where plugins won't suffice? Not right now - but I'm sure someone will at some point, so why limit yourself? And why limit this to ZClasses only? -- Itamar S.T. [EMAIL PROTECTED] Fingerprint = D365 7BE8 B81E 2B18 6534 025E D0E7 92DB E441 411C ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Proposed interface: Restricted creation
Itamar Shtull-Trauring wrote: > I propose a Restricted Creation Interface - when an ObjectManager constructs > it's Add list in manage_main, it first checks with each addable class if > it's instances can be added in this specific ObjectManager. The place where this is needed most (IMHO) is for ZClass factories. So there needs to be a way to create meta type filters through the Web. On the other hand, the plugins framework by Phillip Eby solves this problem in a nice way. I'm hoping to eventually modify the plugins framework so it's more accessible for ZClass development. Do you have an application where plugins won't suffice? Shane ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] Proposed interface: Restricted creation
(URL:
http://www.zope.org/Members/michel/Projects/Interfaces/RestrictedCreation)
Restricted Creation of Objects
The problem - certain types of objects should not be added except in certain
places or with certain restrictions. For example, we may want to make sure
Laundry objects are only added inside Luggage objects, and nowhere else. Or
we may want to make sure that an object is added only if there's a MailHost
in it's acquistion path. How do we ensure this?
I propose a Restricted Creation Interface - when an ObjectManager constructs
it's Add list in manage_main, it first checks with each addable class if
it's instances can be added in this specific ObjectManager.
We do this by calling a class method called _addableIn(), that receives as a
parameter the ObjectManager to which we may want to add objects. If the
result is not true, instances of this class can't be added, and won't be
listed in the Add list.
For example, the following code will make the Laundry class show up in the
Add menu only in objectmanagers whose meta_type is "Luggage":
class Laundry(SimpleItem):
""" A Fruit class """
def _addableIn(parent):
if parent.meta_type == "Luggage": return 1
else: return 0
I'm not sure how to get from meta_type to class, so I can't show working
code, but something like this in ObjectManager.py would do the trick:
def filtered_meta_types(self, user=None):
# Return a list of the types for which the user has
# adequate permission to add that type of object.
user=getSecurityManager().getUser()
meta_types=[]
if callable(self.all_meta_types):
all=self.all_meta_types()
else:
all=self.all_meta_types
for meta_type in all:
> klass = getClassFromMetaType(meta_type)
>
> # If the class has a function _addableIn, it must return true or
> # that means the class doesn't want to be added to this ObjectManager:
>
> if not hasattr(klass, '_addableIn') or klass._addableIn(self):
> if meta_type.has_key('permission'):
> if user.has_permission(meta_type['permission'],self):
> meta_types.append(meta_type)
> else:
> meta_types.append(meta_type)
return meta_types
Comments?
--
Itamar S.T. [EMAIL PROTECTED]
Fingerprint = D365 7BE8 B81E 2B18 6534 025E D0E7 92DB E441 411C
___
Zope-Dev maillist - [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://lists.zope.org/mailman/listinfo/zope-announce
http://lists.zope.org/mailman/listinfo/zope )
