[Grok-dev] Re: on the name "Grok"
Philipp von Weitershausen
philipp at weitershausen.de
Tue Apr 29 08:20:17 EDT 2008
eric casteleijn wrote:
>> I think the mental work is minimal. Nobody objected when Five (due to
>> a technicality) had to introduce a BrowserView base class. five.grok
>> is in a way a special animal because it brings over some commonly used
>> components to Zope 2. I still don't think that bringing over all of
>> Grok is an important or even sensible goal. Therefore, five.grok will
>> always be just a subset. And to be honest, probably a small subset (I
>> suspect the future plone.grok will most likely be the rising star of
>> Grok technology on Zope 2).
>
> I'm mostly +0 on naming, although I do see a small advantage to having
> (some subset of) grok examples and documentation make sense for grok on
> zope 2.
I agree. Don't get me wrong, I think it's fantastic to have Grok serve
as an example for other systems. I also agree that the similarity
between five.grok and grok itself is attractive.
> I *do* think there is a big use case for grok technology on Zope 2 aside
> from building new applications. Building Extensions for Plone and Silva
> and other Zope 2 based frameworks could become a lot easier if we had
> groklike ways to remove boiler plate.
Absolutely. But it's all about *extensions* for existing Zope 2 stuff,
isn't it.
> This is the exact same use that
> Five had when we started using it in Silva, making it much easier to
> override small parts of Silva in an extension, and I think Grok will be
> an excellent way to make more boilerplate go away.
Yes, I think so too.
> I really wish we had the luxury to move away from the legacy platform,
> but it's not going to happen soon, and realistically, maybe never.
Not that it belongs into this discussion, but if you don't want
revolution, just evolution, "never" is probably your best bet. Evolution
can have various aspects, though. repoze is giving Zope 2 a completely
new life in the WSGI world, just like Five did in the Zope 3 world.
> No customer will pay for this, and the Silva community unfortunately isn't
> as big as Plone's so it's much harder to absorb such a huge investment.
>
> I sincerely hope though, that having a forward oriented way of extending
> Silva and Plone on Zope 2 will generate enthousiasm for Grok the web
> platform, and it would be great if the skills people acquire would be
> useful when they start to use grok itself, (or hell freezes over and we
> do manage to port to Zope 3 some happy day ;)
Indeed, the technical synergies between Grok and other platforms should
hopefully also reflect in community synergies. For that we don't
necessarily need the same (module) names, though.
More information about the Grok-dev
mailing list