[Zope3-dev] separation of view hierarchy

[Paul Everitt]

On jeudi, d=E9c 12, 2002, at 12:19 Europe/Paris, Martijn Faassen wrote:

> Paul Everitt wrote:
>>
>> On mercredi, d?c 11, 2002, at 15:50 Europe/Paris, Guido van Rossum
>> wrote:
>>>
>>> I've been thinking about this, and I'm not sure.  I find it hard to
>>> navigate existing code that creates views, which I was trying to use
>>> as examples.  One problem is that the information that shows how it
>>> all fits together are spread over three different file types (in the
>>> general case): there's a .py file providing view-specific logic, a
>>> .pt file providing the page template that invokes the view-specific
>>> logic (and sometimes also non-view-specific logic) and the .zcml =
that
>>> ties it all together.  Then there additional layers of indirection:
>>> multiple zcml files (one for the content object, and one for browser
>>> views), ZPT macros, generic views (e.g. the "Add" view logic is in a
>>> shared place) and you get the picture.
>>
>> [snip]
>>
>> This was the reaction I had as well when trying to write some Zopetop
>> documentation.  I verified that other Rotterdam people had the same
>> experience, as everyone relied on grep to resolve all questions.
>
> We've been discussing 'through the web' views in this context just =
now.

Ugh, wish I was there.  I think this piece will be really helpful in a=20=

number of ways.  Not the least of which is that it will open up the=20
doors for people to tackle the usability/complexity problem in new ways.

> We're considering a special package where you can add page templates

Hmm, neat idea.  Really neat.  There's a lot that can be done this way=20=

and it likely reduces the number of knobs that would confront people.

(Minor note, though: you'll want some other types besides page=20
templates -- images, css files, js files, etc.)

> and page templates only (uploading them using FTP or WebDAV or=20
> filesystem
> sync). The package is configured to work with an interface and may be

By "configured" you mean "pre-configured", and thus people won't be=20
confronted with that complexity, right?

> associated with a view class/factory. There can then be a browse user
> interface where you can get information from the interface and also
> all methods defined on the view.

If this information is introspectible via the web, then lots can happen.

> This is again with an eye on the view developer who isn't writing=20
> python,
> though.
>
> While it won't give all the information needed, it should likely help.
> More suggestions in this department are welcome. It's a (view)=20
> developer
> user interface issue. :)

I'm particularly interested in the discoverability issue.  For=20
instance, let's say Jill Sitedesigner is looking at a page in a site=20
she's co-developing with her teammates.  She wants to know what=20
produces a certain box on the page, and the box was created by someone=20=

else.  How does she find out where the box comes from?  (Don't say,=20
down the hall and to the right.) :^)

Another: she's sitting in front of a blank page, getting started on a=20
new view/template/page/whatever.  Let's say she's adding a guestbook=20
form, to later be hooked up to the object system by Joe Sitedeveloper.

Jill knows there are a bunch of macros she can reuse in her page.  Or=20
at least she's been told.  How does she find these macros?  (Don't say=20=

grep.) :^)

--Paul=