Chris Withers wrote:
Philipp von Weitershausen wrote:
  Note: browser:view always creates new classes on the fly.


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


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?


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

-- -- Professional Zope documentation and training
Zope3-dev mailing list

Reply via email to