checked in: megrok.resourcelibrary

[Martijn Faassen-2]

Hi there,

I just checked in a package called megrok.resourcelibrary. It wraps
zc.resourcelibrary and all the real functionality is in that library,
this just grokifies it. In essence megrok.resourcelibrary lets you set
up your own new 'static' directories.

What you can do with this is the following:

import megrok.resourcelibrary

class MyResources(megrok.resourcelibrary.ResourceLibrary):
     megrok.resourcelibrary.directory('some_directory')

Your resources will then be published under:

http://localhost/@@/myresources

The library allows you to declare you actually need some resources in
the head section of a HTML page whenever you use them:

class MyResources(megrok.resourcelibrary.ResourceLibrary):
    megrok.resourcelibrary.directory('some_directory')
    megrok.resourcelibrary.include('foo.js')
    megrok.resourcelibrary.include('bar.css')

This will make 'foo.js' and 'bar.css' whenever you use this resource
library in a page. You can declare this requirement like this in a ZPT:

   <tal:block replace="resource_library: myresources" />

or like this in Python code that is used to display the page (such as in
a widget that needs some javascript to be included):

   MyResources.need()

There are some other features, some of which are undertested, such as
putting resources in a particular layer. There's also a feature that I
did try to test but doesn't work yet, protecting resources behind
permissions.

People are welcome to give this a spin, add more code/tests and write
tutorials. :)

Regards,

Martijn

_______________________________________________
Grok-dev mailing list
Grok-dev@...
http://mail.zope.org/mailman/listinfo/grok-dev

[wichert]

Previously Martijn Faassen wrote:

> Hi there,
>
> I just checked in a package called megrok.resourcelibrary. It wraps
> zc.resourcelibrary and all the real functionality is in that library,
> this just grokifies it. In essence megrok.resourcelibrary lets you set
> up your own new 'static' directories.
>
> What you can do with this is the following:
>
> import megrok.resourcelibrary
>
> class MyResources(megrok.resourcelibrary.ResourceLibrary):
>     megrok.resourcelibrary.directory('some_directory')

Isn't this something that could be setup using config.ini or a wsgi
middleware layer? It feels like using python to configure a deployment.

WIchert.

--
Wichert Akkerman <wichert@...>    It is simple to make things.
http://www.wiggy.net/                   It is hard to make things simple.
_______________________________________________
Grok-dev mailing list
Grok-dev@...
http://mail.zope.org/mailman/listinfo/grok-dev

[Martijn Faassen-2]

Wichert Akkerman wrote:

> Previously Martijn Faassen wrote:
>> Hi there,
>>
>> I just checked in a package called megrok.resourcelibrary. It wraps
>> zc.resourcelibrary and all the real functionality is in that library,
>> this just grokifies it. In essence megrok.resourcelibrary lets you set
>> up your own new 'static' directories.
>>
>> What you can do with this is the following:
>>
>> import megrok.resourcelibrary
>>
>> class MyResources(megrok.resourcelibrary.ResourceLibrary):
>>     megrok.resourcelibrary.directory('some_directory')
>  
> Isn't this something that could be setup using config.ini or a wsgi
> middleware layer? It feels like using python to configure a deployment.

I don't think so. A package may want to ship with resources. Imagine a
widget that needs a javascript file present. Or a package that
implements a layout that needs some images. Or a package that has some
kss files that expect to work together with Python code.

These resources are often intimately related with the code in the Python
package. It's also nice to be able to construct a virtual-host aware URL
for them.

Anyway, this is not new - 'static' in Grok works this way, and Zope 2
has been exposing resources for a long time as well.

Regards,

Martijn

_______________________________________________
Grok-dev mailing list
Grok-dev@...
http://mail.zope.org/mailman/listinfo/grok-dev

[Robert Gravina]

On 07/08/2008, at 8:22 AM, Martijn Faassen wrote:

> Wichert Akkerman wrote:
>> Previously Martijn Faassen wrote:
>> Isn't this something that could be setup using config.ini or a wsgi
>> middleware layer? It feels like using python to configure a  
>> deployment.
>
> I don't think so. A package may want to ship with resources. Imagine  
> a widget that needs a javascript file present. Or a package that  
> implements a layout that needs some images. Or a package that has  
> some kss files that expect to work together with Python code.
>
> These resources are often intimately related with the code in the  
> Python package. It's also nice to be able to construct a virtual-
> host aware URL for them.
>
> Anyway, this is not new - 'static' in Grok works this way, and Zope  
> 2 has been exposing resources for a long time as well.
>

I agree with Martjin here. Nevow (a Twisted web framework) has the  
concept of static resources as well, with an API similar to what I see  
here, and it works very well for me. Search for "static" in this  
documentation:
http://divmod.org/trac/browser/trunk/Nevow/doc/txt/nevow-traversal.txt

The last thing I would want to be doing is having to configure a WSGI  
middleware layer just to makes some images/css/js available in my site.

Robert
_______________________________________________
Grok-dev mailing list
Grok-dev@...
http://mail.zope.org/mailman/listinfo/grok-dev

[wichert]

Previously Martijn Faassen wrote:

> Wichert Akkerman wrote:
> >Previously Martijn Faassen wrote:
> >>Hi there,
> >>
> >>I just checked in a package called megrok.resourcelibrary. It wraps
> >>zc.resourcelibrary and all the real functionality is in that library,
> >>this just grokifies it. In essence megrok.resourcelibrary lets you set
> >>up your own new 'static' directories.
> >>
> >>What you can do with this is the following:
> >>
> >>import megrok.resourcelibrary
> >>
> >>class MyResources(megrok.resourcelibrary.ResourceLibrary):
> >>    megrok.resourcelibrary.directory('some_directory')
> >
> >Isn't this something that could be setup using config.ini or a wsgi
> >middleware layer? It feels like using python to configure a deployment.
>
> I don't think so. A package may want to ship with resources. Imagine a
> widget that needs a javascript file present. Or a package that
> implements a layout that needs some images. Or a package that has some
> kss files that expect to work together with Python code.
>
> These resources are often intimately related with the code in the Python
> package. It's also nice to be able to construct a virtual-host aware URL
> for them.

Pylons does the same thing, and may others probably as well. We are
seeing the exact same limitations everywhere: serving these static
resources through the application server is always a bottleneck when you
scale a site. In Zope much more so than elsewhere since Zope uses a very
low number of threads.

There are basically two things that you need: a way to construct a URL
to a resource and a way to conveniently serve those resources.
resourcelibrary does both, but I am advocating that it should be
possible to split them up. I want to be able to say 'my resources are at
http://static.mysite.com' and use apache to serve them without having
to rewrite all my templates.

Wichert.

--
Wichert Akkerman <wichert@...>    It is simple to make things.
http://www.wiggy.net/                   It is hard to make things simple.
_______________________________________________
Grok-dev mailing list
Grok-dev@...
http://mail.zope.org/mailman/listinfo/grok-dev

[Martijn Faassen-2]

Hey,

Wichert Akkerman wrote:
[snip]
> There are basically two things that you need: a way to construct a URL
> to a resource and a way to conveniently serve those resources.
> resourcelibrary does both, but I am advocating that it should be
> possible to split them up. I want to be able to say 'my resources are at
> http://static.mysite.com' and use apache to serve them without having
> to rewrite all my templates.

Sure, I agree that's a desirable feature.

Having an explicit concept of a resource library should be of use there.
I don't think Zope 3's resource infrastructure supplies for this
directly, but it should be possible to supply the system with an
alternative factory for DirectoryResource that knows about publishing
them using Apache. Resource objects are in control of creating URLs.

megrok.resourcelibrary doesn't supply for this directly yet. Alternative
factory support should be easy enough to add, but it'd be nice if there
were some higher level ability to make URLs go somewhere else. Note also
that in order to actually know which resources there are (if only to
generate URLs), the resource library *still* needs access to the files
in question, no matter how they are published.

If one does this, it would of course be interesting to be able to
specify where the real resource URLs are during deployment, perhaps in
zope.conf (which can be generated by buildout.cfg).

People are welcome to try adding in this support. The custom factory
support is already in zc.resourcelibrary, though I left it out of
megrok.resourcelibrary for now. It should be very easy to add it back.
Then it'd be a matter of creating a factory that takes looks for its
configuration information in zope.conf, looking for a section based on
the name of the resource library.

Regards,

Martijn

_______________________________________________
Grok-dev mailing list
Grok-dev@...
http://mail.zope.org/mailman/listinfo/grok-dev