[Zope-dev] Dependencies and future of zope 3

[David Pratt]

Hi Martijn. As a side note I have found immense value in the effort to 
split out the grok packages as it is has been very useful in my own 
development. I have been looking for you on irc to discuss this further 
to create a grokcore.traverser package and another package to abstract 
grok.Model (that depends more upon grokcore.component), grok.Container 
and grok.Application.

This abstraction paves the way for general usage of megrok.rdb, 
megrok.rdb, and megrok.trails without the grok dependency and can bring 
the general usage of the model concept into regular z3. You would not 
believe how much this can reduce the volume of your package with these 
things.

My preference is not to develop in grok, but at the same time these 
packages are excellent as I can selectively use them to reduce 
configuration and volume in my packages and not loose anything in the 
process so it is very much appreciated what you have done here.


Martijn Faassen wrote:
> Benji York wrote:
>> On Wed, Sep 3, 2008 at 8:40 AM, David Pratt <fairwinds.dp at gmail.com> wrote:
>>
>>> I am trying to avoid the need for selective forking that Chris has found
>>> necessary to make progress with bfg. I want to continue using zope [...]
>> +1  Experimental forks to help determine what refactoring need to be
>> done in the "mother" package are fine, but I hope that the findings of
>> Plone, Grok, and repoze/bfg can all be folded back in.
> 
> Agreed with this. We want Zope 3 packages to move forward, so I'm very 
> glad that David took up this discussion. It's important we develop a bit 
> of vision here, some guidelines, and a plan on how to get there step by 
> step.
> 
> Note that Grok hasn't been forking Zope 3 packages. We've built a few 
> packages on top of Zope 3 that are now reusable with straight Zope 3 
> too, to wit, grokcore.component, grokcore.view and grokcore.security and 
> soon grokcore.formlib. Grok has its own approaches of course, but one 
> thing we spent quite a bit of time on is to be good Zope 3 citizens.
> 
> Grok 0.14 will be built on top of these grokcore.*, and we took pains to 
> make these compatible with straight Zope 3 projects as well. This means 
> that if you want Grok-style configuration of adapters, views and 
> utilities in your Zope 3 project or library you can use these projects. 
> I have a few z3c packages sitting around that I hope to convert to use 
> these once Grok 0.14 is released. These packages are already finding 
> some uptake in Zope 2 projects as well. It's been interesting to see how 
> the requirements to reuse bits of Grok in Zope 3 and Zope 2 have been 
> pulling togeter to help factor these packages out.
> 
> I think the only bit that you can really consider a 'fork' is 
> grokproject itself, which is like an improved zopeproject. If someone 
> wants to take it up, we could start factoring out a common core there as 
> well.
> 
> Regards,
> 
> Martijn
> 
> _______________________________________________
> Zope-Dev maillist  -  Zope-Dev at zope.org
> http://mail.zope.org/mailman/listinfo/zope-dev
> **  No cross posts or HTML encoding!  **
> (Related lists - 
>  http://mail.zope.org/mailman/listinfo/zope-announce
>  http://mail.zope.org/mailman/listinfo/zope )
>