[Zope-CMF] Re: Method Aliases

[Shane Hathaway]

On Tue, 30 Sep 2003, Yuppie wrote:

> Hi!
> 
> 
> Shane Hathaway wrote:
> > In more ways than one!  Never use "is" with strings.  Here is one way it 
> > fails:
> > 
> >  >>> str(u'a') is 'a'
> > False
> 
> I see. Fixed.
> 
> > Also, I think that while method aliases are a good idea, implementing 
> > them with a traversal hack is a bad idea.  It will kill whatever 
> > performance we have left after all the other hacks we've done.  It's 
> > shoehorning too much into Zope 2.
> 
> Before implementing it this way a did some profiling using the 
> ZopeProfiler product. Maybe I did it wrong, but these were my results:
> 
> cumulative CPU cost:
> 
>    __before_publishing_traverse__  between 1 and 2 percents
> 
>    _getViewFor (used by __call__ and view) about 1 percent
> 
> if you use Method Aliases to bypass __call__() and view(), the overall 
> cost is about 1 percent performance loss.
> 
> That's not for free, but I can't see why this should be a performance 
> killer.

It's a problem because *everything* in CMF inherits from DynamicType.  If 
you traverse 4 levels deep under a portal, you'll hit the before_traverse 
hook four times.

Also, you didn't say what you're comparing with.  If you're saying that 
the new hook accounts for 1% of Plone rendering time, that could translate 
to a much greater portion of the rendering time on a faster CMF site.

> > The more interesting thing to do is to make something acquired from the 
> > root of the portal that dispatches to skin methods based on the type of 
> > the context.  For example, if we want an "edit" method alias, we might 
> > create a skin method called "edit" that dispatches to "document_edit" if 
> > it's applied to a document, "news_edit" for news, etc.  We could 
> > continue to use the existing machinery for setting up aliases, but we 
> > wouldn't use a traversal hook.
> 
> I'm not sure what you propose: All content objects have 'view', 'edit' 
> and a default method. How would you override them using acquisition?

That's another thing wrong with this.  I don't think it should be possible
to override methods using method aliases.  What I'm suggesting is to use
method names that are not overridden.

The vision is good, but Zope 2 can't support many traversal hooks without
a high cost in understandability and speed.  Take a look at Zope 3
instead.  Zope 3 completes the vision with not just skins, but view
components, rather than a big pile of methods.  Please check it out.

Shane