One of the epiphanies Tres came up with during a bout of drinking is that the
#1
navel-gaze below (the unittest indirection one) doesn't need a ZCML
registration
(or any "real" component registrations at all except in the unit test).
Instead, to do unit testing indirection, say for a test like so:
def test_it(self):
from something import view
context = DummyContext()
request = DummyRequest()
result = view(context, request)
def factory(context, request):
return DummyImplementation()
provideAdapter(factory, (None, None), ISomeUnitTestIndirection)
self.assertEqual(result.status, '200 OK')
Where the 'from something import view' might resolve to:
def view(context, request):
impl = queryMultiAdapter((context, request), ISomeUnitTestIndirection)
if impl is None:
impl = TheRealImplementation(context, request)
return Response(impl.render())
This is as opposed to doing:
def view(context, request):
impl = getMultiAdapter((context, request), ISomeUnitTestIndirection)
In the second view variant, the unit test indirection would need to be
registered in ZCML or elsewhere. In the first one, it needn't be, except
within
the unit test itself. The main benefit of this is that registrations made only
to service unit tests don't need to pollute ZCML.
- C
On 4/27/09 2:56 PM, Chris McDonough wrote:
> On 4/27/09 1:18 PM, Chris McDonough wrote:
>>> I find the introduction lacking; why do I care about indirection,
>>> what's the benefit.
>> Good point.
>>
>> Um. Why *do* we care about indirection? In particular, why do we care about
>> this sort of generic-function-ish dispatch pattern we call adaptation? Why
>> do
>> we care about it for *every* application? I'm too brainwashed to answer that
>> question without thinking about views. If we want something to be bit off by
>> the larger Python community, we need an answer for this.
>
> Answering myself with the kind of navel-gazing which is sure to drive Tres
> nuts ;-):
>
> - We use the heck out of indirections during unit testing. In most
> of the apps I write personally, the ZCA indirections are the only thing
> that make it *possible* to write unit tests rather than needing
> to write functional tests. But typically during testing the idea that
> some *adapter* is registered against more than one "requires" interface is
> just something that we deal with rather something that is actively
> desirable (because we always only have one implementation during
> unit testing); the actual multidispatch is to support the below
> case.
>
> - We use adaptation and utility indirections in applications to allow
> people to override implementations without needing to change the code.
> Most non-Zope people associate this desire to provide pluggability,
> correctly or incorrectly, with "CMS" systems. But there's something
> to this conclusion because indeed the ZCA indirections were originally
> meant to replace use of something like acquisition to find values in
> "content space". I suspect we are quite brainwashed here, or at
> least incapable of discounting this use case, because we tend to
> treat every application as something that might turn into a framework.
>
> - We use utility indirections (or at least I do) to retrieve
> application-specific configuration values (e.g. BFG's ISettings
> utility, which offers no behavior except as a bag-of-names).
>
> I have some ideas about how you might layer several systems together to allow
> people to only bite off one bit of software for each of these cases. #2 is
> the
> most problematic and would be at a higher layer.
>
> - C
>
> _______________________________________________
> Repoze-dev mailing list
> Repoze-dev@lists.repoze.org
> http://lists.repoze.org/listinfo/repoze-dev
>
_______________________________________________
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev
