[Zope3-dev] Template usage

[Joachim Werner]

> We agree with the rationale behind having a way to separate the two page 
> types, but we don't think it should be done by having two separate 
> templates. The main template can easily be reused for this, the only 
> thing needed is a way to decide whether a page is a view or falls into a 
> different category (for example a dialog page or maybe a wizard page for 
> novice and setup interfaces later on).

+1

> Actually hiding too much of the interface confuses the user more than 
> helping, since you in a way "pull out the rug" under him by removing 
> things he normally relies on, like the navigation box or similar items. 
> Removing non-applicable items is ok, but most of the other elements 
> should be kept where they usually are. So in the case of dialogs, we 
> will be hiding the view tabs and the action bar, while keeping 
> navigation and personalized elements.

Good idea in general. But we should keep rendering performance in mind. 
One thing that makes the current ZMI so usable is that every management 
screen renders very quickly (except for very large object listings or so 
of course). That works because the right "manage_main" frame only needs 
very little context. It just calls a single method.

If you always display the navigation and basic button bars, personal 
toolbars etc. on every screen (and not use frames for it), you will end 
up with a lot of computing. I see two working solutions for that:

a) do not actually reload the page, but just the parts that change (like 
the tree navigation does now); this is basically the approach a real 
("thick") client app would use. This is quite clever and needs the least 
traffic. Also, state has not necessarily to be kept on the server, as 
the actual management screen is somewhat stateful. But it needs a good 
browser-side JavaScript implementation.

b) heavy server-side caching of the management sessions, so all slots 
that don't change can just be filled from the cache. This is not as 
efficient in terms of minimizing page sizes (think modem connections), 
but it will work with very old browsers and is probably a bit less 
error-prone and more simple to do.

The third option is building more autonomous clients (e.g. with XUL), 
but that's off topic right now.

Remark: We don't need to have the performance optimizations in place 
right now, but the architecture should be fit for being optimized in the 
beta phase of Zope3 ...

Cheers

Joachim