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,
--
Gonzalo A. Diethelm
[EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
