[Grok-dev] Re: Salt & z3c.autoinclude
faassen at startifact.com
Sat Mar 22 18:56:32 EDT 2008
Martin Aspeli wrote:
> Ethan Jucovy wrote:
>> 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.
I think we should define a plugin as something that uses APIs in the
core to plug into it. It will for instance implement an interface
defined in the core, and register itself as a utility, or will adapt
something in the core, or be a view for it. The relationship between the
plugin and the core could be limited to something only expressed in ZCML
as Ethan mentioned, but usually there will be a code relationship as
> 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
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.
> 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.
More information about the Grok-dev