9 Jul
2012
9 Jul
'12
5:43 p.m.
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
- '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.
9 Jul
9 Jul
6:10 p.m.
New subject: [xwiki-devs] [Proposal] Applications panel and configurable menus
Hi JV,
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:
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+M…
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
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
6:41 p.m.
New subject: [xwiki-devs] [Proposal] Applications panel and configurable menus
On Mon, Jul 9, 2012 at 6:10 PM, Ecaterina Moraru (Valica)
<valicac(a)gmail.com> wrote:
Hi JV,
On Mon, Jul 9, 2012 at 6:43 PM, Jean-Vincent Drean <jv(a)xwiki.com> wrote:
Yes we'll certainly need 1) for other things, I was only talking about
XWIKI-7927 here.
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.
I did remember the extension and went to see it before sending the proposal.
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.
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+M…
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 ?
> 
10 Jul
10 Jul
8:22 a.m.
New subject: [xwiki-devs] [Proposal] Applications panel and configurable menus
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.
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
11 a.m.
New subject: [xwiki-devs] [Proposal] Applications panel and configurable menus
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:
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.
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.
Thanks,
Marius
--
Jean-Vincent Drean,
XWiki.
- '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 
1:05 p.m.
New subject: [xwiki-devs] [Proposal] Applications panel and configurable menus
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] http://xwiki.markmail.org/thread/jj6z3ywptaqesv4r
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:
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.
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.
Thanks,
Marius
--
Jean-Vincent Drean,
XWiki.
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
- '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
11 Jul
11 Jul
5:53 p.m.
New subject: [xwiki-devs] [Proposal] Applications panel and configurable menus
On Tue, Jul 10, 2012 at 1:05 PM, Eduard Moraru <enygma2002(a)gmail.com> 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 <jv(a)xwiki.com> wrote:
--
Jean-Vincent Drean,
XWiki.
On Tue, Jul 10, 2012 at 8:22 AM, Marius Dumitru
Florea
<mariusdumitru.florea(a)xwiki.com> wrote:
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs On Mon, Jul 9, 2012 at 6:43 PM, Jean-Vincent
Drean <jv(a)xwiki.com> wrote:
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.
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.
Thanks,
Marius
--
Jean-Vincent Drean,
XWiki.
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
- '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 
4:27 p.m.
New subject: [xwiki-devs] [Proposal] Applications panel and configurable menus
I've just had a brainstorming session with JV.
The outcome is:
+1 for 2) and +1 to implement the generic extension UI mechanism I had proposed and which
has already been voted.
JV will provide more details on the implementation later on (we've brainstormed
that).
Thanks
-Vincent
On Jul 9, 2012, at 5:43 PM, Jean-Vincent Drean 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
- '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.
4546
days inactive
4548
days old
7 comments
5 participants
participants (5)
-
Ecaterina Moraru (Valica) -
Eduard Moraru -
Jean-Vincent Drean -
Marius Dumitru Florea -
Vincent Massol