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 _______________________________________________ Zope3-users mailing list Zope3email@example.com http://mail.zope.org/mailman/listinfo/zope3-users