paulalexwilson at gmail.com
Sun Dec 14 17:18:30 EST 2008
Thanks for the lengthy and detailed response, you've given me some
good ideas, thanks.
2008/12/13 Kevin Teague <kevin at bud.ca>:
> 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..
> In order to make this work between Python projects, you need to use a
> DirectoryResource, which allows you to share static elements such as
> trunk and will be in Grok 1.0), I've pulled it into Grok 0.14 with:
> grokcore.view = 1.2 # DirectoryResource - to be included in next Grok
> And created a directoryresource in gum/layout.py:
> class Resources(grokcore.view.DirectoryResource):
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!
More information about the Grok-dev