On Tue, Jul 10, 2012 at 1:05 PM, Eduard Moraru <[email protected]> wrote: > 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 :). >
Thanks, I looked for the email a few days ago without finding it. I thought about it before sending the proposal and I had the impression that implementing such a mechanism would lead to a lot of code/html duplication in the extensions content, I was seeing each extension as a blank slate. After brainstorming with Vincent it appears that a generic parameters mechanism solves this, the fields in proposal 2) (action scope, link target, icon, etc), can be defined like this. This way the UI extension hook can manage all the presentation and use UI extensions only to retrieve the data it needs. I'll send a technical proposal ASAP. > 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 -- Jean-Vincent Drean, XWiki. _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
