thanks for your feedback.
> I like many parts of it. I didn't like the fact that the zcml ended
> up being longer.
Me neither :(.
> I didn't love that people had to start asking
> questions about interface types in order to register a skin.
> Interface types are a cost--another layer of abstraction, another
> potentially mind-blowing thing to explain.
Perhaps, perhaps not. I think the interface ZCML directive would be easy to
understand by itself ("Aha, so we register an interface. And we give it a
type, like, what kind of interface it is."), but I'm totally biased.
> You are already suggesting changing the zcml, and I'd like to see a
> compromise between the brevity of the current zcml and the conceptual
> clarity of your proposed changes.
> I tried to brainstorm, but didn't love what I came up with. Maybe it
> can take us somewhere. What if we still deprecated browser:layer but
> kept a redefined version of browser:skin? Then your zcml--
> could become
> <browser:skin component=".interfaces.ShanghaiSkin"
> name="ShanghaiSkin" />
> The rest of your example would remain the same.
As you can imagine I'm a bit hesitant about having too many specialized ZCML
directives like browser:skin. But I definitely see your point. I have the
following compromise to suggest. The 'interface' directive is used for two
* Registering an interface as a utility. For that it will use the dotted name
of the interface.
* Optionally putting a type on an interface.
My suggestion is to add an optional 'name' parameter to it so that the
interface won't necessarily have to registere using its dotted name. Then we
can merge the 'interface' directive and the 'utility' directive from above
into one. It will basically have the same affect as your suggested
browser:skin directive and is only longer by the 'type' argument.
Other usecases I see for the extra 'name' argument: Content Types. For example:
So, this would be a very generic way of giving interfaces a type and name.
Generic means that it'd be used throughout Zope extensions and would therefore
provide a lot of consistency.
> It doesn't accomplish everything you set out to do, and that's a
> shame, but it feels like a compromise with a reasonable counter-
> argument: defining skins is a basic task often introduced early on
> with teaching Zope, and it's a shame to have to bloat the zcml and
> teach advanced topics too soon.
> I'd like to at least get the <interface...> zcml out of this story.
I know my compromise does everything except that :). I think it's still better
to keep consistency in the ZCML directives than having nicely sounding
directives whose way of working isn't really explained just by their names.
This message was sent using IMP, the Internet Messaging Program.
Zope3-dev mailing list