On Tue, Apr 28, 2009 at 3:01 AM, Malthe Borch <mbo...@gmail.com> wrote:
> 2009/4/27 Chris McDonough <chr...@plope.com>:
> > Answering myself with the kind of navel-gazing which is sure to drive
> Tres
> > nuts ;-):
>
> Not answering anything, but this thread is as good a place as any:
>
> I think the issue of overriding default components is unnatural.
> Rather, I'd like to think of components in terms of availability,
> rather than pluggability. Concretely, the following is *pluggability*:
>
> >>> by_interface = {}
>
> Plug me once, you'll plug something out if you try it again.
>
> That's not what the ZCA is about; I think it's rather about
> availability, e.g. if I give you these N things, give me something
> that provides some formal functionality (described by an interface).
> The problem with this line of thought is that it breaks down when you
> abuse it to multiplex user interface elements; because here it's not
> about availability, it's about multiplexing.
>
> I think we should reconsider the way we decide on views and related
> components. Perhaps using a routes-like approach, e.g.
>
> <browser:page
> ...
> for=".interfaces.IHelpCenter .interfaces.IDocument"
> />
>
> (to target documents inside the help center section). Or whatever
> language/abstraction that can fit the bill. Note that to match this
> "for" clause, something more than a simple component lookup is
> required.
>
> I'm not sure that I see the need for that personally, but maybe it just
hasn't sunk in yet why I'd want to do that.
I did want to go ahead and bring up a completely different use case that is
very common in the wild but doesn't seem to be addressed in ZCA or this
generic formulation. Let's call it the Photoshop model, since hopefully
everyone knows what Photoshop plugins are. You have N number of plugins
that define a particular interface that are all registered but with no
preferential treatment in terms of look up--just a list of things you could
possibly use, with choice driven by the user.
>>> registry.look("img_processor")
[ <FuzzyCloudsPlugin ojbect at 0x00000000>, <SatanicRequestPlugin at
0x00000000>, <GreeneryPlugin at 0x00000000>, etc...]
or maybe a dict, more like:
>>> registry.look("img_processor")
{ 'Fuzzy Clouds': <FuzzyCloudsPlugin ojbect at 0x00000000>,
'Satanic Request': <SatanicRequestPlugin at 0x00000000>,
'Greenery Plugin': <GreeneryPlugin at 0x00000000>,
etc...
}
Now, I have no idea whether or not we actually care about this use case. An
application that uses plugins like this could easily define it's registry
and registration process. But, it had occurred to me, that if you're
throwing around the word plugin to people not already familiar with ZCA, a
lot of people are going to be thinking this model.
Chris
_______________________________________________
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev
