What's the plan for supporting multi-level menus with response.menu?

[weheh]

I've read that this is possible with t2, but how about 1.57? I've
tried it with 1.57 and it doesn't seem to work. Any suggestions for
how to do nested multi-level menus with the current version?

[mdipierro]

The problem is that we do not want to include too many JS libraries
with the base distribution. Everybody has his/her own preferences when
it comes to menus.

[Iceberg]

> > On Mar 8, 1:09 am, weheh <richard_gor...@verizon.net> wrote:
> >
> > I've read that this is possible with t2, but how about 1.57? I've
> > tried it with 1.57 and it doesn't seem to work. Any suggestions for
> > how to do nested multi-level menus with the current version?

On Mar8, 11:38pm, mdipierro <mdipie...@cs.depaul.edu> wrote:
> The problem is that we do not want to include too many JS libraries
> with the base distribution. Everybody has his/her own preferences when
> it comes to menus.

I would have agree with Massimo about "not to include too many this
and that in the base distribution". But, when talking about the menu,
I beg a reconsideration.

Because menu is such a basic need in almost every web application. I
still remember years ago when I just began to develop my first web app
based on another "lightweight" web framework, soon I had to pause the
app development and dived into many javascript, css things to make my
first menu system work. It was painful.

So you can understand I am so happy when I start to use web2py and
find out that it comes with a decent and easy menu system (although
not multi-level). I almost do not need to touch any javascript but I
can still finish more and more apps. I call this PRODUCTIVITY.

So I do suggest web2py to have a multi-level menu system (while
keeping the current response.menu definition for backward
compatibility). It can benefit most common developers, and the rest
can customize their own menu anyway.

[mdipierro]

What about a CSS only solution like:

http://www.grc.com/menu2/invitro.htm

Massimo

[mdipierro]

If somebody send me a patch to welcome to use a css only cascade menu,
I will probably take it.
I am not doing it myself because I am not a good designer and it would
take forever to look decent.

It has to work cross browser and I do not want to have < if IE > tags
in the default layout.

Massimo

[Iceberg]

Thanks for the quick feedback.

CSS only solution or CSS+JS solution are both ok for me. After all,
end users only care about effects, not technology. :-) Anyway, the
GRC css menu sounds promising and looks good, so it will be a good
choice.

By the way, my personal favorite is something like this:
http://www.milonic.com/imagepack/itemicons.php
I mean, an icon image appearing at the beginning of each menu items,
can really make the menu looks vivid. But it is certainly not a
must. :-)

[weheh]

Gibson's solution is interesting and I like the fact that it's a CSS-
only implementation. Unfortunately, it doesn't keep track of which
link is currently selected, a feature I would like to have because it
makes navigation self-documenting, as it should be. Self-documenting
nav menus means you don't have to resort to an extra, and frankly
unnecessary, bread-crumb display, such as:

Home > level 1 > level 2 > you are here.

[AchipA]

Just an idea. How about keeping/extending the current syntax, and then
using some glue code to link that common format to particular menus ?
We could do a few examples by default (as we already have jQuery, you
can choose from dozens and dozens of different menu plugins), and let
the user write it's own if he prefers another JS lib - this way we
could retain a 'common' menu nomenclature regardless of the engine
used in the view ?

If you want to go even deeper, we could make the whole menu thing a
plugin (=application) and then you could literally pop in and pop out
different menus AND would get of ugly modules/models code usually
introduced with menus.

Comments, suggestion welcome.

[Yarko Tymciurak]

I'm a little confused:

menus included (as far as I can tell):

• t2.action()
• t2.menu()
• a tiny, tiny bit in layout.html
• static/scripts/sfmenu.js
• static/styles/sfmenu.css

All of the above (except for the little div, and {{=t2.menu()}} bit) is in t2.

T2 (right now) has at least one "backward compatibility issue, but once that is cleaned up (if I remember from what I ran into yesterday, we'll need a t2 that checks the version of web2py it's running under),

You should be free to use the "standard" menu way from t2, no?

Want something else, go ahead - but currently it would be nice to have "one" menu system that people can just quickly use w/o thinking too much about what they eventually want.

Am I missing something?

Regards,

Yarko

[AchipA]

t2 is *almost* what I'm talking about, but I have a few concerns,
correct me if I'm wrong

- you do need to include t2, it's not out of the box
- you can't customize the t2 menu with a custom JS backend
- the above means applications have to share menu engines (ugh)
- not jquery (IINM), which has nice plugis for this purpose

The questions is whether these can be addressed within t2, or am I
talking about a separate application ?

On Mar 8, 11:55 pm, Yarko Tymciurak <yark...@gmail.com> wrote:
> I'm a little confused:
> menus included (as far as I can tell):
>

>    - t2.action()
>    - t2.menu()
>    - a tiny, tiny bit in layout.html
>    - static/scripts/sfmenu.js
>    - static/styles/sfmenu.css

>
> All of the above (except for the little div, and {{=t2.menu()}} bit) is in
> t2.
>
> T2 (right now) has at least one "backward compatibility issue, but once that
> is cleaned up (if I remember from what I ran into yesterday, we'll need a t2
> that checks the version of web2py it's running under),
>
> You should be free to use the "standard" menu way from t2, no?
>
> Want something else, go ahead - but currently it would be nice to have "one"
> menu system that people can just quickly use w/o thinking too much about
> what they eventually want.
>
> Am I missing something?
>
> Regards,
> Yarko
>

[Iceberg]

Hello folks,

There are intermittent discussion about cascading menu from time to time.
http://groups.google.com/group/web2py/msg/9a04650f84649641
and recently:
http://groups.google.com/group/web2py/browse_frm/thread/cbe3556820e885bb

In this mail I attach a cascade menu draft. It is just a prototype far from being finished, because I am not good at css at all. I just try to define a kind of higher level syntax and make it work. The syntax features include:

* Each menu item can have a text label AND/OR an image icon.
* Submenus are appeared in a recursive way.

Volunteers are welcome to polish the work.

The only four major files I modified or introduced in this app are as below.

static/grcmenu.css # It actually comes from here (http://splike.com/projects/cssmenu.html)

models/menu.py # In final version, this would be adjusted into modules/menu.py

views/layout.html # Only one line genMenu(...) is inserted

controllers/default.py # The main sample

static/*.gif # Optional

Best regards,
Iceberg, 2009-May-03, 21:22(PM), Sun

----------------------- Original Message -----------------------
From: mdipierro <mdipie...@cs.depaul.edu>
To: web2py Web Framework <web...@googlegroups.com>
Date: Sun, 8 Mar 2009 11:06:02 -0700 (PDT)
Subject: Re: What's the plan for supporting multi-level menus with response.menu?
-------------------

[mdipierro]

Can you tweak and provide an example so that it can be used as popop
menus too?

>  web2py.app.menu.tar
> 233KViewDownload

[Francisco Gama]

Personally, I prefer mootools as a JS framework but I do understand
why you don't want to web2py tied with some framework that will never
please everybody. Besides, css based only has always advantages.

Steve Gibson is always a good reference ;)