The names are unicode strings that are registered as factories and get called when getMultiAdapter is used.
@srichter followed up:
This is not a bug. It is simply a fact of the system. It was never intended that the default view names are to be looked up via a getMultiAdapter() call. This is also the reason, we provide a custom lookup function for default view names:
IMHO this breaks component architecture usability in a similar way as views which are adaptations to Interface.
It took me quite a while to find those getDefaultViewName functions because I looked at the registrations, find a multi-adapter registration and I immediately think 'sure, so lets adapt context and request to IDefaultViewName' and then a 10 minute long search for IDefaultViewName to figure out where the publisher itself uses this.
When someone sees an adapter being registered, I think its valid that he assumes he can retrieve it using get(Multi)Adapter.
@srichter:
But default views are not registered with a regular adapter directive. There is a special directive for a reason. The fact that the CA is reused for this case is an implementation detail.
@philikon:
Which is?
I think Theuni's assumptions where somewhat correct. While I agree that he tried to use IDefaultViewName incorrectly (after all, it suggests that it describes a view name rather than a view itself), I do wonder why couldn't there simply be an IDefaultBrowserPage interface that allows you to find a view w/o having to specify a name?
Moving this to zope.publisher, which is where IDefaultViewName and the ZCML directives are defined. This doesn't seem to be a problem with zope.component, merely the way zope.publisher is using it.
In https://bugs.launchpad.net/zope.component/+bug/260379, @icemac reported:
@srichter followed up:
@ctheune replied:
@srichter:
@philikon:
@ctheune: