[Zope-CMF] Re: Method Aliases

[Yuppie]

Hi!


Shane Hathaway wrote:
> On Tue, 30 Sep 2003, Yuppie wrote:
>>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.

I know. Accidently I tested it with 4 levels (including portal root). 
Cumulative means *all* traversal steps needed to publish a document 
compared to the one _getViewFor call.

> 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.

I tested with a new CMFDefault site, debug mode off.

>>>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.

Your example was a dispatcher for 'edit', so I was confused. Why 
shouldn't it be possible to override method names for publishing traversal?

> 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.

Sure this can't be implemented as efficiently as in Zope 3. But compared 
to all the other inefficient code in Zope 2 and CMF I couldn't measure a 
high cost in speed.

Understandability is something different. Why do you think the current 
implementation is hard to understand? I think it's much simpler than 
what __call__ and view do right now.


Cheers,
Yuppie