On 4/28/09 3:01 AM, Malthe Borch 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.
When you do need it, the multiplexing is awful handy (e.g. when trying to look
up a view based on a context type and a request type).
> 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.
A fish doesnt know from wet, but I think if you were to want to go after some
dispatch like this, you might as well just use some URL dispatch thing like
Routes itself, because it ties the traversal path (at least in some abstract
sense) to a view. And once you do that, you might as well just use a regex
against the path itself to make it more flexible.
- C
_______________________________________________
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev
