Salut,
an excellent idea!!! Do you want to post your work? It would help us a
lot in our current project. If appreciated we would contribute any
additional thoughts we get on working with your package...
Aleks
Diethelm Guallar, Gonzalo wrote:
>Several (maybe all) of the apps we are developing need some form of
>menu that can easily be administered, ties into the security system
>and is generic enough to support multiple needs. I have been working
>on a design that will fit our needs, and I think this might make a
>nice addition to Turbine. So, let me explain what I'm thinking about,
>and hopefully I can get some feedback from the development group.
>
>A Menu is just a hierarchy of operations to be displayed somehow for
>the user. Each operation consists of the following:
>
>* An id.
>* An optional action to invoke.
>* An optional screen to end up showing.
>* A permission required to perform the operation.
>
>This would all fit into an OPERATION table, and an internal
>representation in an Operation class. Then, a menu would have:
>
>* An id.
>* A text to be displayed (multilanguage considerations here).
>* An operation id.
>* The parent menu id.
>
>This would all fit into a MENU table, with an internal representation
>in a Menu class. The parent relation would make it possible to build
>a hierarchical menu.
>
>Then we would have an interface MenuBuilder, which defines the
>operations to read a Menu definition and build an internal
>representation for it. Multiple classes implementing MenuBuilder
>could be built: DefaultMenuBuilder would read everything from a DB,
>XMLMenuBuilder could read everything from a set of XML files, etc.
>Incidentally, our projects would define their own means of building a
>menu.
>
>Once the menu is created into memory, we need to do something with it;
>there would be a class MenuRenderer, defining the operations to render
>a menu. It could be used like this:
>
> context.put("menu", getMenuRenderer(user));
>
> ...
>
> #foreach ($item in $menu.getItems())
> <a href="$item.getOperation()">$item.getText()</a>
> <br>
> #end
>
>This is where the permission system ties in with the menu system: the
>renderer would skip any menu items for which the user has no
>permission.
>
>Then, we could change something (not sure where) so that when the user
>executes an action, or goes to a screen, the system checks whether the
>user has the permission that allows him to do that.
>
>Finally, we would have a means to compose a menu from several
>instances of the Menu class, creating a MenuSet. My idea here is to
>support specifying things like this: the menu for a user is made up of
>menu General, which contains General options (for which probably
>everybody has the required permissions), then menu Financial, with the
>financial operations which the user is allowed to perform, and then
>menu Administration, with the administrative options (probably with
>tight security restrictions). The MenuSet would simply remember the
>listed Menu definitions, and render them all when so asked.
>
>That's it. One way or the other, we need this functionality and are
>currently building it. We would be very happy to include it into
>standard Turbine. Thanks,
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
