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 :).
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]
On Tue, Jul 10, 2012 at 12:00 PM, Jean-Vincent Drean <jv(a)xwiki.com> wrote:
On Tue, Jul 10, 2012 at 8:22 AM, Marius Dumitru
Florea
<mariusdumitru.florea(a)xwiki.com> wrote:
On Mon, Jul 9, 2012 at 6:43 PM, Jean-Vincent
Drean <jv(a)xwiki.com> 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
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Jean-Vincent Drean,
XWiki.
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs