[Grok-dev] towards a Grok release: current state of affairs
jdriessen at thehealthagency.com
Thu Jan 6 11:01:12 EST 2011
On 6 January 2011 16:18, Martijn Faassen <faassen at startifact.com> wrote:
> Hey JW,
> Thanks very much for this overview!
> On 01/05/2011 02:49 PM, Jan-Wijbrand Kolman wrote:
>> * Landing Fanstatic into grok, grokproject
>> As you most probably already know, we're about to change the way
>> Grok will handle static resources. This rather significant change
>> will be based on the Fanstatic project.
> I'll note that many in the Grok world already have used Fanstatic in its
> previous incarnation, named "hurry.resource". The main difference is
> that Fanstatic can also serve static resources itself. And that
> Fanstatic is tremendously more polished and documented. :)
> [fanstatic change implies]
> I think another change is that the Zope static resource publisher, for
> better or worse, publishes even .html files as zope page templates, i.e.
> it tries to interpret TAL in it. If you've been relying on this, it
> won't work with Fanstatic.
>> For the Fanstatic integration we now need to choose from two
>> 1) Require all "static" directories to be declared as
>> entry-points. Projects created through the ``grokproject``
>> tool could provide for an example setup to show how this is
>> done (and of course there will be upgrade documentation for
>> 2) keep the Grokker that looks for "static" directories and have
>> it register the correct Fanstatic libraries of resources.
>> The advantage of 1) is that there's one clear way for
>> registering libraries of resources, even if people need to learn
>> that this "registration" is now not done automatically anymore
>> *and* is different from other ways of registering components in
>> Grok. Another advantage is, that there is no hard dependency
>> for grokcore.view on Fanstatic.
>> The advantage of 2) is that the current behaviour of the
>> "static" directory is kept as closely as possible. Even if there
>> would now be in fact two ways for registering libraries of
>> resources in Grok. With such a grokker we would also introduce a
>> hard dependency on Fanstatic.
> I'm in favor of 2), to preserve the compatibility. I think in the case
> that someone really wants to extract a reusable library, they can go
> all-Fanstatic themselves. It's also Grok's job to automate registration
> tasks, and I think this includes Fanstatic registration tasks. I think
> it's okay for grokcore.view to rely on Fanstatic. Can we drop the
> dependency on zope.browserresource when we do that?
>From a grok perspective it makes sense to 'grok' the registration.
I'll work on the grokker.
This probably means that grokcore.view 2.3 should have never been released.
>> * Quite possibly there're several packages out there that somehow
>> rely on the ``static`` attribute that need to be updated in some
> I think there's some interesting interaction if you have a macro in
> package A, and then a template in package B that uses it.
> Grok-dev mailing list
> Grok-dev at zope.org
More information about the Grok-dev