I will post the thing in a few days, we are still polishing
some details...
--
Gonzalo A. Diethelm
[EMAIL PROTECTED]
> -----Original Message-----
> From: Vidakovic Aleksandar [mailto:[EMAIL PROTECTED]]
> Sent: Saturday, July 28, 2001 3:31 AM
> To: [EMAIL PROTECTED]
> Subject: Re: Menu service
>
>
> 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]
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
