Hi JV, 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: > IMO we need both solution 1 and solution 2 for various use cases and applications. If in this period we start with 2) is fine by me. Regardless of the solutions, a future need will be to list different applications depending on the user's type (like list ColorTheme application just for Admins, etc.) so it will need also to contain an application type/visibility (user, dev, admin). Another use case was to be able to define your favourite applications, allowing a normal user to use a mechanism that automatically created such a panel based on giving favourite stars to his favourite applications. I'm mentioning these ideas because they need to be at least considered for future modifications of the implementation. > > 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 > > I just want to mention some work done for the Customizable Panels (Menus). I know they are not quite related to this topic, but could serve as a minimal inspiration. http://extensions.xwiki.org/xwiki/bin/view/Extension/Navigation+Menu+Wiki+Macro http://incubator.myxwiki.org/xwiki/bin/view/Improvements/CustomizablePanels A dynamic solution similar to ConfigurableClass would be very nice indeed. > 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 > One purpose of the CustomizablePanels was that they could be also edited by simple users and the requirement was that the menu editor UI should be very simple to use. One of the CustomizablePanels initials ideas was the use case where the user could enter also external links (http://). So the "target" should not be limited just to wiki pages. Thanks, Caty > - 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 > _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
