Garrett Smith wrote:

I'm trying to get my head around the template 'usage' attribute -- I know it should be simple, but the 'ah ha' hasn't hit me yet.

It seems to me that 'usage' is just an abitrary way to configure a view with a particular piece of information in ZCML.

No. Usage has a for more specific purpose. Unfortunately, it's scope has expanded beyond it's fairly basic purpose. The usage variable was defined to solve a particular problem. We are used to thyinking about a standard look and feel for pages. The standard "page" macro is used to implement this standard look and feel. Unfortunately, there are a number of different kinds of pages. For example, some pages are like dialogs. For such pages, it doesn't make sense do display some page elements. We had created two page macros, "page" and "dialog". These macros were very similar and had overlapping contents. The folks working on these macros wanted to have a single macro and a variable to be used by the macro to disable some page elements depending on how the page was being used. So far so good. There is a notion that the page usage might be a configuration option. The thought is that the same template might be used for both "view" pages and "dialog" pages. I think that this is rather questionable. When someone designes a page, they probably know, or should know, how it is going to be used. To take things further, it was thought that all of the pages referenced by a manu should have the same usage and that the usage for a template should be *implied* by the menu that contains the menu item that references the page used by the template. I understand the motivation for this, but it is really problematic, for two reasons: 1. It is very implicit (automatic;) 2. The menu system just wasn't designed to support this sort of thing. The menu system is really only responsible for navigation. It is not responsible for implementation of referenced pages. Trying to do so adds lots of unwarrented complexity to the menu system.

This seems very useful, but why limit it to a single value among a predefined set?

Nah.

I can imagine a host a number of view-related (or whatever-related) attributes being set via ZCML. E.g.

- a view/form caption

This already exists for forms.

- whether or not a page section is visible

In general, YAGNI. For forms, you can control which fields are included.

- a URL to redirect to after an action has occurred

I'd like to borrow some variation on this from the evolving form-navigation ideas developed for Plone. All of these parameter ideas are pretty specific. They are not well served by a general mechanism.

Short of requiring developers to create their own ZCML directives, could

I'd rather have developers create their own ZCML directives. A generic mechanism will be too error prone or encourage folks to put too much ligic in their zpt.

we not handle these cases using an 'attributes' attribute, ala TALES? E.g. in the case of usage now, an 'attributes' tag would look like this:

<view name="foo" class="Foo" permission="zope.View" attributes="usage objectview" />

I realize might be viewed as an erosion of well defined ZCML directives, but it looks to me this is what 'usage' is doing anyway. I think an 'attributes' attribute would be far more useful.

I'm increasingly of the opinion that usage should be set in zpt, as it is, ultimately, an implementation decision. Jim -- Jim Fulton mailto:jim@zope.com Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org