Philipp von Weitershausen wrote:
browser:view
Note: browser:view always creates new classes on the fly.
evil
browser:page
Registers an adapter where the second adapted object defaults to
IBrowserDefaltLayer. Always creates a new class on the fly and
mixes in functionality that makes the adapter a *publishable view*.
evil.
I'm sick of ZCML and its magic and its inconsistency. The typing and the
pointy brackets I could live with... ME GROK SMASH ZCML.
Yeah, ZCML is the new acquisition :-(
It's sad that one of it's main selling points (the ability to "turn off"
configuration made in another package) was never implemented :-(
That said, I can live with most of the crap, but these dynamically
generated classes... wtf? why? why did that? why are they still breathing?!
Whatever happened to explicit is better than implicit et al?
I'm trying to register an adapter in such a way that I can do the
following in a page template:
<p tal:content="structure someobj/@@render"/>
Which of the myriad flavours of view registration should I be using?
Inherit from BrowserView
Everyone says this, but why is it a good idea? I want these things to be
_really_ light, they're going to be used a lot in every page render...
and use either a simple <adapter /> or a <view
/> or a <browser:view /> directive to register it. Note that this thing
won't be publishable via the URL then (which is probably what you want).
Correct.
Also, why, when zope:view is described as a synonym for zope:adapter,
does zope:view support an allowed_attributes attribute, while
zope:adapter does not?
zope:adapter assumes the "provides" interface as the "allowed_interface".
*sigh*
Chris
--
Simplistix - Content Management, Zope & Python Consulting
- http://www.simplistix.co.uk
_______________________________________________
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
