[Grok-dev] "static" library registration. Was: towards a Grok release: current state of affairs

[Jan-Wijbrand Kolman]

On 1/6/11 16:18 PM, Martijn Faassen wrote:
>> >           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?

and

On 1/7/11 16:56 PM, Jan-Jaap Driessen wrote:
> 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

After much more deliberation, we do not see clear way around the 
implication Jan-Jaap found when implementing solution 2):

When we register a fanstatic.Library from a StaticGrokker, there will be 
no reference to this Library and thus no fanstatic.Resource instances 
can be defined for this library in the application that is being 
developed (I'm not talking about extracting reusable libraries of 
resources here).

An application developer then would need to define his own Library for 
his set of need()-able resources, and a quite obvious name for this 
Library would be to choose the name of application package he is 
developing. This name would then clash with the automatically registered 
Library name.

This clash would not be so obvious if he were to refer to the directory 
called "static" in his newly created Library instance, as things would 
probably continue to work  - the fanstatic library registry is basically 
a dict, so the last one to register there, would "win".

If this developer were to refer to another directory in his project 
however, the static *attribute* on views would not have access to 
resources in the directory called "static" anymore, as the Library 
registered under the package name suddenly is the one created by the 
developer.


At this point, I'm inclined too, to have grokproject generate a setup.py 
that sets up an entry point, and have it generate code that defines a 
Library instance for the directory called "static" in the newly created 
project.

We will of course need to write upgrade documentation for people who 
want to upgrade from a an earlier grok to the one that will contain 
fanstatic integration. This upgrade documentation will essentially tell 
to add entry points to the project's setup.py and how to define the 
corresponding Library instances.

regards, jw