[Grok-dev] Re: Salt & z3c.autoinclude

Martin Aspeli optilude at gmx.net
Sat Mar 22 19:32:40 EDT 2008


Hi Martijn,

>>> If I end up having a second zope platform which wants to use it (which 
>>> currently looks unlikely, and which I can't really imagine ever 
>>> needing anyway) I would need to be able to register the package as a 
>>> plugin for multiple platforms, each with a different starting point 
>>> for its ZCML.
>> Actually, I think this is kind of important. What if I write a package 
>> that can work both with Grok and Plone?
> 
> A *plugin* that plugs into Grok and Plone? Could you give an example of 
> such a thing? I have a very hard time imagining what that could be.

Perhaps I'm inventing use cases that don't exist. It's more a gut feel 
that limiting ourselves to exactly one "target" forever may be something 
that we come to regret.

Basically, the superficial goal as far as Plone is concerned is to get 
rid of ZCML slugs. When you install a third party product, having to add 
a slug or an include in your own package (if you have one - 
non-programmers using Plone don't) is just lame. :) Some plugins may not 
be Plone-specific or may have some specific Plone support but be 
applicable to Zope (2 or 3) or CMF or Grok or whatever in general.

> [snip]
>  > I can certainly see situations where you have
>  > an auto-includable package that works with Plone and Grok, but where the
>  > configuration is slightly different for each.
> 
> Loading up dependencies we already have covered with the autoinclude 
> directive.

I didn't mean that. I meant a situation where a package works in plain 
Zope 2, say, but has an optional view or module that's mostly useful in 
Plone. The ZCML configuration may need to be adjusted slightly for the 
two different targets.

> We need to distinguish auto-inclusion from loading up plugins. 
> Auto-inclusion means automatically also loading the ZCML of that 
> dependency. A dependency like that could be used by Plone or Grok; 
> that's not a problem. The dependency relationship is the other way round 
> in that case though.

Agreed.

> [snip]
>  > Then again, this may be YAGNI. It seems that we shouldn't restrict the
>  > format so that it becomes impossible to support this, though. :-/
> 
> I think we should indeed say YAGNI for a while and see how this works 
> out for Plone. When real-world problems come up, we will come back and 
> talk about adding behaviors.

So long as we don't design the syntax or framework so that it's 
impossible to cleanly support multiple targets in the future, I'm happy 
with that stance.

Martin

-- 
Author of `Professional Plone Development`, a book for developers who
want to work with Plone. See http://martinaspeli.net/plone-book



More information about the Grok-dev mailing list