[Zope3-dev] Re: zcml questions

[Tres Seaver]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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 
>>> feature:
>> Why? So you can have yet another (pointless in this case) layer of 
>> indirection?!
> 
> *sigh*
> 
> 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.
- --
===================================================================
Tres Seaver          +1 202-558-7113          tseaver at palladion.com
Palladion Software   "Excellence by Design"    http://palladion.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFFEpBV+gerLs4ltQ4RAlldAJ9FwPgZV3NCE16wXiZGwpljrpZfswCeLwU5
PdZXr3WyOcBeEpcAzEe2QEg=
=XbgN
-----END PGP SIGNATURE-----