[Grok-dev] getting the ball rolin' again: ZTK, zope.app.* and Grok-1.2

Martijn Faassen faassen at startifact.com
Tue Sep 7 09:39:14 EDT 2010


Hey JW,

On 08/30/2010 08:51 PM, Jan-Wijbrand Kolman wrote:

>     1) The ZTK-1.0 will have several zope.app.* package in the
>        "deprecated" list already. The goal is to move all zope.app.*
>        packages to the deprecated eventually. This aligns with our
>        work to free Grok from zope.app.*.
>
>     2) However, there are two zope.app.* packages that Grok depends
>        on that somehow need to be renamed or refactored into common
>        zope.* packages: zope.app.wsgi and zope.app.appsetup.

Perhaps it would be a decent opportunity to just merge them into a 
single package. Whether that makes a lot of sense I don't know, it's 
just something to consider.

> * Freeing Grok from zope.app.* dependencies. This work still needs to be
> finished. A lot of work has already gone into this and it is not the
> most fun work you could think of, but we need to finish it. Could I ask
> someone that has a somewhat clear overview of what needs to be done, to
> start a new thread about this particular topic?

I think we're now in a decent state on the trunk.. There are a few 
zope.app.* dependencies that are absolutely required, but otherwise 
we're pretty clean, I thought. Perhaps I'm missing something?

> * Towards 1.2: Besides the zope.app.* work, there a number of grokcore.*
> branches and related work that needs to be merged with Grok. Again, we
> need to have a separate thread about this topic, listing the todo items,
> and hopefully people that want to work on it.

Yeah:

* the long standing template registry refactoring

* and the even more long standing martian updates

> * Features? This is of course the most interesting part! Do we have
> features planned that really should be worked on soon? I do know of the
> ambitious plan around "A new publisher".

Recently I've been packaging a ton of jquery related libraries as 
hurry.resource components. We could consider packaging these together as 
a framework that's somehow related to Grok, together with some clues on 
how to put things together.

> The discussions about this topic sound very interesting. I can imagine
> though we also have more "down to earth" features, that we would like to
> see added to Grok. Or maybe we regard Grok as somewhat complete?

I think there are probably quite a few opportunities for stuff we can 
add, or change. It just takes a bit more active thinking to decide: hey, 
this could go into Grok!

A long-standing story is refactoring Grok so it's easier to drop support 
for something (such as grokui.admin, for example, or formlib support), 
or easily plug in new stuff (other form libraries for instance).

Thanks for opening this discussion!

Regards,

Martijn



More information about the Grok-dev mailing list