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

Reply via email to