Chris Withers wrote:
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 :-(
Well, the ZCML directives we currently have. If we had better and more
sensible directives, it might be much better.
It's sad that one of it's main selling points (the ability to "turn off"
configuration made in another package) was never implemented :-(
Not yet. We're getting there.
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?!
*sigh* I don't know who came up with the idea, and I don't really care
as I don't want to point fingers at anyone. The reasons are probably
historical...
Whatever happened to explicit is better than implicit et al?
Exactly.
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...
BrowserView and BrowserPage *are* really light. Look at them.
Note that you would get them mixed into your view component
automatically by ZCML anyways (at least when using browser:view /
browser:page).
--
http://worldcookery.com -- Professional Zope documentation and training
_______________________________________________
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
