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 > _______________________________________________ Zope3-dev mailing list Zope3email@example.com Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com