[Grok-dev] towards a Grok release: current state of affairs

[Jan-Jaap Driessen]

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
>>         options:
>>
>>         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
>>            this).
>>
>>         Or,
>>
>>         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
>>         way.
>
> 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.
[SNIP]
> Regards,
>
> Martijn
>
> _______________________________________________
> Grok-dev mailing list
> Grok-dev at zope.org
> https://mail.zope.org/mailman/listinfo/grok-dev
>



-- 
Jan-Jaap Driessen