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*
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
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
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
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 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 make
