[Grok-dev] Bonked

Paul Wilson paulalexwilson at gmail.com
Sun Dec 14 17:18:30 EST 2008

Hi Kevin,

Thanks for the lengthy and detailed response, you've given me some
good ideas, thanks.

2008/12/13 Kevin Teague <kevin at bud.ca>:
> Goal:
> Allow add-ons to be managed as seperate Python projects, packagable as eggs,
> etc. When an add-on package is grokked, then the application presents a UI
> for installing/uninstalling that add-on.

My requirements are very similar..

> [SNIP]
> In order to make this work between Python projects, you need to use a
> DirectoryResource, which allows you to share static elements such as
> JavaScript, images and CSS. This was added to grokcore.view 1.2 (which is in
> trunk and will be in Grok 1.0), I've pulled it into Grok 0.14 with:
> [versions]
> grokcore.view = 1.2 # DirectoryResource - to be included in next Grok
> release
> And created a directoryresource in gum/layout.py:
> class Resources(grokcore.view.DirectoryResource):
>    grokcore.view.name('resources')
>    grokcore.view.path('resources')

I was wondering about how I was going to pull this one off, thanks for
bringing DirectoryResource to my attention.

> So that's pretty much how I approached the add-on problem. The key being
> that the main application has an IExtensionMaker and IExtension interfaces,
> and each add-on then implements these interfaces as global utilities. Then I
> query the component architecture to see what's being registered via grokking
> and build the UI based on that.

Makes sense to me. I've checked out your project so I can have a
general poke around! Do you have an example of an add-on too?

> Again, I can't promise that I've got the cleanest or most robust solution,
> but I did write something that worked for me :)

For someone who's just getting to grips with things, it's a good start
for me. I can tune it to my specific needs later!

Thanks again,

More information about the Grok-dev mailing list