[Zope3-dev] Menu issues

[Stephan Richter]

On Wednesday 02 March 2005 04:25, Roger Ineichen wrote:
> > as you have seem probably, I have been working on a menu demo
> > today. Update
> > your Zope 3, then go to http://localhost:8080/%40%40menudemo.html
>
> First, thanks for your great work.

No problem. However, I note that it is up to you (plural you, as in the Zope 3 
community)


> > While I was doing that it occurred to me that our
> > implementation of menus has
> > some problems. For example, it might be desirable at times to
> > have a sub-menu
> > that lists all recently opened files. Currently there is no
> > way ti implement
> > that, since we do not have the concept of a menu, but only a
> > menu item, which
> > are fairly static.
>
> I'm still working out a way where we can build menus with submenus.
> I think there is no other way then using javascripts;-(
> Yes the gecko engine can do it without JS, but ie ...

I think it should do pure CSS when it can and fall back to JS, if  a browser 
cannot do it; the only one I am aware of is IE. The special CSS feature 
needed is the ">" selector.

> I think your implementation is going in the right direction
> if you using nested lists. This is today the best concept
> for supporting future accessiblity requierments.

This is what all the examples online used.

> > Thus, I propose to implement a menu adapter that mainly does the work
> > "getMenu" is currently doing. By default the implementation
> > of a menu will be
> > very simple. But one can optionally specify a menu class that
> > does very
> > different things to generate menu items. This would allow us
> > to implement the
> > "Open Recently" use case.
>
> I think, using adapters will be staight forward for this.

Yes, they are.

> Perhaps we can a also support a menu view where is using a
> layout template. If so we could call this view and get a
> rendered menu component. This whould be cleaner then do it
> all the time in a master template and would make it reusable.
> (like the navigation tree in Rotterdam)

Menus will be already views, but you could write a view on a view of course. 
In general; this is a level I am not interested in. There is a lot of 
oppurtunity for UI people here.

> > Another advantage is that we can then store some sort of
> > state on the menu;
>
> On the menu item in the registry?

No, the important fact is that we store info on the menu not the item.

> This info is session or  principal related? right?

Some info could be others is not. It depends on the implementation of your 
menu.

> I mean if a menu is collapsed 
> or expanded is up to what a user klicked.

But this is UI, this has nothing to do with the underlying logic.

> Or you mean somthing like the default state of a menu item for a
> application?

Right, I mean more default states. Based on your questions, I just thought 
that it would then be possible to implement the tree as menu as well. Only 
makes sense in mind.

> > for example whether non-available items should be not displayed or be
> > disabled. Another possible feature would be the grouping of
> > menu-items and
> > inserting meta-items, such as a separator.
>
> Uh, I forgot the separators in the unordered list concept...
>
> Has anybody some ideas, for supporting separator in UL menues?
> Or knows a good sample.

I think it is just another list item with a special class. Should be easy for 
browsers to see

Regards,
Stephan
-- 
Stephan Richter
CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student)
Web2k - Web Software Design, Development and Training