[Zope-dev] Re: [Zope3-dev] template 'usage' (was Zope 3 Newsletter 11)

[Jim Fulton]

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 at zope.com       Python Powered!
CTO                  (540) 361-1714            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org