[Zope3-dev] Re: AW: Re: The elevator speech for Zope 3
Hey, On 10/8/07, Philipp von Weitershausen <[EMAIL PROTECTED]> wrote: > Martijn Faassen wrote: [snip] >> ... emit configuration actions instead of component > > registrations directly. This is underway, started at the sprint last > > week by Godefroid Chapelle. > > Great! Where can this work be seen? Good question. I thought there was a branch but I can't find any. This definitely needs some followup from Godefroid, to at least check his work into a branch of Grok: Godefroid? > > * split up Grok into separate components that are independently > > reusable, without having to pull in the whole of Grok to use this. > > Philipp wanted to start this work but I'm not sure about its status. > > There's a branch that works and has tests [1], but I need to speak to > you about some quirks that the current Grokker story has. Some > refactoring in Martian would make this much easier. I will bring this up > on grok-dev. Okay, thanks, see you there. Hopefully we can get martian fixed for this quickly. Regards, Martijn ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: AW: Re: The elevator speech for Zope 3
Martijn Faassen wrote: Does grok support a component architecture where I can use some components from or is grok a "use it all or nothing concept"? Grok *aims* to support reusing bits of it. It hasn't reached this goal yet as we focused on making it work first, but has been an explicit seocndary goal from the beginning last year. We need to do some things to make this possible: * Done: Grok's mechanism of scanning for classes and instances in modules and issuing some form of configuration has been factored out into the martian library. * as Philipp mentioned, emit configuration actions instead of component registrations directly. This is underway, started at the sprint last week by Godefroid Chapelle. Great! Where can this work be seen? * split up Grok into separate components that are independently reusable, without having to pull in the whole of Grok to use this. Philipp wanted to start this work but I'm not sure about its status. There's a branch that works and has tests [1], but I need to speak to you about some quirks that the current Grokker story has. Some refactoring in Martian would make this much easier. I will bring this up on grok-dev. * related to this, Grok turns off some of Zope 3's security infrastructure (for content objects, not for views). The Grok core should continue doing this for the forseeable future, but of course if you want to reuse other bits of Grok standalone this shouldn't come along. So, this is slowly but surely coming nearer. We want Grok to be a unified story for most users, so this is not our *primary* goal, but we do want Grok's work to be reusable in other Zope 3 projects as well. [1] http://svn.zope.org/grok/branches/philikon-grokcore.component/ -- http://worldcookery.com -- Professional Zope documentation and training ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
AW: [Zope3-dev] Re: AW: Re: The elevator speech for Zope 3
Hi Martijn > Betreff: [Zope3-dev] Re: AW: Re: The elevator speech for Zope 3 [...] > Grok *aims* to support reusing bits of it. It hasn't reached > this goal yet as we focused on making it work first, but has > been an explicit seocndary goal from the beginning last year. > > We need to do some things to make this possible: > > * Done: Grok's mechanism of scanning for classes and > instances in modules and issuing some form of configuration > has been factored out into the martian library. > > * as Philipp mentioned, emit configuration actions instead of > component registrations directly. This is underway, started > at the sprint last week by Godefroid Chapelle. > > * split up Grok into separate components that are > independently reusable, without having to pull in the whole > of Grok to use this. > Philipp wanted to start this work but I'm not sure about its status. > > * related to this, Grok turns off some of Zope 3's security > infrastructure (for content objects, not for views). The Grok > core should continue doing this for the forseeable future, > but of course if you want to reuse other bits of Grok > standalone this shouldn't come along. > > So, this is slowly but surely coming nearer. We want Grok to > be a unified story for most users, so this is not our > *primary* goal, but we do want Grok's work to be reusable in > other Zope 3 projects as well. Cool, sounds promising Regards Roger Ineichen > Regards, > > Martijn > > > ___ > Zope3-dev mailing list > Zope3-dev@zope.org > Unsub: > http://mail.zope.org/mailman/options/zope3-dev/dev%40projekt01.ch > > ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: AW: Re: The elevator speech for Zope 3
Roger Ineichen wrote: Hi Philipp Betreff: Re: [Zope3-dev] Re: The elevator speech for Zope 3 [...] Soon, we will change Grok so that it emits configuration actions, rather than doing the registrations right away. That way, you will still be able to inspect what exactly Grok is doing (for example by dumping all configuration actions before or instead of executing them), but you won't have to deal with ZCML anymore. You will also be able to use the overrides mechanism with them. I don't know much about grok. But this sounds interesting. Does grok support a component architecture where I can use some components from or is grok a "use it all or nothing concept"? Grok *aims* to support reusing bits of it. It hasn't reached this goal yet as we focused on making it work first, but has been an explicit seocndary goal from the beginning last year. We need to do some things to make this possible: * Done: Grok's mechanism of scanning for classes and instances in modules and issuing some form of configuration has been factored out into the martian library. * as Philipp mentioned, emit configuration actions instead of component registrations directly. This is underway, started at the sprint last week by Godefroid Chapelle. * split up Grok into separate components that are independently reusable, without having to pull in the whole of Grok to use this. Philipp wanted to start this work but I'm not sure about its status. * related to this, Grok turns off some of Zope 3's security infrastructure (for content objects, not for views). The Grok core should continue doing this for the forseeable future, but of course if you want to reuse other bits of Grok standalone this shouldn't come along. So, this is slowly but surely coming nearer. We want Grok to be a unified story for most users, so this is not our *primary* goal, but we do want Grok's work to be reusable in other Zope 3 projects as well. Regards, Martijn ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
