-----BEGIN PGP SIGNED MESSAGE-----
Philipp von Weitershausen wrote:
> Chris Withers wrote:
>> Philipp von Weitershausen wrote:
>>> AFAIK, getUtilitiesFor is not supposed to order these in any way.
>>> While the returned iterator does find them in a reproduceable order
>>> due to the implementation, you shouldn't rely on that.
>> OK, so you should always sort this list when using it for a UI?
> If you explicitly want the list to be sorted, sure. The question is how
> you want it to be sorted. Perhaps not everyone wants it to be sorted by
> the utility name.
> Also, getUtilitiesFor is a generator. That makes it efficient if you
> just get a few utilities, realize you have the one you want and don't
> get the rest. If you expect a sorted output, you lose that efficiency.
>> Hmm, seems odd, is getUtilitiesFor used for anything other than
>> generating UI's?
> I can't say off of the top of my head. Why don't you grep :)
>>>> Also, if a site administrator wanted to "unregister" one of these in
>>>> site.zcml, maybe because they didn't want the Traverse executor to be
>>>> available, how would they go about doing that?
>>> ZCML has no way of unregistering specific utilities or adapters
>>> (though there's a Python API).
>> That sucks :-(
>> I thought the whole point of ZCML was that a site manager could override
>> setup in site.zcml. 50% of that aim isn't done if they can't turn stuff
>> off as well as on...
> Right. I think zcml:condition was a first step into that direction. Its
> implementation was very use case-driven. It seems you have a use case
> for more control over ZCML, so it'd be nice to hear from suggestions how
> you would envision a directive disabling feature in ZCML.
>> Where can the python api for unregistration be found?
> On site managers. They have unregister* methods. So, *after* your ZCML
> has been loaded, you could poke at the global site manager and
> unregister the utilities that ZCML registered.
>>> In ZCML we typically define "features" and apply a condition using the
>> Why? So you can have yet another (pointless in this case) layer of
> We use it quite well in Zope 3 to enable/disable development tools like
> APIDoc. We have a feature called 'devmode' so all debugging tools can
> hook into that. APIDoc itself also enables a feature when it is loaded
> so you can register things with APIDoc, but only if APIDoc is available.
> zcml:condition also has another verb, "installed", that allows you to
> load directives only when a certian Python package is available, e.g.:
> <include zcml:condition="installed reportlab"
> package="worldcookery.pdf" />
>>> <meta:provides feature="twidder.defaulttraverser" />
>>> <utility ...
>>> zcml:condition="have twiddler.defaulttraverser" />
>> This is missing the point. There are an array of inputs, outputs and
>> traversers available. There's a sensible default set registered, but
>> site managers might have different requirements which are likely to
>> include disabling some of the default registrations.
> Why woudl they have to disable existing ones? Can't they just choose
> different ones, leaving the default ones sitting there?
>> How should I do things such that they can do that?
> I'm just wondering whether you really need the disabling feature.
I've wanted it. My major beef with the way we are *using* ZCML now is
that we expect package authors to provide policy-laden configuration for
their packages ("sensible defaults") but provide no means for the admin
to reuse that configuration selectively; their only realy choice is to
*copy* the configuration and edit it.
I argued *long* ago (after the first ZC-internal Zope3 sprint, I think)
that the '<include>' directive should be allowed to be complex, with
subelements like '<except>' or '<only>' to pull in specific directives.
Such a practice would require either that we have XPath support
available, or else that we come up with a way to mark the directives
(e.g., a 'zcml:id' attribute). It would *also* require that we
implement the "no side-effects during parsing" policy (my other favorite
"dead horse" in arguments about ZCML's implementation / usage).
Tres Seaver +1 202-558-7113 [EMAIL PROTECTED]
Palladion Software "Excellence by Design" http://palladion.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v126.96.36.199 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----
Zope3-dev mailing list