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

[Jan-Jaap Driessen]

On 6 January 2011 17:52, Jan-Wijbrand Kolman <janwijbrand at gmail.com> wrote:
> On 1/6/11 17:01 PM, Jan-Jaap Driessen wrote:
>>> 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.
>
> Cool.
>
> regards, jw

Or not so cool :(

I created a branch based on grokcore.view 2.2, in which I replaced the
DirectoryResource by a ZopeFanstaticResource in the
StaticResourcesGrokker:

http://zope3.pov.lt/trac/changeset/119442

Note that the fanstatic.Library is created on the fly based on a name
and a resource path.

I then made the necessary changes to grokproject: removing the
fanstatic.libraries entry_point and the Library() in resource.py. (I
didn't check in these changes.)

When resources are referenced from ZPT through the static attribute of
the view, all is jolly good. However, when I want define
fanstatic.Resource instances in order to 'need()' them in a view, I
don't have a reference to the Library object:

http://zope3.pov.lt/trac/browser/grokproject/trunk/grokproject/template/src/%2Bpackage%2B/resource.py_tmpl

(I could access the 'static' Library instance by going through
fanstatic.get_library_registry[moduleinfo.package_dottedname], but
this seems like an unstable hack.)

I am inclined to reverse the static grokker code and return to
grokcore.view 2.3. Input from a fresh set of eyes and mind would be
much appreciated at this moment.


Cheers,

-- 
Jan-Jaap Driessen