[Grok-dev] grokproject + hurry.resource wsgi resource injection
trollfot at gmail.com
Mon Dec 6 09:30:48 EST 2010
My opinion is to use fantastic as the default.
I don't mind throwing away grokkers and stuff
Less code and less complexity is fine to me :)
2010/12/6 Jan-Jaap Driessen <jdriessen at thehealthagency.com>:
> On 14 November 2010 16:20, Jan-Jaap Driessen
> <jdriessen at thehealthagency.com> wrote:
>> At the Zope summit Jan-Wijbrand and Martijn cooked up ideas for
>> offloading the serving of resources from grok/zope to WSGI middleware.
>> During the sprint Christian Klinger and I worked on an implementation
>> of these ideas, based on work Martijn had already done in the most
>> recent versions of hurry.resource, hurry.zoperesource and serf. The
>> goal is to offload serving of resources to a WSGI component in order
>> not to make `expensive` calls to the zope publisher. It would be nice
>> if we could have backwards compatibility and some kind of easy
>> migration path.
>> I invite you to have a look at the following branch of grokproject,
>> which integrates the feature branches of hurry.resource and
>> (If you don't have svn access to svn.zope.org, change the [sources]
>> information in the resulting buildout.cfg from svn+ssh:// to http://)
>> The changes are documented here:
>> - http://svn.zope.org/hurry.resource/branches/janjaapdriessen-resource-publisher/CHANGES.txt?rev=118402&view=markup
>> - http://svn.zope.org/hurry.zoperesource/branches/janjaapdriessen-wsgi/CHANGES.txt?rev=118375&view=markup
>> As you fire up the newly created instance, you will notice I am not
>> the resource handling is actually working.
>> Turning the hurry.resource.publisher off is easy: remove the
>> publisher_prefix in the resource_injection part of parts/etc/debug.ini
>> and the resources will be served by zope.
>> Some caveats:
>> 1. Don't name your project 'foo', as this resource name is used in the project.
>> These issues are still on my todo list:
>> 1. Creating URLs to resources from page templates. As you can see in
>> the result of the grokproject run, the img generated by the page
>> template is still served by zope.
>> 2. ease of configuration: We should be able to turn caching/hashing on
>> and off in the paster configuration. This depends on whether the
>> application is running in dev mode or not.
>> 3. tests + documentation
>> 4. Make this functionality available in non-zope WSGI applications.
>> 5. Deployment: Does this setup play nice with Apache + mod_rewrite or
>> mod_wsgi? What about virtual hosting and ++skin++ information in the
>> 6. The publisher should not serve '.svn/entries' files and the like.
>> 7. Recalculate content-length header after modifying the body of the
>> request in the injection middleware.
>> And we may want to answer the following questions:
>> * What is the future of 'static' in grok?
>> * Should we make the wsgi injection middleware and the publisher into
>> one component instead of two, for ease of configuration?
>> * The hurry.resource.core._plugin is global. This means we can not run
>> multiple plugins in one runtime. Can we find another way of doing
>> * hash md5 vs zlib for computing hashes: Do you have any thoughts on
>> this? I used zlib.adler32 because it is fasted in Peter Bengtsson's
>> benchmarks 
>> Thank you in advance for your feedback,
>> Jan-Jaap Driessen
>> 1) http://www.peterbe.com/plog/using-md5-to-check-equality-between-files
> An updated version of grokproject + fanstatic is available on my branch:
> Some observations:
> 0. hurry.resource and hurry.zoperesource have been renamed to
> fanstatic and zope.fanstatic. They live on bitbucket now:
> 1. A feature branch of grokui.base is pulled in to make grokui.admin work.
> 2. A feature branch of grokcore.view is used to make 'static' work: I
> have dropped the static grokker from grokcore.view, in lieu of
> registering a fanstatic library under the name of the
> package/application. This means 'static' still works as you expect it
> to, as you can see in the page template in the result of a grokproject
> run. The only difference is that the files in the 'static' directory
> are served by the fanstatic publisher.
> 3. I duplicated the zope.conf into debug and deploy versions. These
> are referenced from the paster configuration file. If you start your
> application with debug.ini, both fanstatic and grok are started in
> debug mode. This means that page templates are re-evaluated after you
> change them, and URLs to resources are re-calculated for every
> If you start the application with deploy.ini, both fanstatic and grok
> are started in deploy mode. Page templates are read only once,
> resource URL calculations will be cached. The resources are injected
> into the page using minification, rollup and bottom-including
> techniques (only if rollupped and/or minified versions are available
> for your resources that is).
> 4. You cannot use the '++resource++foo/icon.png' notation in CSS any
> more. Use relative paths instead. I wonder if these kind of URLs were
> ever supposed to be used in this way.
> And one question:
> What is the future of grok and fanstatic? Will fanstatic be an
> integral part of a grok application for serving resources? In that
> case, we can remove the DirectoryResource code from grokcore.view. We
> can remove the code in grok that handles resources, such as
> DirectoryResource in grokcore.view.
> I would like to hear your opinion.
> -- JJ
> Grok-dev mailing list
> Grok-dev at zope.org
More information about the Grok-dev