On Tuesday 16 Apr 2002 10:25 pm, Casey Duncan wrote:
>However, you should know that the crux of this change is really to the
>publisher, the mixin is just the management piece.
Hmmm. Thanks for raising this. I wasnt aware that these browser_default
changes went so deep.
Im curious as to *why*
On Tue, 16 Apr 2002, Casey Duncan wrote:
> However, you should know that the crux of this change is really to the
> publisher, the mixin is just the management piece. *any* object can
> define a browser_default hook that overrides 'index_html', not just
> objectmanagers.
All the more reason to ma
Well I honestly hadn't considered that. So, I suppose changing to to a
mix-in inherited by folder is better.
However, you should know that the crux of this change is really to the
publisher, the mixin is just the management piece. *any* object can
define a browser_default hook that overrides '
On 4/16/02 8:53 AM, "Casey Duncan" <[EMAIL PROTECTED]> wrote:
> The implementation adds the API to manage browser default for all
> objectmanagers. However, no browser_default handler is actually added to
> the object unless you specify a default other than "index_html"
>
> What was the specific
On Tuesday 16 Apr 2002 3:53 pm, Casey Duncan wrote:
>What was the specific "undesirable effects" you were seeing?
1. The extra tab in the management interface.
2. That an ObjectManager-derived classes might have a default method which is
something other than index_html. (I havent digested this
The implementation adds the API to manage browser default for all
objectmanagers. However, no browser_default handler is actually added to
the object unless you specify a default other than "index_html"
What was the specific "undesirable effects" you were seeing?
If it is agreed that this mana