[Zope3-dev] wading through zcml...

[Chris Withers]

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