[Grok-dev] Re: the projects in progress
faassen at startifact.com
Mon Feb 25 09:22:12 EST 2008
Martin Aspeli wrote:
> plone.salt doesn't exist yet, though - Wichert has a prototype under a
> different name, and I think others have played with this too (Whit,
> maybe?). I'm wondering if it makes sense to have the "salt"
> functionality as a part of the z3c.autoinclude package, since they are
> reasonably similar and may benefit from sharing some code.
I think it would fit very well in z3c.autoinclude. I think the
functionality fits well with the purpose of "auto inclusion", and as I
already mentioned, there's a lot of infrastructure that you should be
able to reuse.
>> With z3c.autoinclude-like functionality you could make this smaller
>> (note the name change :):
>> target = plone
> Does this functionality exist right nor, or are you saying we could
> extend z3c.autoinclude to do this?
Not at all, it's just a proposal. :) What I meant is that I was basing
the ideas on the experience we had designing and writing z3c.autoinclude.
>> This would then dig up meta.zcml and configure.zcml from the current
>> package. The only information necessary in the entry point is a
>> specification of what it actually claims to plug into. You might want
>> to consider making 'target' a dotted package name to actually give it
> Certainly looks nicer. ;-) I think having separate meta and configure
> tags is probably unnecessary in the majority of cases.
I think that in by far the majority of the cases automatically loading
both would be fine indeed.
I think should someone want control, they should go the original way:
include these things manually in an instance's site.zcml. How to allow
The only way I see is to have a way to here should be a way to turn
*off* inclusion of a particular plugin. I think the ZCML exclude
directive (which is available in an extension) could be used for this.
This use case bears some thinking about as it's a problem we don't have
for autoinclusion of dependencies. With plugins, the setup.py of the
plugin is stating it wants to be included after all, and just the act of
listing the package will make its ZCML be loaded by default.
> It probably also makes sense to allow an optional syntax where different
> *.zcml files are used as the starting point for different platforms. For
> example, a package that has optional Plone support may have a plone.zcml
> that's the starting point for Plone, a zope.zcml that's the starting
> point for plain-Zope, etc.
Yes, this sounds useful. You might be able to get by with a convention
that is driven by the directive though - i.e. the includePlugins
directive can be instructed to load other things instead of the default
configure.zcml and meta.zcml. This means that the package's setup.py do
not need to list any of these things explicitly. I think that having
such a convention makes for more easy to recognize structures in plugin
than if you let people come up with their own mapping (plone:
plone.zcml) in setup.py.
For Grok we have the (not-yet-implemented) 'tagging' idea that serves a
similar purpose - you mark particular components with tags using a
directive so that they can be explicitly included or excluded.
>> With a bit of cleverness you could then make the include statement
>> shorter too (note my putting this into the 'zope' ZCML namespace and
>> changing the name of the directive...):
>> <includePlugins target="plone" />
> Cool. I'm not sure whether it's kosher to use the 'zope' namespace for
> things that are not part of Zope 3, but this would of course be even nicer.
Yes, good point. We've done it with z3c.autoinclude already. "Part of
Zope 3" is becoming a somewhat diffuse concept anyway. :)
>> This sounds like nice functionality and we might cooperate on the
>> implementation of such a package. z3c.autoinclude probably already
>> includes much of what would be needed (including quite hairy test
>> infrastructure), and it might make sense to simply extend that
>> package's functionality with the new directive and entry point
> That makes sense to me too. Are people (who? You? Uli?) happy for us
> (who? me? wiggy? hannosch?) to do that (in a branch)?
Uli hasn't worked on this functionality yet. But I'd be happy to see
this being done on a branch, and I'd be happy to discuss the technical
details and review the changes too - just let me know when you need my
help. I'm sure Ethan and Robert who worked with me on this during the
snow sprint won't object either.
More information about the Grok-dev