I've just had a brainstorming session with JV. The outcome is: +1 for 2) and +1 to implement the generic extension UI mechanism I had proposed and which has already been voted.
JV will provide more details on the implementation later on (we've brainstormed that). Thanks -Vincent On Jul 9, 2012, at 5:43 PM, Jean-Vincent Drean 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 > - '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
