RedstrictedCreation proposal
Re: http://dev.zope.org/Wikis/DevSite/Proposals/RestrictedCreation This proposal from Itamar has been up on dev.zope.org for a while, proposing a way for a registered type to control whether or not it can be added to a container, or a per-container basis. I now have an implementation of this in CVS in the toby-metatypes-branch. I propose this goes into zope 2.6. Any comments? (Ive CCed everyone who has commented on the proposal; I hope thats OK)
Toby Dickenson wrote:
Re: http://dev.zope.org/Wikis/DevSite/Proposals/RestrictedCreation
This proposal from Itamar has been up on dev.zope.org for a while, proposing a way for a registered type to control whether or not it can be added to a container, or a per-container basis.
I now have an implementation of this in CVS in the toby-metatypes-branch. I propose this goes into zope 2.6. Any comments?
Cool! I hear CMF 1.3 has some sort of restricted creation thing in it (other than the Types tool ability to limit things from the container's side.) It may just be "this object is not addable by default", and then the container would say explicitly that the object is addable in it. Anyone familiar with the details?
IMO, this comes at this at the wrong direction. Objects should not decide whether they can be added to a given folder, the folder should be the one that makes that decision. It gives me the heebie geebies to think that every time the add list is rendered, a whole slew of class methods are potentially called to determine what gets put there. This also invokes my ui chaos alarm. It gives things such arbitrary ability to dynamically affect the ui, that it may cause mass confusion by users who can't understand why an object is addable in one folder but not in another (seemingly identical) folder. Granted, this is somewhat possible right now (using permissions), but this pushes it a bit over the edge for me. It smells too much like magic. -Casey Toby Dickenson wrote:
Re: http://dev.zope.org/Wikis/DevSite/Proposals/RestrictedCreation
This proposal from Itamar has been up on dev.zope.org for a while, proposing a way for a registered type to control whether or not it can be added to a container, or a per-container basis.
I now have an implementation of this in CVS in the toby-metatypes-branch. I propose this goes into zope 2.6. Any comments?
(Ive CCed everyone who has commented on the proposal; I hope thats OK)
IMO, this comes at this at the wrong direction.
Objects should not decide whether they can be added to a given folder, the folder should be the one that makes that decision.
It gives me the heebie geebies to think that every time the add list is rendered, a whole slew of class methods are potentially called to determine what gets put there.
I think (correct me though, if I'm wrong!) that Toby actually implemented the suggestion that Jim made on the comments page of the proposal (add a filter to the meta type info, allowing products to do this without killing performance). We need to find a reasonable place to document the API addition for this before merging it. Brian Lloyd brian@zope.com V.P. Engineering 540.361.1716 Zope Corporation http://www.zope.com
Brian Lloyd wrote:
I think (correct me though, if I'm wrong!) that Toby actually implemented the suggestion that Jim made on the comments page of the proposal (add a filter to the meta type info, allowing products to do this without killing performance).
...but hasn't this problem already been solved with the wierd-interface-filter thing that Andreas did for the PluginIndexes stuff? cheers, Chris
On Tue, 9 Apr 2002 10:57:04 -0400, "Brian Lloyd" <brian@zope.com> wrote:
IMO, this comes at this at the wrong direction.
Objects should not decide whether they can be added to a given folder, the folder should be the one that makes that decision.
Zope can already do that. Check out how ZCatalog.Indexes requires all of its contained items to implement the PluggableIndex interface. That works well when you have a special folder type, but it doesnt help when you want to control whether special objects can be added to ordinary folders.
It gives me the heebie geebies to think that every time the add list is rendered, a whole slew of class methods are potentially called to determine what gets put there.
One function per type, if it was specified during registration. This isnt configurable through-the-web.
I think (correct me though, if I'm wrong!) that Toby actually implemented the suggestion that Jim made on the comments page of the proposal (add a filter to the meta type info, allowing products to do this without killing performance).
Thats correct. I changed the parameter name from Jim's suggestion; 'filter' to 'container_filter'.
We need to find a reasonable place to document the API addition for this before merging it.
Im happy to keep any documentation up to date, provided it is already up to date. Is there any more than the docstring? Suprisingly, I couldnt find any at http://www.zope.org/SiteIndex/search?text_content=registerClass Toby Dickenson tdickenson@geminidataloggers.com
After reading the discussion page I feel a bit more comfortable with it. I do see an undesireable increase in the entropy of the ui, however. This could be offset by careful use of this feature, of course. In fact good use of it could reduce some of the clutter in the add list. For instance, singleton classes might automatically hide themselves if they find an instance of themselves somewhere. As Chris M says: "The problem is dynamism" ;^) -Casey Brian Lloyd wrote: [snip my knee jerk reaction]
I think (correct me though, if I'm wrong!) that Toby actually implemented the suggestion that Jim made on the comments page of the proposal (add a filter to the meta type info, allowing products to do this without killing performance).
We need to find a reasonable place to document the API addition for this before merging it.
Brian Lloyd brian@zope.com V.P. Engineering 540.361.1716 Zope Corporation http://www.zope.com
participants (6)
-
Brian Lloyd -
Casey Duncan -
Chris Withers -
Itamar Shtull-Trauring -
Toby Dickenson -
Toby Dickenson