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 :-(

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


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



Simplistix - Content Management, Zope & Python Consulting

Zope3-dev mailing list

Reply via email to