Hi, I have briefly scanned the discussion and noticed that a proposal has been made to implement a dynamic mechanism that is focused only on menus. However, please note that we already have a more general proposal [1] for UI extensions from Vincent that is eager to be implemented :).
IMO, if you (JV) are planning to work on something like this, I`d suggest that you do the more general approach that is pretty equivalent in terms of work needed AFAICT. Thanks, Eduard ---------- [1] http://xwiki.markmail.org/thread/jj6z3ywptaqesv4r On Tue, Jul 10, 2012 at 12:00 PM, Jean-Vincent Drean <[email protected]> wrote: > On Tue, Jul 10, 2012 at 8:22 AM, Marius Dumitru Florea > <[email protected]> wrote: > > On Mon, Jul 9, 2012 at 6:43 PM, Jean-Vincent Drean <[email protected]> wrote: > >> Hi devs, > >> > >> in order to implement XWIKI-7927, "Create an entry point for all > >> available applications inside the wiki" which I plan to commit before > >> 4.2M2 we need to agree on a strategy. > >> > >> The discussions point to a panel in the right column called > >> "Applications" which would list all the applications. Here are my > >> current thoughts about it. We can: > >> > >> 1) Rely solely on application descriptors and list all those > >> applications in the panel. > >> > >> - we don't have such a descriptor yet, the main reason is that what > >> should goes in it can be discussed over and over, even by a single > >> person. Thomas ? :) > >> - it would require an additional mechanism if we wish to be able to > >> edit (ordering, removal) the panel entries; and I think we will want > >> that > >> > >> 2) Implement a menu component that would allow to build dynamic menus. > >> > >> I think applications should be able to plug themselves in the user UI > >> in a manner similar to the way they plug themselves in the > >> administration (ConfigurableClass). > >> It would: > >> - Be generic, we could re-use this mechanism to build both the > >> applications panel and the other XWiki menus (top menu, content menu) > >> - Allow to separate the presence of an application in the wiki with > >> it's presence in the user UI > >> - Allow applications to add entries to top and content menus > >> > >> It could look like this: > >> > >> XWiki.MenuEntryClass > >> - id: String. Technical ID of the entry > >> - menuId: String. ID of the menu the entry is part of > >> - parentMenuEntryId: String. ID of a parent menu entry (optional). > >> Allows to build submenus (example: top menu). > >> - scope: Static list. List of actions the entry should appear for: > >> view/edit/admin/preview. > >> - position: Int. Position in the menu, we could use 0 as undefined > >> (bottom) and order from 1 to n. Also used to position items in > >> submenus. > >> - label: String. Label of the entry. Would be evaluated (velocity ? > >> wiki syntax ?) to allow i18n > >> - target: String. Fullname of the wiki page to point to > >> - enabled: Boolean. Allow to remove an entry from the menu without > >> actual deletion > >> - iconAttachment: String. Name of the attachment to use as the entry > >> icon (optional) > >> > >> Notes: > > > >> - Objects from this class would be stored in preferences documents > >> since they'll hold configured positions and the enabled state > > > > You mean Space.WebPreferences? I suppose this configuration will be > > packaged with the application pages, so the (top) menu configuration > > will be spread across multiple (application) spaces. > > > > Ah no, I meant application preferences, those pages we already use to > store preferences editable from the administration > (ConfigurableClass). > > The options: > a) Have dedicated pages for menu entries: -0 > b) Put the objects in one of the application pages: -1, it'd make > upgrades more painful > c) Put the objects in the prefs page of the application (along with > the ConfigurableClass), create one if there's none: +1, one page that > should be excluded/merged during upgrade sounds better to me. > > > Thanks, > > Marius > > > >> - 'separator' could be a reserved entry ID > >> > >> XWiki.MenuClass > >> - id: String. Technical ID of the menu > >> > >> This class would be associated with a XWiki.MenuSheet and would > >> display the menu editor, which could be simple for a first version (no > >> drag & drop). > >> > >> You might have guessed I'm more in favor of 2) even if I can't > >> refactor the top and content menus for the moment. > >> > >> WDYT ? > >> > >> Thanks, > >> JV. > >> _______________________________________________ > >> devs mailing list > >> [email protected] > >> http://lists.xwiki.org/mailman/listinfo/devs > > _______________________________________________ > > devs mailing list > > [email protected] > > http://lists.xwiki.org/mailman/listinfo/devs > > > > -- > Jean-Vincent Drean, > XWiki. > _______________________________________________ > devs mailing list > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs > _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
