On Mon, Jul 9, 2012 at 6:10 PM, Ecaterina Moraru (Valica) <[email protected]> wrote: > 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. >
Yes we'll certainly need 1) for other things, I was only talking about XWIKI-7927 here. > 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 I did remember the extension and went to see it before sending the proposal. > http://incubator.myxwiki.org/xwiki/bin/view/Improvements/CustomizablePanels Didn't know this one but I think the best would be to be able to use the WYSIWYG editor for panels content, it would make a lot of sense for the quicklinks one. > > 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 ? >> _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
