[Zope3-dev] Re: RFC: The browser:page compromise

[dev at projekt01.ch]

Hi Philipp

> > See also my (a little old) proposal at:
> > 
> http://www.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/Simpl
> > ifyMacroRegistration
> > 
> > Note: the proposal is a little bit old and I whould change the 
> > directive browser:macros and make explicit use of a python factory 
> > rather then use a implicit mixin class.
> > 
> > What do you think Philipp? 
> 
> This isn't part of the discussion about this proposal.
> 
> Just to be clear:
> 
> * Having to register macros as pages when they're not meant 
> to be publishable sucks.
> 
> * @@standard_macros sucks a bit too (too much indirection). 
> It sure confuses people (like Tonico, as he says himself).
> 
> * I'd rather not invent a new ZCML directive nor a new TALES 
> expression type (I don't like this about viewlets and 
> contentproviders).
> 
> I could imagine a new traversal namespace:
>   <metal:macro use-macro="context/++macro++page" />
> 
> Here, 'page' is an adapter from (context, request) (it's a 
> view) to IMacro or something. It will also be registered as 
> such (as a <view /> or just an <adapter />).
> 
> I think viewlets and contentproviders should have taken the 
> same road and used traversal namespaces. That's what they're for :).

I don't think so.
ITALESExpression are built for this use case.

My context doesn't need to have a ++macro++ namespace!
My context doesn't know about macros and viewlets. Macros or viewlets
depend on context and request. This is the reason why we implemented a 
lookup via tales expression and not a traversal namespace on our context.

> If we shall discuss this any further, I suggest we move into 
> a separate thread.

Yup

> Philipp
>