[Zope3-Users] Confused re Fine Distinction btw a View and a Page

[Stephan Richter]

On Wednesday 07 December 2005 07:01, Jeff Rush wrote:
> I'm trying to understand how a sequence of pages is handled, as one
> example the IAdding (+) view.
>
> I'm running into the TAL use of the terminology:
>
>      @@standard_macros/page
> versus
>      @@standard_macros/view
>
> Both of those have much of the Zope interface look, just that /page
> drops the tabbar (I wish there were an easy way to drop the tree and
> login name from /page too).

To understand this properly, look at zope.app.basicskin.standardmacros. You 
can see that "view" and "page" are both really the "page" macro. However, ZPT 
stores the actual macro name in a variable "macroname". You can then say, 
okay, if the macro "page" was requested, then I do not want to show the 
available views, context menus, etc. The usage of this feature can be seen in 
zope.app.rotterdam/template.pt

>
> But then in CMF, seemingly using view/page to mean something else, I have:
>
>      browser:pages
> versus
>      browser:view
>
> And in the source, we have:
>
>    "Named View w/o Pages"
>
>    "Unnamed View w/Pages"
>
>    "Named View w/Pages"

First of all, I think you meant to s/CMF/ZCML. Next, ZCML has **nothing** to 
do with TAL. In ZCML, "browser:page" and "browser:view" are ways to register 
new browser views. I agree that their existence is convoluted, as 
browser:pages duplicates a lot of the browser:view use cases. If you use 
browser:view, with pages, then you can do the following traversal:

context/view1/page1.html
context/view2/page2.html

If you use browser:pages, then you can only do:

context/page1.html
cotnext/page2.html

> Obviously a page and a view are not the same thing, but something
> hierarchical.  But is such a page still a "view component" or some
> appendage of a view?
>
> For adding items:
>     +/index.html
>     +/action.html
>
> Those are two real browser-pages, one for displaying the form to be
> filled in, and one for accepting that form and actually creating the
> item.  And some benefit or sharing of data occurs by making those pages
> 'subviews' of the '+' view but I'm not sure what that benefit is, other
> than sharing a few ZCML directives.

Well, we do not clutter the container namespace. Consider this. Let's take 
your suggestion and let's implement, adding-index.html and 
adding-action.html. The you could use:

container/@@adding-index.html
container/@@adding-action.html

There are two disadvantages:

(a) You always have to use "@@", since the container could have objects called 
adding-*.html.

(b) You have to use more English and it is not as obvious that those two views 
belong together.

> And last, in such a sequence of pages, there must be a way to control
> the final destination or page displayed after creating that instance.
> One Zope 3 book mentions providing a nextURL() method on the view, but
> in the case of '+' that would require subclassing.  Is there a less
> intrusive way?

Subclassing is fine in this case. You could write your own IAdding 
implementation that looks up an adapter for the nextURL call, but I think 
that would be an overkill.

Regards,
Stephan
-- 
Stephan Richter
CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student)
Web2k - Web Software Design, Development and Training