Martin Aspeli wrote:
Chris Withers wrote:
What's the difference between zope:view, browser:view, browser:page and
browser:viewlet?
I would strongly encourage you to buy Philipp's book when the second edition
comes out, and read some of the available existing documents (e.g.
worldcookery.com, the Zope 3 wiki thingie).
I'm a strong reader of Philipp's book(s) but they don't go into enough
detail here...
<zope:view /> is deprecated, I believe, an old spelling for <adapter />
before <adapter /> could do multi-adapters.
See my previous complaint, they have totally different signatures, I
don't see how one can be deprecated in favour of the other.
<browser:view /> is about registering a new view, typically one that doesn't
render a page (so think of it analogous to where you may use a Script
(Python) in Zope 2)
What's the difference between a page and not a page in your mind?
<browser:page /> is about a view typically with an associated template that
renders something for the user
Then why is the macros view in the following example registered as a page:
http://wiki.zope.org/zope3/SimplifyMacroRegistration
?
<browser:viewlet /> is about building viewlets, which are small chunks of
HTML that are aggregated into a <browser:viewletManager />. The DocTest in
zope.viewlet explains it all.
Sounds like this is worth a look...
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"/>
You would use a browser:view with a class deriving from BrowserView
(Products.Five.browser.BrowserView)
Why do I need to subclass BrowserView? I looked through the code and
can't really see what this adds...
As I've said before, I don't care about the request, and really don't
like the magic appearance of both the request and context attributes.
That said, looking at the actual object I appear to get as the view, I'm
deeply scared to see so much magic going on (wtf is a
Products.Five.metaclass?!)
and did its magic in the __call__ method
i believe. A more common pattern would be to have a method on the view
"render" that you call:
tal:define="renderView someobj/@@render"
tal:content="structure renderView/renderTheData"
This all feels way to heavyweight. My IRender has exactly one method,
and a lot of objects will be getting rendered on each page...
Chris
--
Simplistix - Content Management, Zope & Python Consulting
- http://www.simplistix.co.uk
_______________________________________________
Zope3-dev mailing list
[email protected]
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
