Re: [Zope3-dev] RFC: Local Component Management Simplification
On 2/2/06, Jim Fulton <[EMAIL PROTECTED]> wrote: > I've posted a proposal to simplify local component management at: > >http://dev.zope.org/Zope3/LocalComponentManagementSimplification I just realized something is missing in Five, and I think it might be missing in Zope3 too. I'm currently trying to write import/export adapters for genericsetup for local utilities, and I realized that there is no way to get ONLY the local utilities in a specific context. That means I can't write an export adapter, since the api methods all will return both the local and the global utilities, and only the local ones should be exported. I might find a trick around this (mainly, I think I'll call it twice, once for the context and once for the contexts parent, and just export the difference), but it would be nice not to have to do "tricks"... Or? -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.cps-project.org/ ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] RFC: Local Component Management Simplification
On Monday 06 February 2006 12:33, Dieter Maurer wrote: > >No it is not. Explicit is better then implicit. "declareSite" creates a > > new site in the sites mapping. We use this pattern for layers and skins > > already. > > If it *creates* something why itn't its name "createSite" > (rather than "declareSite"). As I said, the names were not set in stone. FRom my understanding of English both are fine. > And what does "site" as it apparently does not create nor declare a > site? It declares that all the configuration elements inside it are configuration elements of this site. I originally wanted to add a new attribute to configure called "site", but then I do not want to make configure the place where we put all things that provide wrapper behavior. On the other hand, defining the site of application is so fundamental that we should place it there. So based on your suggestions: ... http://namespaces.zope.org/zope"; i18n_domain="zope" site="mysite"> ... Regards, Stephan -- Stephan Richter CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] RFC: Local Component Management Simplification
Stephan Richter wrote at 2006-2-5 09:32 -0500: > ... >On Friday 03 February 2006 17:23, Dieter Maurer wrote: >> Stephan Richter wrote at 2006-2-3 12:45 -0500: >> > ... >> > >> > >> > >> > >> > >> >> The "declareSite" looks redundant. I see at the "site name='mysite'" >> element that a site with name "mysite" is declared... > >No it is not. Explicit is better then implicit. "declareSite" creates a new >site in the sites mapping. We use this pattern for layers and skins already. If it *creates* something why itn't its name "createSite" (rather than "declareSite"). And what does "site" as it apparently does not create nor declare a site? -- Dieter ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] RFC: Local Component Management Simplification
On Friday 03 February 2006 17:23, Dieter Maurer wrote: > Stephan Richter wrote at 2006-2-3 12:45 -0500: > > ... > > > > > > > > > > > > The "declareSite" looks redundant. I see at the "site name='mysite'" > element that a site with name "mysite" is declared... No it is not. Explicit is better then implicit. "declareSite" creates a new site in the sites mapping. We use this pattern for layers and skins already. Regards, Stephan -- Stephan Richter CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] RFC: Local Component Management Simplification
Stephan Richter wrote at 2006-2-3 12:45 -0500: > ... > > > > > The "declareSite" looks redundant. I see at the "site name='mysite'" element that a site with name "mysite" is declared... -- Dieter ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] RFC: Local Component Management Simplification
Amos Latteier wrote: Hi, In general I like the proposal, but I have a small nit: registerSubscriptionAdapter's signature indicates that one of its arguments is "adapts", but the docstring indicates that it is named "required". The same thing is true with unregisterSubscriptionAdapter, registerHandler, and unregisterHandler. Which is preferred, "adapts" or "required"? Adapts seems more natural to me since it echoes the name of the adapts() function, but perhaps I'm missing something that makes "required" more appropriate. Oops. Fixed. I don't know where "adapts" came from. Thanks. Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] RFC: Local Component Management Simplification
Hi, In general I like the proposal, but I have a small nit: registerSubscriptionAdapter's signature indicates that one of its arguments is "adapts", but the docstring indicates that it is named "required". The same thing is true with unregisterSubscriptionAdapter, registerHandler, and unregisterHandler. Which is preferred, "adapts" or "required"? Adapts seems more natural to me since it echoes the name of the adapts() function, but perhaps I'm missing something that makes "required" more appropriate. -Amos ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] RFC: Local Component Management Simplification
Stephan Richter wrote: ... I just noticed that we have a slight paradigm shift here now; Subscriptions are split into subscriptions and handlers. I like that distinction, but it needs to be well-documented and communicated. I don't disagree, except to note that that split happened some time ago. Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] RFC: Local Component Management Simplification
On Friday 03 February 2006 07:06, Jim Fulton wrote: > I've updated the proposed APIs. I changed wording from "provide" to > "register" as "unprovide" doesn't make sense. (This also conglicts less > with existing APIs.) Like Dominik, I like the API as well. > Comments and questions are still welcome. I just noticed that we have a slight paradigm shift here now; Subscriptions are split into subscriptions and handlers. I like that distinction, but it needs to be well-documented and communicated. Regards, Stephan -- Stephan Richter CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] RFC: Local Component Management Simplification
On Friday 03 February 2006 07:17, Jim Fulton wrote: > Good point. I'm liking your proposal. It deserves some more thought. > However, another way to do the same thing woyuld be to allow ZCML to > define multiple registries and have a way of saying that a site of a > particular kind should use an additional ZCML-defined base registry. Here is what I would like for the ZCML side of things; clearly the names are pending: What should happen with the above> I imagine a simple mapping of several sites; of course there is the default site, so that things are backward-compatible. The "site" directive then sets a context variable and then the directives are registered for that site instead the default. Once all this is done, you can go into your UI and say which bases a local site should have. This should allow one to perfectly customize a site for a customer. As I said before, I will develop a proposal in the following weeks. Regards, Stephan -- Stephan Richter CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] RFC: Local Component Management Simplification
On Friday 03 February 2006 07:17, Jim Fulton wrote: > BTW, the new adapter registries have __bases__ attributes and > support multiple base registries. The same will probably hold for > component registries (that handle both adapters and utilities). > So, one could have a local registry that stores it's data in the ZODB > and that has as one of it's bases a ZCML-defined registry that is > separate from the normal global registry. Yeah, I am s excited about that! :-) I can barely wait for it to land, so I can do a proposal on how to use this effectively. ;-) Regards, Stephan -- Stephan Richter CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] RFC: Local Component Management Simplification
On Friday 03 February 2006 06:17, Martijn Faassen wrote: > > I have already demonstrated such behavior in the bugtracker package. You > > can use subscribers for it as well. > > Could you be a bit more specific on where in the bugtracker package I > should be looking to find this behavior? Sure. I must have taken out the site-specific stuff, but AddBugTracker in bugtracker.browser.tracker shows how you have on the fly additional setup stuff. But Ia m sure subscribers to IObjectAddedEvent are a better patterns to use. You could also write a custom IFactory, but tgat might be too much work. Regards, Stephan -- Stephan Richter CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] RFC: Local Component Management Simplification
Jim Fulton wrote: Dominik Huber wrote: Jim Fulton wrote: One issue with subscribers currently is that ZCML subscriber directives can't be overridden. We need a fix for this. In my understanding this usecase is covered by the new implementation, isn't it? What new implementation? The proposed interface IComponentRegistry says: def unregisterSubscriptionAdapter(factory=None, adapts=None, provides=None, name=u''): """Register a subscriber factory ... factory This is the object used to compute the adapter. The factory can be None, in which case any factories registered to implement the given provided interface for the given required specifications with the given name are unregistered. """ I thougt the planned component registry implementation covers that use case in principle, doesn't it? Regards, Dominik ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] RFC: Local Component Management Simplification
Jim Fulton wrote: Dominik Huber wrote: Jim Fulton wrote: I've updated the proposed APIs. I changed wording from "provide" to "register" as "unprovide" doesn't make sense. (This also conglicts less with existing APIs.) I like the new wording. Do you offer the new wording within the zapi too? I'd prefer to get rid of zapi. Back when we used context wrappers, there were a lot more dead chickens in our code that zapi helped to manage. I personally never (well almost never) use zapi anymore. I would say that, in general, indirection is bad. In many cases, indirection is also good. It should only be used when the good of a particular indirection significantly outweighs the bad. IMO, the benefits of zapi don't outweight it's inherent obfuscation. +1, but then I have to change my question. Do you reflect the new wording within zope.component too? zope.component.registerAdapter ... and deprecate the old ones eventually zope.component.provideAdapter ... Regards, Dominik ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] RFC: Local Component Management Simplification
Dominik Huber wrote: I like the new wording. Do you offer the new wording within the zapi too? That would be cool. Personally, I'd like it if zope.app.zapi was deprecated all-together. It doesn't really provide anything useful other than an overly-large amalgam of APIs. I'd assert that importing the package you really want to use is "cleaner" and a few more lines of imports isn't going kill anyone and definitely isn't worth the added indirection and duplication. -- Benji York Senior Software Engineer Zope Corporation ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] RFC: Local Component Management Simplification
Dominik Huber wrote: Jim Fulton wrote: One issue with subscribers currently is that ZCML subscriber directives can't be overridden. We need a fix for this. In my understanding this usecase is covered by the new implementation, isn't it? What new implementation? Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] RFC: Local Component Management Simplification
Dominik Huber wrote: Jim Fulton wrote: I've updated the proposed APIs. I changed wording from "provide" to "register" as "unprovide" doesn't make sense. (This also conglicts less with existing APIs.) I like the new wording. Do you offer the new wording within the zapi too? I'd prefer to get rid of zapi. Back when we used context wrappers, there were a lot more dead chickens in our code that zapi helped to manage. I personally never (well almost never) use zapi anymore. I would say that, in general, indirection is bad. In many cases, indirection is also good. It should only be used when the good of a particular indirection significantly outweighs the bad. IMO, the benefits of zapi don't outweight it's inherent obfuscation. Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] RFC: Local Component Management Simplification
Jim Fulton wrote: One issue with subscribers currently is that ZCML subscriber directives can't be overridden. We need a fix for this. In my understanding this usecase is covered by the new implementation, isn't it? Regards, Dominik ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] RFC: Local Component Management Simplification
Jim Fulton wrote: I've updated the proposed APIs. I changed wording from "provide" to "register" as "unprovide" doesn't make sense. (This also conglicts less with existing APIs.) I like the new wording. Do you offer the new wording within the zapi too? That would be cool. zapi.registerAdapter() zapi.unregististerAdapter() ... Regards, Dominik ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] RFC: Local Component Management Simplification
Martijn Faassen wrote: Jim Fulton wrote: I've posted a proposal to simplify local component management at: http://dev.zope.org/Zope3/LocalComponentManagementSimplification Comments and questions are welcome. I like the proposal. I'm trying to figure out what this means exactly: """ Registries may place restrictions on objects registered. In particular, local registries stored in the ZODB will have to be able to store registered objects (or references to registered objects) in the ZODB. """ So, this means that for a ComponentRegistry that's in the ZODB (non-global), Note that "non-global" and "stored in the ZODB" need not be correlated, For example, a local registry need not store it's information in the ZODB. Or, for that matter, a registry could conceivably store data in the ZODB and in memory. My only point is that an implementation is allowed to place restructions on registered components not mentioend here, > the utility you want to register needs to be pickleable, or 'referenceable'. How would such a reference to a registered object that's not in the ZODB work? This is up to the implementation. BTW, the new adapter registries have __bases__ attributes and support multiple base registries. The same will probably hold for component registries (that handle both adapters and utilities). So, one could have a local registry that stores it's data in the ZODB and that has as one of it's bases a ZCML-defined registry that is separate from the normal global registry. Related to this, I'm looking for a new (the horror!) ZCML knob which would allow me to say: For this content object (that is a site), when it's installed into the ZODB (like a CMFSite or a Silva Root), please also install the following local utilities (catalog, intid utility, etc). Here's an idea that I haven't really thought through: ... this would set up somekind of subscriber for IMySite so that whenever an object providing IMySite is added to a container, a local utility of type mycatalog.Catalog would be set up in it straight away. As mentioned by Stephan, you can simply set up a subscriber. One issue with subscribers currently is that ZCML subscriber directives can't be overridden. We need a fix for this. The component registration interface as proposed would help some setup code cleaner, but having such functionality in ZCML would clean up quite a bit more registration code -- right now we have an event handler that gets called when a site is added, and then calls a lot of Python code to do the utility setup. It's lots of code that is really doing configuration expressed as Python. Good point. I'm liking your proposal. It deserves some more thought. However, another way to do the same thing woyuld be to allow ZCML to define multiple registries and have a way of saying that a site of a particular kind should use an additional ZCML-defined base registry. (Of course in case of a catalog this sort of begs the question whether setting up catalog indexes should be configurable through ZCML too...) Yup. BTW, I like the Plone (CMF?) mechanism in which a product can specify an installation UI so that someone can walk up to a site TTW and elect interactively to install a product. Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] RFC: Local Component Management Simplification
Jim Fulton wrote: I've posted a proposal to simplify local component management at: http://dev.zope.org/Zope3/LocalComponentManagementSimplification Comments and questions are welcome. I hope to begin working on this this weekend on my adapter redesign branch: http://svn.zope.org/Zope3/branches/jim-adapter/ I'd love to get some help on the UI. :) As Stephan pointed out, I forgot to provide an API for unregistering components. This is obviously important for persistent registries, but would also be useful for in-memory registries for use in test tear-down code. I've updated the proposed APIs. I changed wording from "provide" to "register" as "unprovide" doesn't make sense. (This also conglicts less with existing APIs.) Comments and questions are still welcome. Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] RFC: Local Component Management Simplification
Stephan Richter wrote: On Thursday 02 February 2006 11:50, Martijn Faassen wrote: or this content object (that is a site), when it's installed into the ZODB (like a CMFSite or a Silva Root), please also install the following local utilities (catalog, intid utility, etc). I have already demonstrated such behavior in the bugtracker package. You can use subscribers for it as well. Could you be a bit more specific on where in the bugtracker package I should be looking to find this behavior? Regards, Martijn ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] RFC: Local Component Management Simplification
On Thursday 02 February 2006 11:50, Martijn Faassen wrote: > (Of course in case of a catalog this sort of begs the question whether > setting up catalog indexes should be configurable through ZCML too...) Note that as soon as Jim is done with his work I will write and publish a proposal on how to use ZCML to define and fill multiple sites via ZCML and then use those sites as bases on local sites. The Plone community has a lot of interest in this and I will need this for SchoolTool as well. I am committed in writing and implementing the proposal. Regards, Stephan -- Stephan Richter CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] RFC: Local Component Management Simplification
On Thursday 02 February 2006 12:47, Jim Fulton wrote: > > I like the proposal too, but if we start to allow utilities within the > > content-space, this unregistering or reregistering should be highly > > transparent for end-user. > > Therefore it might be still usefull to provide a marker interface such > > as ILocalUtility that can be triggered by little un/re-registering > > framework using the annotation of an utility to remember its > > registration-dependencies. > > It should be able to quert the components registry to determin it's > registrations. Yep, the current API is quiet good: utility = ... IRegistered(utility).registrations Overall, I agree with Jim that the CA can be extended in the the outlined, but I do like several features of the current way. And the way you interact on the registration level is one of them, though I admit writing different registration objects becomes old quickly, as we figured out this week working on WebDev. Regards, Stephan -- Stephan Richter CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] RFC: Local Component Management Simplification
On Thursday 02 February 2006 11:50, Martijn Faassen wrote: > or this content object (that is a site), when it's installed into the > ZODB (like a CMFSite or a Silva Root), please also install the following > local utilities (catalog, intid utility, etc). I have already demonstrated such behavior in the bugtracker package. You can use subscribers for it as well. Regards, Stephan -- Stephan Richter CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] RFC: Local Component Management Simplification
Dominik Huber wrote: Stephan Richter wrote: On Thursday 02 February 2006 07:38, Jim Fulton wrote: Comments and questions are welcome. I like the proposal in general. The big missing use case that is missing for me is the task of unregistering or reregistering a persistent component. I like the proposal too, but if we start to allow utilities within the content-space, this unregistering or reregistering should be highly transparent for end-user. Therefore it might be still usefull to provide a marker interface such as ILocalUtility that can be triggered by little un/re-registering framework using the annotation of an utility to remember its registration-dependencies. It should be able to quert the components registry to determin it's registrations. Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] RFC: Local Component Management Simplification
Stephan Richter wrote: On Thursday 02 February 2006 07:38, Jim Fulton wrote: Comments and questions are welcome. I like the proposal in general. The big missing use case that is missing for me is the task of unregistering or reregistering a persistent component. I like the proposal too, but if we start to allow utilities within the content-space, this unregistering or reregistering should be highly transparent for end-user. Therefore it might be still usefull to provide a marker interface such as ILocalUtility that can be triggered by little un/re-registering framework using the annotation of an utility to remember its registration-dependencies. Regards, Dominik ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] RFC: Local Component Management Simplification
Jim Fulton wrote: I've posted a proposal to simplify local component management at: http://dev.zope.org/Zope3/LocalComponentManagementSimplification Comments and questions are welcome. I like the proposal. I'm trying to figure out what this means exactly: """ Registries may place restrictions on objects registered. In particular, local registries stored in the ZODB will have to be able to store registered objects (or references to registered objects) in the ZODB. """ So, this means that for a ComponentRegistry that's in the ZODB (non-global), the utility you want to register needs to be pickleable, or 'referenceable'. How would such a reference to a registered object that's not in the ZODB work? Related to this, I'm looking for a new (the horror!) ZCML knob which would allow me to say: For this content object (that is a site), when it's installed into the ZODB (like a CMFSite or a Silva Root), please also install the following local utilities (catalog, intid utility, etc). Here's an idea that I haven't really thought through: ... this would set up somekind of subscriber for IMySite so that whenever an object providing IMySite is added to a container, a local utility of type mycatalog.Catalog would be set up in it straight away. The component registration interface as proposed would help some setup code cleaner, but having such functionality in ZCML would clean up quite a bit more registration code -- right now we have an event handler that gets called when a site is added, and then calls a lot of Python code to do the utility setup. It's lots of code that is really doing configuration expressed as Python. (Of course in case of a catalog this sort of begs the question whether setting up catalog indexes should be configurable through ZCML too...) Regards, Martijn ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] RFC: Local Component Management Simplification
Stephan Richter wrote: On Thursday 02 February 2006 07:38, Jim Fulton wrote: Comments and questions are welcome. I like the proposal in general. The big missing use case that is missing for me is the task of unregistering or reregistering a persistent component. In the ZODB I need to be able to remove a registration when deleting a component or reregister it when information changed. The current API is nice in supporting this and the functionality cannot be lost. Oops. that's a huge hole. Doh! OK, I'll fix that. (Probably won't be until tomorrow.) Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] RFC: Local Component Management Simplification
On Thursday 02 February 2006 07:38, Jim Fulton wrote: > Comments and questions are welcome. I like the proposal in general. The big missing use case that is missing for me is the task of unregistering or reregistering a persistent component. In the ZODB I need to be able to remove a registration when deleting a component or reregister it when information changed. The current API is nice in supporting this and the functionality cannot be lost. Regards, Stephan -- Stephan Richter CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] RFC: Local Component Management Simplification
I've posted a proposal to simplify local component management at: http://dev.zope.org/Zope3/LocalComponentManagementSimplification Comments and questions are welcome. I hope to begin working on this this weekend on my adapter redesign branch: http://svn.zope.org/Zope3/branches/jim-adapter/ I'd love to get some help on the UI. :) Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
