[xwiki-devs] [Proposal] Change of behavior for Applications Panel and app registration in general
5 Oct
2016
5 Oct
'16
11:37 a.m.
Hi devs,
With the recent introduction of the Applications Index (see
http://extensions.xwiki.org/xwiki/bin/view/Extension/Application+Index+Appl…) we
need to agree on a few things.
In the past we had:
* We wanted all new app that you installed to automatically be visible in the Applications
Panel
* This is why the Applications Panel config had a blacklist (and not a white list)
What we’ve done:
* We add the Applications Index
* We removed some apps from the Applications Panel. Namely: Invitation, Panels, Scheduler,
User Directory and Tour applications. this was done using hardcoded blacklist xobjects in
PanelsCode.ApplicationsPanelConfiguration.
The need:
* We need to remove this hack. It’s not normal for the Panels module to know all the apps
that shouldn’t be listed in it!
Proposal:
* Replace the blacklist configuration of the Applications Panel by a whitelist one
* When a new app is installed, list it in the Applications Index but don’t add it to the
Applications Panel
* If an admin wants to add this new for his users, he’ll need to add it in the Admin UI
for the Applications Panel.
WDYT?
Thanks
-Vincent
5 Oct
5 Oct
12:08 p.m.
New subject: [xwiki-devs] [Proposal] Change of behavior for Applications Panel and app registration in general
On Wed, Oct 5, 2016 at 12:37 PM, Vincent Massol <vincent(a)massol.net> wrote:
Hi devs,
With the recent introduction of the Applications Index (see
http://extensions.xwiki.org/xwiki/bin/view/Extension/
Application+Index+Application/) we need to agree on a few things.
In the past we had:
* We wanted all new app that you installed to automatically be visible in
the Applications Panel
* This is why the Applications Panel config had a blacklist (and not a
white list)
There are some nice side effects of the current behavior that I would not
want to lose:
A. after you install an app with the EM, it immediately appears (if it has
the UIX defined) in the AppBar and is ready for usage. The admin does not
need to do the second step manually. We save him a click (in practice is
more than a click).
B. after you create a new app with AWM, you automatically have it in the
AppBar. In theory that app should be useful for the user, since he manually
create it to his own liking. We are saving him a click+.
The only problem is when the wiki is getting out of control, too many apps,
no favorite order, just alphabetical. For this there is this issue
http://jira.xwiki.org/browse/XWIKI-13075
What we’ve done:
* We add the Applications Index
* We removed some apps from the Applications Panel. Namely: Invitation,
Panels, Scheduler, User Directory and Tour
applications. this was done
using hardcoded blacklist xobjects in PanelsCode.
ApplicationsPanelConfiguration.
The need:
* We need to remove this hack. It’s not normal for the Panels module to
know all the apps that shouldn’t be listed in it!
So the main problem is that currently the AppBar is defined in Panels
module, instead of the Application module. This is known and we also have
an issue for the move, see http://jira.xwiki.org/browse/XWIKI-13502 , we
just didn't had the time to do it.
Proposal:
* Replace the blacklist configuration of the Applications Panel by a
whitelist one
* When a new app is installed, list it in the Applications Index but don’t
add it to the Applications Panel
* If an admin wants to add this new for his users, he’ll need to add it in
the Admin UI for the Applications Panel.
WDYT?
I'm not sure I like this very much :)
IMO the main problem is that we are using the "Add Application" UIX
http://platform.xwiki.org/xwiki/bin/view/ExtensionPoint/AddApplicationUIX
to define applications.
For me, ideally, we would have a separate mechanism to define an app (not
this UIX). Application Index would display all the XARs that contain an app
descritor, while the AppBar would list the apps that have the UIX.
The problem with the AppBar and the blacklisting appeared when we added the
UIX to applications that were not "user-oriented", not useful in the daily
flow, not needed for fast navigation prioritization, but that contained the
UIX since we added this step to our recommended development app practices.
Ideally the UIX should be added to applications intended for normal users
that need a fast access point in the AppBar.
Having it as a white list, will reduce the user-centered applications
discoverability and rapid access.
WDYT?
Thanks,
Caty
Thanks
-Vincent
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
12:35 p.m.
New subject: [xwiki-devs] [Proposal] Change of behavior for Applications Panel and app registration in general
On 05 Oct 2016, at 12:08, Ecaterina Moraru (Valica)
<valicac(a)gmail.com> wrote:
On Wed, Oct 5, 2016 at 12:37 PM, Vincent Massol <vincent(a)massol.net> wrote:
However following this strategy you shouldn’t be allowed to blacklist the apps that you
blacklisted since they fail point A now (and you should consider them as extensions - we
bundle them but they could be not bundled, and the same problem will appear with contrib
extensions.
What I’m questioning is considering that Invitation, Panels, Scheduler, User Directory
and Tour are special applications and that we only want to hide those and all others
should be listed by default.
Hi devs,
With the recent introduction of the Applications Index (see
http://extensions.xwiki.org/xwiki/bin/view/Extension/
Application+Index+Application/) we need to agree on a few things.
In the past we had:
* We wanted all new app that you installed to automatically be visible in
the Applications Panel
* This is why the Applications Panel config had a blacklist (and not a
white list)
There are some nice side effects of the current behavior that I would not
want to lose:
A. after you install an app with the EM, it immediately appears (if it has
the UIX defined) in the AppBar and is ready for usage. The admin does not
need to do the second step manually. We save him a click (in practice is
more than a click).
B. after you create a new app with AWM, you automatically have it in the
AppBar. In theory that app should be useful for the user, since he manually
create it to his own liking. We are saving him a click+. The only problem is when the wiki is getting out of
control, too many apps,
no favorite order, just alphabetical. For this there is this issue
http://jira.xwiki.org/browse/XWIKI-13075
What we’ve done:
* We add the Applications Index
* We removed some apps from the Applications Panel. Namely: Invitation,
Panels, Scheduler, User Directory and Tour
applications. this was done
using hardcoded blacklist xobjects in PanelsCode.
ApplicationsPanelConfiguration.
The need:
* We need to remove this hack. It’s not normal for the Panels module to
know all the apps that shouldn’t be listed in it!
So the main problem is that currently the AppBar is defined in Panels
module, instead of the Application module. This is known and we also have
an issue for the move, see http://jira.xwiki.org/browse/XWIKI-13502 , we
just didn't had the time to do it. Proposal:
* Replace the blacklist configuration of the Applications Panel by a
whitelist one
* When a new app is installed, list it in the Applications Index but don’t
add it to the Applications Panel
* If an admin wants to add this new for his users, he’ll need to add it in
the Admin UI for the Applications Panel.
WDYT?
I'm not sure I like this very much :)
IMO the main problem is that we are using the "Add Application" UIX
http://platform.xwiki.org/xwiki/bin/view/ExtensionPoint/AddApplicationUIX
to define applications.
For me, ideally, we would have a separate mechanism to define an app (not
this UIX). Application Index would display all the XARs that contain an app
descritor, while the AppBar would list the apps that have the UIX. The problem with the AppBar and the blacklisting
appeared when we added the
UIX to applications that were not "user-oriented", not useful in the daily
flow, not needed for fast navigation prioritization, but that contained the
UIX since we added this step to our recommended development app practices.
Ideally the UIX should be added to applications intended for normal users
that need a fast access point in the AppBar.
This was catered for already. If you were not an admin the App Panel was only listing
user-oriented apps (there was a check for admins in apps). Personally I don’t agree with
the rationale that Admins are lesser users of the wiki and that they shouldn’t have fast
access to admin apps.
If an Admin installs a new admin app (for ex), that app will be displayed in the App Panel
and we certainly don’t want to add yet another blacklist xobject in the App Panel.
Having it as a white list, will reduce the
user-centered applications
discoverability and rapid access.
That’s the role of the App Index IMO. Maybe we need to make it more visible or maybe it’s
just because we’re not used to it yet.
So my understanding is that the behavior you’d like like is:
* Keep a blacklist of app for the XE flavor (KB flavor soon). So this means the config
should be moved to the flavor.
* All further apps installed by an admin will appear in the App Panel, even if they’re for
admins only. It’s up to the admin to decide to remove them or not and decide if he wants
to show the one we blacklisted in the flavor by default.
Sounds globally ok to me.
I guess the only point where I’m not 100% in agreement is the removal of quick access to
admin apps for admins but I’m not going to fight this since it’s not that important that
admin users have to do 2 extra clicks to access them, and if we consider the App Panel as
a favorite it’s acceptable.
Thanks
-Vincent
WDYT?
Thanks,
Caty
>
> Thanks
> -Vincent
4:47 p.m.
New subject: [xwiki-devs] [Proposal] Change of behavior for Applications Panel and app registration in general
On Wed, Oct 5, 2016 at 1:35 PM, Vincent Massol <vincent(a)massol.net> wrote:
has
So as I said, I don't consider the mentioned apps as user-centered apps
(Invitation and Panels are for Admins, User Directory was already in the
Drawer, Tour and Scheduler are technical). They should have the UIX to be
promoted in the AppBar, but sure we should find a way to say they are apps.
It would be exactly the same problem. There’s no reason for the
Application module to depend on all those apps and that’s not a good
practice IMO.
Let me ask differently: why did you moved out those apps? Just because or
are there some rules that you applied? In that case shouldn’t those rules
also be applied to any other app that’s installed?
The apps were not something an user would benefit from every day. And yes
this rule should apply to any other apps that wants to get inserted in the
AppBar, which is a QuickLinks for apps.
AddApplicationUIX
So depends how we create the definition of the Flavor, if it's from the
scratch (as list of module) or from XE. If it's from XE, than yes, the
flavor could overwrite or provide the list of default bundled blacklisted
apps that it does not want to promote. Each flavor could optimize the
AppBar according to its needs. If the flavor is from scratch and it selects
from the start the needed apps, the initial blacklist could be empty.
On 05 Oct 2016, at 12:08, Ecaterina Moraru
(Valica) <valicac(a)gmail.com>
wrote:
On Wed, Oct 5, 2016 at 12:37 PM, Vincent Massol <vincent(a)massol.net>
wrote:
> Hi devs,
>
> With the recent introduction of the Applications Index (see
> http://extensions.xwiki.org/xwiki/bin/view/Extension/
> Application+Index+Application/) we need to agree on a few things.
>
> In the past we had:
> * We wanted all new app that you installed to automatically be visible
in
the
Applications Panel
* This is why the Applications Panel config had a blacklist (and not a
white list)
There are some nice side effects of the current behavior that I would not
want to lose:
A. after you install an app with the EM, it immediately appears (if it the UIX defined) in the AppBar and is ready for
usage. The admin does not
need to do the second step manually. We save him a click (in practice is
more than a click).
B. after you create a new app with AWM, you automatically have it in the
AppBar. In theory that app should be useful for the user, since he
manually
create it to his own liking. We are saving him a
click+.
However following this strategy you shouldn’t be allowed to blacklist the
apps that you blacklisted since they fail point A now (and you should
consider them as extensions - we bundle them but they could be not bundled,
and the same problem will appear with contrib extensions.
What I’m questioning is considering that Invitation, Panels, Scheduler,
User Directory and Tour are special applications and that we only want to
hide those and all others should be listed by default.
The only problem is when the wiki is getting out
of control, too many
apps,
no favorite order, just alphabetical. For this
there is this issue
http://jira.xwiki.org/browse/XWIKI-13075
What we’ve done:
* We add the Applications Index
* We removed some apps from the Applications Panel. Namely: Invitation,
Panels, Scheduler, User Directory and Tour
applications. this was done
using hardcoded blacklist xobjects in PanelsCode.
ApplicationsPanelConfiguration.
The need:
* We need to remove this hack. It’s not normal for the Panels module to
know all the apps that shouldn’t be listed in it!
So the main problem is that currently the AppBar is defined in Panels
module, instead of the Application module. This is known and we also have
an issue for the move, see http://jira.xwiki.org/browse/XWIKI-13502 , we
just didn't had the time to do it.
> Proposal:
> * Replace the blacklist configuration of the Applications Panel by a
> whitelist one
> * When a new app is installed, list it in the Applications Index but
don’t
> add it to the Applications Panel
> * If an admin wants to add this new for his users, he’ll need to add it
in
the Admin
UI for the Applications Panel.
WDYT?
I'm not sure I like this very much :)
IMO the main problem is that we are using the "Add Application" UIX
http://platform.xwiki.org/xwiki/bin/view/ExtensionPoint/ to define applications.
For me, ideally, we would have a separate mechanism to define an app (not
this UIX). Application Index would display all the XARs that contain an
app
descritor, while the AppBar would list the apps
that have the UIX.
I’ve been thinking about this and I have a different opinion. IMO we can
continue to have the same UIXP for the App Index and the App Panel.
It seems logical to me that:
* The Application Index is the place where an app that you install is added
* Now that we have an App index, the App Panel should be a Favorite, i.e.
listing favorite apps decided by the Admin of the wiki (and in the future
users may be able to override with their own favorites if the admin allows
it)
The problem with the AppBar and the blacklisting
appeared when we added
the
UIX to applications that were not
"user-oriented", not useful in the
daily
flow, not needed for fast navigation
prioritization, but that contained
the
UIX since we added this step to our recommended
development app
practices.
Ideally the UIX should be added to applications
intended for normal users
that need a fast access point in the AppBar.
This was catered for already. If you were not an admin the App Panel was
only listing user-oriented apps (there was a check for admins in apps).
Personally I don’t agree with the rationale that Admins are lesser users of
the wiki and that they shouldn’t have fast access to admin apps.
If an Admin installs a new admin app (for ex), that app will be displayed
in the App Panel and we certainly don’t want to add yet another blacklist
xobject in the App Panel.
Having it as a white list, will reduce the
user-centered applications
discoverability and rapid access.
That’s the role of the App Index IMO. Maybe we need to make it more
visible or maybe it’s just because we’re not used to it yet.
So my understanding is that the behavior you’d like like is:
* Keep a blacklist of app for the XE flavor (KB flavor soon). So this
means the config should be moved to the flavor.
* All further apps installed by an admin will appear
in the App Panel,
even if they’re for admins only. It’s up to the admin to decide to remove
them or not and decide if he wants to show the one we blacklisted in the
flavor by default.
Sounds globally ok to me.
I guess the only point where I’m not 100% in agreement is the removal of
quick access to admin apps for admins but I’m not going to fight this since
it’s not that important that admin users have to do 2 extra clicks to
access them, and if we consider the App Panel as a favorite it’s acceptable.
Regarding admins, some apps have some UIX code that mentions that the app
should be listed only for Admins, but that's another story.
If we were to create personalized favorites lists
http://jira.xwiki.org/browse/XWIKI-13770 than we will have a recommended
initial list that every user (including Admin) could customize (but this is
already an advanced / extended use case). User might not even know that
they can customize the AppBar (because we don't have an Edit/Customize
button for that panel and also the Application Panel section is inside the
Applications area, instead of being near the Look&Feel and Panel Wizard)
[but that's another story].
Thanks,
Caty
Thanks
-Vincent
WDYT?
Thanks,
Caty
>
> Thanks
> -Vincent
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
4:49 p.m.
New subject: [xwiki-devs] [Proposal] Change of behavior for Applications Panel and app registration in general
On Wed, Oct 5, 2016 at 5:47 PM, Ecaterina Moraru (Valica) <valicac(a)gmail.com
have
The apps were not something an user would benefit from every day. And yes
this rule should apply to any other apps that wants to get inserted in the
AppBar, which is a QuickLinks for apps.
pplicationUIX
So depends how we create the definition of the Flavor, if it's from the
scratch (as list of module) or from XE. If it's from XE, than yes, the
flavor could overwrite or provide the list of default bundled blacklisted
apps that it does not want to promote. Each flavor could optimize the
AppBar according to its needs. If the flavor is from scratch and it selects
from the start the needed apps, the initial blacklist could be empty.
wrote:
>
>
> On Wed, Oct 5, 2016 at 1:35 PM, Vincent Massol <vincent(a)massol.net wrote:
>
>>
>> > On 05 Oct 2016, at 12:08, Ecaterina Moraru (Valica)
<valicac(a)gmail.com>
> wrote:
>> >
>> > On Wed, Oct 5, 2016 at 12:37 PM, Vincent Massol <vincent(a)massol.net>
> wrote:
>> >
>> >> Hi devs,
>> >>
>> >> With the recent introduction of the Applications Index (see
>> >> http://extensions.xwiki.org/xwiki/bin/view/Extension/
>> >> Application+Index+Application/) we need to agree on a few things.
>> >>
>> >> In the past we had:
>> >> * We wanted all new app that you installed to automatically be visible
>> in
>> >> the Applications Panel
>> >> * This is why the Applications Panel config had a blacklist (and not a
>> >> white list)
>> >>
>> >
>> > There are some nice side effects of the current behavior that I would
>> not
>> > want to lose:
>> > A. after you install an app with the EM, it immediately appears (if it
>> has
>> > the UIX defined) in the AppBar and is ready for usage. The admin does
>> not
>> > need to do the second step manually. We save him a click (in practice is
>> > more than a click).
>> > B. after you create a new app with AWM, you automatically have it in the
>> > AppBar. In theory that app should be useful for the user, since he
>> manually
>> > create it to his own liking. We are saving him a click+.
>>
>> However following this strategy you shouldn’t be allowed to blacklist the
>> apps that you blacklisted since they fail point A now (and you should
>> consider them as extensions - we bundle them but they could be not bundled,
>> and the same problem will appear with contrib extensions.
>>
>> What I’m questioning is considering that Invitation, Panels, Scheduler,
>> User Directory and Tour are special applications and that we only want to
>> hide those and all others should be listed by default.
>>
>
> So as I said, I don't consider the mentioned apps as user-centered apps
> (Invitation and Panels are for Admins, User Directory was already in the
> Drawer, Tour and Scheduler are technical). They should have the UIX to be
> promoted in the AppBar, but sure we should find a way to say they are apps.
>
* shouldn't
The only problem is when the wiki is getting out
of control, too many
apps,
no favorite order, just alphabetical. For this
there is this issue
http://jira.xwiki.org/browse/XWIKI-13075
What we’ve done:
* We add the Applications Index
* We removed some apps from the Applications Panel. Namely: Invitation,
Panels, Scheduler, User Directory and Tour
applications. this was done
using hardcoded blacklist xobjects in PanelsCode.
ApplicationsPanelConfiguration.
The need:
* We need to remove this hack. It’s not normal for the Panels module to
know all the apps that shouldn’t be listed in it!
So the main problem is that currently the AppBar is defined in Panels
module, instead of the Application module. This is known and we also an issue for the move, see
http://jira.xwiki.org/browse/XWIKI-13502 ,
we
just didn't had the time to do it.
It would be exactly the same problem. There’s no reason for the
Application module to depend on all those apps and that’s not a good
practice IMO.
Let me ask differently: why did you moved out those apps? Just because or
are there some rules that you applied? In that case shouldn’t those rules
also be applied to any other app that’s installed?
> Proposal:
> * Replace the blacklist configuration of the Applications Panel by a
> whitelist one
> * When a new app is installed, list it in the Applications Index but
don’t
> add it to the Applications Panel
> * If an admin wants to add this new for his users, he’ll need to add
it in
the Admin
UI for the Applications Panel.
WDYT?
I'm not sure I like this very much :)
IMO the main problem is that we are using the "Add Application" UIX
http://platform.xwiki.org/xwiki/bin/view/ExtensionPoint/AddA to define applications.
For me, ideally, we would have a separate mechanism to define an app
(not
this UIX). Application Index would display all
the XARs that contain an
app
descritor, while the AppBar would list the apps
that have the UIX.
I’ve been thinking about this and I have a different opinion. IMO we can
continue to have the same UIXP for the App Index and the App Panel.
It seems logical to me that:
* The Application Index is the place where an app that you install is
added
* Now that we have an App index, the App Panel should be a Favorite, i.e.
listing favorite apps decided by the Admin of the wiki (and in the future
users may be able to override with their own favorites if the admin allows
it)
The problem with the AppBar and the blacklisting
appeared when we added
the
UIX to applications that were not
"user-oriented", not useful in the
daily
flow, not needed for fast navigation
prioritization, but that contained
the
UIX since we added this step to our recommended
development app
practices.
Ideally the UIX should be added to applications
intended for normal
users
that need a fast access point in the AppBar.
This was catered for already. If you were not an admin the App Panel was
only listing user-oriented apps (there was a check for admins in apps).
Personally I don’t agree with the rationale that Admins are lesser users of
the wiki and that they shouldn’t have fast access to admin apps.
If an Admin installs a new admin app (for ex), that app will be displayed
in the App Panel and we certainly don’t want to add yet another blacklist
xobject in the App Panel.
Having it as a white list, will reduce the
user-centered applications
discoverability and rapid access.
That’s the role of the App Index IMO. Maybe we need to make it more
visible or maybe it’s just because we’re not used to it yet.
So my understanding is that the behavior you’d like like is:
* Keep a blacklist of app for the XE flavor (KB flavor soon). So this
means the config should be moved to the flavor.
* All further apps installed by an admin will
appear in the App Panel,
even if they’re for admins only. It’s up to the admin to decide to remove
them or not and decide if he wants to show the one we blacklisted in the
flavor by default.
Sounds globally ok to me.
I guess the only point where I’m not 100% in agreement is the removal of
quick access to admin apps for admins but I’m not going to fight this since
it’s not that important that admin users have to do 2 extra clicks to
access them, and if we consider the App Panel as a favorite it’s acceptable.
Regarding admins, some apps have some UIX code that mentions that the app
should be listed only for Admins, but that's another story.
If we were to create personalized favorites lists
http://jira.xwiki.org/browse/XWIKI-13770 than we will have a recommended
initial list that every user (including Admin) could customize (but this is
already an advanced / extended use case). User might not even know that
they can customize the AppBar (because we don't have an Edit/Customize
button for that panel and also the Application Panel section is inside the
Applications area, instead of being near the Look&Feel and Panel Wizard)
[but that's another story].
Thanks,
Caty
Thanks
-Vincent
WDYT?
Thanks,
Caty
>
> Thanks
> -Vincent
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
5:55 p.m.
New subject: [xwiki-devs] [Proposal] Change of behavior for Applications Panel and app registration in general
Hi,
The only thing I could say about this is that I would also prefer to have
the App Panel be configured by an admin exclusively manually (i.e. not
having apps added by default, when they are installed). All the installed
apps should be listed in the App Panel administration section, and the
admin should be able to pick from them and specify the order.
Additionally, I would like the same behavior to be available for any use,
thus being able to customize his App Panel (plus the option to reset to the
default apps, configured by the admin).
The analogy here is obviously the User Directory columns customization
which works exactly in the above described way: admin sets defaults, use
can customize his own view.
Bonus/Nice to have: When visiting an application`s homepage, a user should
be able to see under "More Actions" (or somewhere) an option to "Add to
App
Panel" :)
Bonus2/Derailing: Just thinking about the nice to have feature above, it
would also be awesome to have some "Shortcuts" panel that would allow you
to add any page to it, for quick reference. Each user would have his own
"shortcuts". Something a bit similar to the Desktop in an Operating System.
Thanks,
Eduard
On Wed, Oct 5, 2016 at 5:49 PM, Ecaterina Moraru (Valica) <valicac(a)gmail.com
wrote:
> On Wed, Oct 5, 2016 at 5:47 PM, Ecaterina Moraru (Valica) <
> valicac(a)gmail.com
> wrote:
>
> >
> >
> > On Wed, Oct 5, 2016 at 1:35 PM, Vincent Massol <vincent(a)massol.net>
wrote:
> >
> >>
> >> > On 05 Oct 2016, at 12:08, Ecaterina Moraru (Valica) <
> valicac(a)gmail.com>
> > wrote:
> >>
>
> >> > On Wed, Oct 5, 2016 at 12:37 PM, Vincent Massol
<vincent(a)massol.net>
> > wrote:
> >>
>
> >> >> Hi devs,
> >> >>
> >> >> With the recent introduction of the Applications Index (see
> >> >> http://extensions.xwiki.org/xwiki/bin/view/Extension/
> >> >> Application+Index+Application/) we need to agree on a few things.
> >> >>
> >> >> In the past we had:
> >> >> * We wanted all new app that you installed to automatically be
> visible
> >> in
> >> >> the Applications Panel
> >> >> * This is why the Applications Panel config had a blacklist (and
not
> a
> >> >> white list)
> >> >>
> >> >
> >> > There are some nice side effects of the current behavior that I would
> >> not
> >> > want to lose:
> >> > A. after you install an app with the EM, it immediately appears (if it
> >> has
> >> > the UIX defined) in the AppBar and is ready for usage. The admin does
> >> not
> >> > need to do the second step manually. We save him a click (in practice
> is
> >> > more than a click).
> >> > B. after you create a new app with AWM, you automatically have it in
> the
> >> > AppBar. In theory that app should be useful for the user, since he
> >> manually
> >> > create it to his own liking. We are saving him a click+.
> >>
> >> However following this strategy you shouldn’t be allowed to blacklist
> the
> >> apps that you blacklisted since they fail point A now (and you should
> >> consider them as extensions - we bundle them but they could be not
> bundled,
> >> and the same problem will appear with contrib extensions.
> >>
> >> What I’m questioning is considering that Invitation, Panels, Scheduler,
> >> User Directory and Tour are special applications and that we only want
> to
> >> hide those and all others should be listed by default.
> >>
> >
> > So as I said, I don't consider the mentioned apps as user-centered apps
> > (Invitation and Panels are for Admins, User Directory was already in the
> > Drawer, Tour and Scheduler are technical). They should have the UIX to be
> > promoted in the AppBar, but sure we should find a way to say they are
> apps.
> >
> * shouldn't
>
> >
> >
> >>
> >> > The only problem is when the wiki is getting out of control, too many
> >> apps,
> >> > no favorite order, just alphabetical. For this there is this issue
> >> > http://jira.xwiki.org/browse/XWIKI-13075
> >>
> >>
> >> >
> >> >> What we’ve done:
> >> >> * We add the Applications Index
> >> >>
> >> > * We removed some apps from the Applications Panel. Namely:
> Invitation,
> >> >> Panels, Scheduler, User Directory and Tour applications. this was
> done
> >> >> using hardcoded blacklist xobjects in PanelsCode.
> >> >> ApplicationsPanelConfiguration.
> >> >>
> >> >> The need:
> >> >> * We need to remove this hack. It’s not normal for the Panels
module
> to
> >> >> know all the apps that shouldn’t be listed in it!
> >> >>
> >> >
> >> > So the main problem is that currently the AppBar is defined in Panels
> >> > module, instead of the Application module. This is known and we also
> >> have
> >> > an issue for the move, see http://jira.xwiki.org/browse/XWIKI-13502 ,
> >> we
> >> > just didn't had the time to do it.
> >>
> >> It would be exactly the same problem. There’s no reason for the
> >> Application module to depend on all those apps and that’s not a good
> >> practice IMO.
> >>
> >> Let me ask differently: why did you moved out those apps? Just because
> or
> >> are there some rules that you applied? In that case shouldn’t those
> rules
> >> also be applied to any other app that’s installed?
> >>
> >
> > The apps were not something an user would benefit from every day. And yes
> > this rule should apply to any other apps that wants to get inserted in
> the
> > AppBar, which is a QuickLinks for apps.
> >
> >
> >>
> >> >
> >> >> Proposal:
> >> >> * Replace the blacklist configuration of the Applications Panel by
a
> >> >> whitelist one
> >> >> * When a new app is installed, list it in the Applications Index
but
> >> don’t
> >> >> add it to the Applications Panel
> >> >> * If an admin wants to add this new for his users, he’ll need to
add
> >> it in
> >> >> the Admin UI for the Applications Panel.
> >> >>
> >> >> WDYT?
> >> >>
> >> >
> >> > I'm not sure I like this very much :)
> >> >
> >> > IMO the main problem is that we are using the "Add
Application" UIX
> >> > http://platform.xwiki.org/xwiki/bin/view/ExtensionPoint/AddA
> >> pplicationUIX
> >> > to define applications.
> >> > For me, ideally, we would have a separate mechanism to define an app
> >> (not
> >> > this UIX). Application Index would display all the XARs that contain
> an
> >> app
> >> > descritor, while the AppBar would list the apps that have the UIX.
> >>
> >> I’ve been thinking about this and I have a different opinion. IMO we can
> >> continue to have the same UIXP for the App Index and the App Panel.
> >>
> >> It seems logical to me that:
> >> * The Application Index is the place where an app that you install is
> >> added
> >> * Now that we have an App index, the App Panel should be a Favorite,
> i.e.
> >> listing favorite apps decided by the Admin of the wiki (and in the
> future
> >> users may be able to override with their own favorites if the admin
> allows
> >> it)
> >>
> >> > The problem with the AppBar and the blacklisting appeared when we
> added
> >> the
> >> > UIX to applications that were not "user-oriented", not useful
in the
> >> daily
> >> > flow, not needed for fast navigation prioritization, but that
> contained
> >> the
> >> > UIX since we added this step to our recommended development app
> >> practices.
> >> > Ideally the UIX should be added to applications intended for normal
> >> users
> >> > that need a fast access point in the AppBar.
> >>
> >> This was catered for already. If you were not an admin the App Panel was
> >> only listing user-oriented apps (there was a check for admins in apps).
> >> Personally I don’t agree with the rationale that Admins are lesser
> users of
> >> the wiki and that they shouldn’t have fast access to admin apps.
> >>
> >> If an Admin installs a new admin app (for ex), that app will be
> displayed
> >> in the App Panel and we certainly don’t want to add yet another
> blacklist
> >> xobject in the App Panel.
> >>
> >> > Having it as a white list, will reduce the user-centered applications
> >> > discoverability and rapid access.
> >>
> >> That’s the role of the App Index IMO. Maybe we need to make it more
> >> visible or maybe it’s just because we’re not used to it yet.
> >>
> >> So my understanding is that the behavior you’d like like is:
> >> * Keep a blacklist of app for the XE flavor (KB flavor soon). So this
> >> means the config should be moved to the flavor.
> >>
> >
> > So depends how we create the definition of the Flavor, if it's from the
> > scratch (as list of module) or from XE. If it's from XE, than yes, the
> > flavor could overwrite or provide the list of default bundled blacklisted
> > apps that it does not want to promote. Each flavor could optimize the
> > AppBar according to its needs. If the flavor is from scratch and it
> selects
> > from the start the needed apps, the initial blacklist could be empty.
> >
> >
> >> * All further apps installed by an admin will appear in the App Panel,
> >> even if they’re for admins only. It’s up to the admin to decide to
> remove
> >> them or not and decide if he wants to show the one we blacklisted in the
> >> flavor by default.
> >>
> >
> >> Sounds globally ok to me.
> >>
> >> I guess the only point where I’m not 100% in agreement is the removal of
> >> quick access to admin apps for admins but I’m not going to fight this
> since
> >> it’s not that important that admin users have to do 2 extra clicks to
> >> access them, and if we consider the App Panel as a favorite it’s
> acceptable.
> >>
> >
> > Regarding admins, some apps have some UIX code that mentions that the app
> > should be listed only for Admins, but that's another story.
> > If we were to create personalized favorites lists
> > http://jira.xwiki.org/browse/XWIKI-13770 than we will have a recommended
> > initial list that every user (including Admin) could customize (but this
> is
> > already an advanced / extended use case). User might not even know that
> > they can customize the AppBar (because we don't have an Edit/Customize
> > button for that panel and also the Application Panel section is inside
> the
> > Applications area, instead of being near the Look&Feel and Panel Wizard)
> > [but that's another story].
> >
> > Thanks,
> > Caty
> >
> >
> >>
> >> Thanks
> >> -Vincent
> >>
> >> > WDYT?
> >> >
> >> > Thanks,
> >> > Caty
> >> >
> >> >
> >> >>
> >> >> Thanks
> >> >> -Vincent
> >>
> >> _______________________________________________
> >> 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
>
6 Oct
6 Oct
5:30 p.m.
New subject: [xwiki-devs] [Proposal] Change of behavior for Applications Panel and app registration in general
The way I do this for another similar feature, using UIX objects, is to
add two new parameters, "enabled" and "order". When displaying the
extensions for a particular point, I request them ordered by the "order"
parameter, and then manually skip those for which the "enabled"
parameter is set to "false" -- if the parameter is missing, it's
considered enabled by default.
We can define that the order should have a value between 0 and 100, and
each extension can choose it's own relative number, as an expected
percentage, with the actual order depending on which other extensions
are installed and enabled, and their requested order.
As a more advanced feature, in PhenoTips we also have a wizard that
allows enabling/disabling and manually reordering extensions, by
modifying the extension parameters.
I didn't have time for this yet, but in the future I'd like to add
support for ordering and enable/disable flags in the core UIX module, so
that extensions are automatically filtered and ordered.
On 10/05/2016 05:37 AM, Vincent Massol wrote:
Hi devs,
With the recent introduction of the Applications Index (see
http://extensions.xwiki.org/xwiki/bin/view/Extension/Application+Index+Appl…) we
need to agree on a few things.
In the past we had:
* We wanted all new app that you installed to automatically be visible in the
Applications Panel
* This is why the Applications Panel config had a blacklist (and not a white list)
What we’ve done:
* We add the Applications Index
* We removed some apps from the Applications Panel. Namely: Invitation, Panels,
Scheduler, User Directory and Tour applications. this was done using hardcoded blacklist
xobjects in PanelsCode.ApplicationsPanelConfiguration.
The need:
* We need to remove this hack. It’s not normal for the Panels module to know all the apps
that shouldn’t be listed in it!
Proposal:
* Replace the blacklist configuration of the Applications Panel by a whitelist one
* When a new app is installed, list it in the Applications Index but don’t add it to the
Applications Panel
* If an admin wants to add this new for his users, he’ll need to add it in the Admin UI
for the Applications Panel.
WDYT?
Thanks
-Vincent
--
Sergiu Dumitriu
http://purl.org/net/sergiu
5:36 p.m.
New subject: [xwiki-devs] [Proposal] Change of behavior for Applications Panel and app registration in general
Hi Sergiu,
On 06 Oct 2016, at 17:30, Sergiu Dumitriu
<sergiu(a)xwiki.org> wrote:
The way I do this for another similar feature, using UIX objects, is to
add two new parameters, "enabled" and "order". When displaying the
extensions for a particular point, I request them ordered by the "order"
parameter, and then manually skip those for which the "enabled"
parameter is set to "false" -- if the parameter is missing, it's
considered enabled by default.
We can define that the order should have a value between 0 and 100, and
each extension can choose it's own relative number, as an expected
percentage, with the actual order depending on which other extensions
are installed and enabled, and their requested order.
Yes but IMO this wouldn’t work here for this use case because the information as to
whether a given app is displayed or not should not come from the UIX itself (the app
doesn’t know that info and shouldn’t set this). It should come from the admin or from the
flavor for this case at hand.
Also I don’t think that modifying the UIX of an app by the Application Panel admin UI is a
good thing. The storage if this info should go in the App Panel config page instead IMO.
WDYT?
Thanks
-Vincent
As a more advanced feature, in PhenoTips we also have
a wizard that
allows enabling/disabling and manually reordering extensions, by
modifying the extension parameters.
I didn't have time for this yet, but in the future I'd like to add
support for ordering and enable/disable flags in the core UIX module, so
that extensions are automatically filtered and ordered.
On 10/05/2016 05:37 AM, Vincent Massol wrote:
Hi devs,
With the recent introduction of the Applications Index (see
http://extensions.xwiki.org/xwiki/bin/view/Extension/Application+Index+Appl…) we
need to agree on a few things.
In the past we had:
* We wanted all new app that you installed to automatically be visible in the
Applications Panel
* This is why the Applications Panel config had a blacklist (and not a white list)
What we’ve done:
* We add the Applications Index
* We removed some apps from the Applications Panel. Namely: Invitation, Panels,
Scheduler, User Directory and Tour applications. this was done using hardcoded blacklist
xobjects in PanelsCode.ApplicationsPanelConfiguration.
The need:
* We need to remove this hack. It’s not normal for the Panels module to know all the apps
that shouldn’t be listed in it!
Proposal:
* Replace the blacklist configuration of the Applications Panel by a whitelist one
* When a new app is installed, list it in the Applications Index but don’t add it to the
Applications Panel
* If an admin wants to add this new for his users, he’ll need to add it in the Admin UI
for the Applications Panel.
WDYT?
Thanks
-Vincent
--
Sergiu Dumitriu
http://purl.org/net/sergiu
5:56 p.m.
New subject: [xwiki-devs] [Proposal] Change of behavior for Applications Panel and app registration in general
On 10/06/2016 11:36 AM, Vincent Massol wrote:
Hi Sergiu,
True, I was just presenting another approach, which, by the way, also
has limitations that are making me look for improvements.
I don't agree that the application shouldn't know whether it's suitable
for being displayed or not. Who knows that an extension is too technical
to be displayed? Certainly not the Panels application, and flavors can't
know beforehand all the extensions that may be installed. I think that
the application developers are the ones that should decide if their
application is to be displayed by default or not.
And these are just initial hints, the admins can then choose to change
the default and manually hide/show/reorder applications.
Now, for the fact that the parameters are stored *only* in the
extension, that does indeed cause several problems:
- modifying them may cause extension upgrade conflicts
- only one global setting, no user or space settings
- flavors can't override these settings
How about this: we define a way of overriding extension parameters using
custom objects:
XWiki.UIExtensionParameterOverridesClass
- extensionPointId
- name
- parameters
extensionPointId and name must match an UIX, and parameters override the
extension's parameters.
Depending on where the object it placed, it can be valid for:
- the whole wiki if placed in XWiki.XWikiPreferences
- a space if placed in <Space>.WebPreferences
- a certain user if placed in XWiki.<UserProfile>
- any other page, and have a way of telling the uix manager that we want
to apply the parameter overrides in that page
- not sure what to do for flavors, is XWiki.XWikiPreferences good, or is
there a flavor-specific configuration page?
How does that sound?
On 06 Oct 2016, at 17:30, Sergiu Dumitriu
<sergiu(a)xwiki.org> wrote:
The way I do this for another similar feature, using UIX objects, is to
add two new parameters, "enabled" and "order". When displaying the
extensions for a particular point, I request them ordered by the "order"
parameter, and then manually skip those for which the "enabled"
parameter is set to "false" -- if the parameter is missing, it's
considered enabled by default.
We can define that the order should have a value between 0 and 100, and
each extension can choose it's own relative number, as an expected
percentage, with the actual order depending on which other extensions
are installed and enabled, and their requested order.
Yes but IMO this wouldn’t work here for this use case because the information as to
whether a given app is displayed or not should not come from the UIX itself (the app
doesn’t know that info and shouldn’t set this). It should come from the admin or from the
flavor for this case at hand.
Also I don’t think that modifying the UIX of an app by the Application Panel admin UI is
a good thing. The storage if this info should go in the App Panel config page instead
IMO.
WDYT? Thanks
-Vincent
> As a more advanced feature, in PhenoTips we also have a wizard that
> allows enabling/disabling and manually reordering extensions, by
> modifying the extension parameters.
>
> I didn't have time for this yet, but in the future I'd like to add
> support for ordering and enable/disable flags in the core UIX module, so
> that extensions are automatically filtered and ordered.
>
> On 10/05/2016 05:37 AM, Vincent Massol wrote:
>> Hi devs,
>>
>> With the recent introduction of the Applications Index (see
http://extensions.xwiki.org/xwiki/bin/view/Extension/Application+Index+Appl…) we
need to agree on a few things.
>>
>> In the past we had:
>> * We wanted all new app that you installed to automatically be visible in the
Applications Panel
>> * This is why the Applications Panel config had a blacklist (and not a white
list)
>>
>> What we’ve done:
>> * We add the Applications Index
>> * We removed some apps from the Applications Panel. Namely: Invitation, Panels,
Scheduler, User Directory and Tour applications. this was done using hardcoded blacklist
xobjects in PanelsCode.ApplicationsPanelConfiguration.
>>
>> The need:
>> * We need to remove this hack. It’s not normal for the Panels module to know all
the apps that shouldn’t be listed in it!
>>
>> Proposal:
>> * Replace the blacklist configuration of the Applications Panel by a whitelist
one
>> * When a new app is installed, list it in the Applications Index but don’t add it
to the Applications Panel
>> * If an admin wants to add this new for his users, he’ll need to add it in the
Admin UI for the Applications Panel.
>>
>> WDYT?
>>
>> Thanks
>> -Vincent
>>
>
--
Sergiu Dumitriu
http://purl.org/net/sergiu
7 Oct
7 Oct
12:45 a.m.
New subject: [xwiki-devs] [Proposal] Change of behavior for Applications Panel and app registration in general
Guys, remember that we now have an Application Index, where you can browse
and discover all the relevant installed extensions. So this part of
responsibility should no longer be handled by the Apps Panel (since it
never was capable to do so anyway).
Applications will still have to provide either an UIX or a descriptor (with
name, icon and homepage), but IMO that should be targeting the Application
Index and not the App Panel. The Application Index will be the one going
through all applications and listing them. However, the App Panel should
only go through a list from the configuration (either set by the admin or
the current wiki, see my previous mention about per-user Apps Panels) and
only display the apps in that list.
I have 2 examples/analogies that I can think of when apps are automatically
added to your "desktop": on an operating system (i.e. windows, etc.; but
even there you have a checkbox in the installer to not do that) and in
Android OS (where the just installed app is added to one of your screens,
but can be removed). However, for an implementation solution, I find it
counterproductive/counterintuitive to have to manage a blacklist of *all*
the installed apps, except 2-3 that you want to be displayed, instead of
managing a whitelist with *only* the apps you want to see.
Going along these lines, I propose that, instead of automatically listing
all app UIXs and then have to blacklist, we try to find a way (listener?)
to just *add* an application to the whitelist automatically, when it is
installed, so that the admin can remove it if he does not want it there
(like removing a link from desktop or from you Android OS screens, but you
can still find the app in the App Index, later on).
P.S.: All this talk takes us back to the Application Descriptor topic that
we keep avoiding and keep trying to find quirky ways to work around it.
Thanks,
Eduard
On Thu, Oct 6, 2016 at 6:56 PM, Sergiu Dumitriu <sergiu(a)xwiki.org> wrote:
On 10/06/2016 11:36 AM, Vincent Massol wrote:
Hi Sergiu,
information as
to whether a given app is displayed or not should not come
from the UIX itself (the app doesn’t know that info and shouldn’t set
this). It should come from the admin or from the flavor for this case at
hand.
On 06 Oct 2016, at 17:30, Sergiu Dumitriu
<sergiu(a)xwiki.org> wrote:
The way I do this for another similar feature, using UIX objects, is to
add two new parameters, "enabled" and "order". When displaying the
extensions for a particular point, I request them ordered by the "order"
parameter, and then manually skip those for which the "enabled"
parameter is set to "false" -- if the parameter is missing, it's
considered enabled by default.
We can define that the order should have a value between 0 and 100, and
each extension can choose it's own relative number, as an expected
percentage, with the actual order depending on which other extensions
are installed and enabled, and their requested order.
Yes but IMO this wouldn’t work here for this use case because the
Also I don’t think that modifying the UIX of an app by the Application
Panel admin
UI is a good thing. The storage if this info should go in the
App Panel config page instead IMO.
WDYT?
True, I was just presenting another approach, which, by the way, also
has limitations that are making me look for improvements.
I don't agree that the application shouldn't know whether it's suitable
for being displayed or not. Who knows that an extension is too technical
to be displayed? Certainly not the Panels application, and flavors can't
know beforehand all the extensions that may be installed. I think that
the application developers are the ones that should decide if their
application is to be displayed by default or not.
And these are just initial hints, the admins can then choose to change
the default and manually hide/show/reorder applications.
Now, for the fact that the parameters are stored *only* in the
extension, that does indeed cause several problems:
- modifying them may cause extension upgrade conflicts
- only one global setting, no user or space settings
- flavors can't override these settings
How about this: we define a way of overriding extension parameters using
custom objects:
XWiki.UIExtensionParameterOverridesClass
- extensionPointId
- name
- parameters
extensionPointId and name must match an UIX, and parameters override the
extension's parameters.
Depending on where the object it placed, it can be valid for:
- the whole wiki if placed in XWiki.XWikiPreferences
- a space if placed in <Space>.WebPreferences
- a certain user if placed in XWiki.<UserProfile>
- any other page, and have a way of telling the uix manager that we want
to apply the parameter overrides in that page
- not sure what to do for flavors, is XWiki.XWikiPreferences good, or is
there a flavor-specific configuration page?
How does that sound?
Thanks
-Vincent
> As a more advanced feature, in PhenoTips we also have a wizard that
> allows enabling/disabling and manually reordering extensions, by
> modifying the extension parameters.
>
> I didn't have time for this yet, but in the future I'd like to add
> support for ordering and enable/disable flags in the core UIX module, so
> that extensions are automatically filtered and ordered.
>
> On 10/05/2016 05:37 AM, Vincent Massol wrote:
>> Hi devs,
>>
>> With the recent introduction of the Applications Index (see
http://extensions.xwiki.org/xwiki/bin/view/Extension/
Application+Index+Application/) we need to agree on a few things.
>>
>> In the past we had:
>> * We wanted all new app that you installed to automatically be visible
in
the Applications Panel
>> * This is why the Applications Panel
config had a blacklist (and not a
white list)
>>
>> What we’ve done:
>> * We add the Applications Index
>> * We removed some apps from the Applications Panel. Namely:
Invitation,
Panels, Scheduler, User Directory and Tour applications. this
was done using hardcoded blacklist xobjects in PanelsCode.
ApplicationsPanelConfiguration.
>>
>> The need:
>> * We need to remove this hack. It’s not normal for the Panels module
to
know all the apps that shouldn’t be listed in it!
>>
>> Proposal:
>> * Replace the blacklist configuration of the Applications Panel by a
whitelist one
>> * When a new app is installed, list it in
the Applications Index but
don’t add it to the Applications Panel
>> * If an admin wants to add this new for
his users, he’ll need to add
it in the Admin UI for the Applications Panel.
>>
>> WDYT?
>>
>> Thanks
>> -Vincent
>>
>
--
Sergiu Dumitriu
http://purl.org/net/sergiu
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
9:34 a.m.
New subject: [xwiki-devs] [Proposal] Change of behavior for Applications Panel and app registration in general
Hi Sergiu,
On 06 Oct 2016, at 17:56, Sergiu Dumitriu
<sergiu(a)xwiki.org> wrote:
On 10/06/2016 11:36 AM, Vincent Massol wrote:
I’ve never said the the app panel should know this. This would be definitely wrong.
Hi Sergiu,
True, I was just presenting another approach, which, by the way, also
has limitations that are making me look for improvements.
I don't agree that the application shouldn't know whether it's suitable
for being displayed or not. Who knows that an extension is too technical
to be displayed? Certainly not the Panels application, On 06 Oct 2016, at 17:30, Sergiu Dumitriu
<sergiu(a)xwiki.org> wrote:
The way I do this for another similar feature, using UIX objects, is to
add two new parameters, "enabled" and "order". When displaying the
extensions for a particular point, I request them ordered by the "order"
parameter, and then manually skip those for which the "enabled"
parameter is set to "false" -- if the parameter is missing, it's
considered enabled by default.
We can define that the order should have a value between 0 and 100, and
each extension can choose it's own relative number, as an expected
percentage, with the actual order depending on which other extensions
are installed and enabled, and their requested order.
Yes but IMO this wouldn’t work here for this use case because the information as to
whether a given app is displayed or not should not come from the UIX itself (the app
doesn’t know that info and shouldn’t set this). It should come from the admin or from the
flavor for this case at hand.
Also I don’t think that modifying the UIX of an app by the Application Panel admin UI is
a good thing. The storage if this info should go in the App Panel config page instead
IMO.
WDYT? and flavors can't
know beforehand all the extensions that may be installed.
I think there may be 2 different use cases. The one I was addressing mostly was the
**default** list of Apps that are visible in the App Panel.
For this I still believe that the Flavor should have the configuration and that the list
of apps visible by **default* don’t depend on the app themselves but depend on the
flavor.
I think that
the application developers are the ones that should decide if their
application is to be displayed by default or not.
I think you’re talking about edge cases where some apps really don’t want to be displayed
in the Panel. For me these apps should probably not even be apps. An example is an app
providing only a wiki macro. This app shouldn’t register as an app at all. And thus it
wouldn’t be displayed in the App Index or App Panel.
For all other apps, I’m personally fine that they appear in the App Panel for
discoverability. Others will contend that some shouldn’t appear. For example the Scheduler
app is an app that I had configured to appear in the App panel for Admins only. Caty
didn't agree for XE. But I’m sure she’d have agreed for a technical flavor where the
Scheduler app is key.
And these are just initial hints, the admins can then
choose to change
the default and manually hide/show/reorder applications.
Now, for the fact that the parameters are stored *only* in the
extension, that does indeed cause several problems:
- modifying them may cause extension upgrade conflicts
- only one global setting, no user or space settings
- flavors can't override these settings
How about this: we define a way of overriding extension parameters using
custom objects:
XWiki.UIExtensionParameterOverridesClass
- extensionPointId
- name
- parameters
extensionPointId and name must match an UIX, and parameters override the
extension's parameters.
Depending on where the object it placed, it can be valid for:
- the whole wiki if placed in XWiki.XWikiPreferences
- a space if placed in <Space>.WebPreferences
- a certain user if placed in XWiki.<UserProfile>
- any other page, and have a way of telling the uix manager that we want
to apply the parameter overrides in that page
- not sure what to do for flavors, is XWiki.XWikiPreferences good, or is
there a flavor-specific configuration page?
How does that sound?
At first sight, sounds complex to me. I don’t think we need this right now. For me we only
need an App Panel-level configuration that’s taken from the flavor.
FTR I’m also open to not adding new apps by default to the App Panel (Edy is also ok with
this) since for me that’s the role of the App Index. Now, I think the App Index could be
more visible (i.e I think we need to make it easier to navigate to various apps without
having to open the drawer, click on Apps Index and then find the app). I can think of
several ways:
* Add the link to the App Index from “More Applications”. Maybe a “All Applications”
label
* Rework the “More Applicatios” even more so that without clicking on “All Applications”
(just by moving the mouse over it) it opens a lightbox displaying all the apps.
* I’d also like to rework the Goto Page (Ctrl+G) to also add the ability to navigate to
apps more easily. Note that this one is not enough since it’s harder to discover.
Now I also agree that a whitelist is interesting (in addition to a blacklist) and that we
should offer the 2 configuration possibilities to users.
Thanks
-Vincent
Thanks
-Vincent
> As a more advanced feature, in PhenoTips we also have a wizard that
> allows enabling/disabling and manually reordering extensions, by
> modifying the extension parameters.
>
> I didn't have time for this yet, but in the future I'd like to add
> support for ordering and enable/disable flags in the core UIX module, so
> that extensions are automatically filtered and ordered.
>
> On 10/05/2016 05:37 AM, Vincent Massol wrote:
>> Hi devs,
>>
>> With the recent introduction of the Applications Index (see
http://extensions.xwiki.org/xwiki/bin/view/Extension/Application+Index+Appl…) we
need to agree on a few things.
>>
>> In the past we had:
>> * We wanted all new app that you installed to automatically be visible in the
Applications Panel
>> * This is why the Applications Panel config had a blacklist (and not a white
list)
>>
>> What we’ve done:
>> * We add the Applications Index
>> * We removed some apps from the Applications Panel. Namely: Invitation, Panels,
Scheduler, User Directory and Tour applications. this was done using hardcoded blacklist
xobjects in PanelsCode.ApplicationsPanelConfiguration.
>>
>> The need:
>> * We need to remove this hack. It’s not normal for the Panels module to know all
the apps that shouldn’t be listed in it!
>>
>> Proposal:
>> * Replace the blacklist configuration of the Applications Panel by a whitelist
one
>> * When a new app is installed, list it in the Applications Index but don’t add it
to the Applications Panel
>> * If an admin wants to add this new for his users, he’ll need to add it in the
Admin UI for the Applications Panel.
>>
>> WDYT?
>>
>> Thanks
>> -Vincent
>>
>
--
Sergiu Dumitriu
http://purl.org/net/sergiu
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs 
19 Oct
19 Oct
9:39 a.m.
New subject: [xwiki-devs] [Proposal] Change of behavior for Applications Panel and app registration in general
Hello.
I'm currently working on http://jira.xwiki.org/browse/XWIKI-13075 which is
on the roadmap for XWiki 8.4.
What I propose, is to save the order of the displayed apps in the page
"PanelsCode.ApplicationsPanelConfiguration", where the black list is
currently saved too.
So it won't add an "order" field to the UIX, and the UIX won't be
touched
when the order changes.
In the Panel Application, I must provide this page, because it hold a
"ConfigurableClass" XObject and a "DocumentSheetBinding" one.
However, I agree that the Panel Application should not decide which
applications are in the black list by default nor what is the order of the
apps. In my opinion, in the Panel app, the configuration should be provided
empty.
Indeed, it's the role of the flavor to provide a different configuration,
which also allows us to have different configurations according to the
different flavors.
Is it OK for you to let the flavor *overwrite* the default
"PanelsCode.ApplicationsPanelConfiguration" page, and let in the Panel
Application a default "PanelsCode.ApplicationsPanelConfiguration" page with
the configurable class but no configuration?
Is it OK from the EM point of view?
When I was in charge of a flavor for XWikiSAS, this mechanism used to work
but I had to commit http://jira.xwiki.org/browse/XWIKI-11777 to make it
work on the packager plugin too.
Note: the applications that are installed after and that do not have an
"order" in the configuration will be located *after* the applications that
have an order set in the configuration. We could decide to not show them by
default afterwards.
Thanks,
Guillaume
2016-10-07 9:34 GMT+02:00 Vincent Massol <vincent(a)massol.net>et>:
Hi Sergiu,
I’ve never said the the app panel should know this. This would be
definitely wrong.
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Guillaume Delhumeau (guillaume.delhumeau(a)xwiki.com)
Research & Development Engineer at XWiki SAS
Committer on the XWiki.org project
On 06 Oct 2016, at 17:56, Sergiu Dumitriu
<sergiu(a)xwiki.org> wrote:
On 10/06/2016 11:36 AM, Vincent Massol wrote:
> Hi Sergiu,
>
>> On 06 Oct 2016, at 17:30, Sergiu Dumitriu <sergiu(a)xwiki.org> wrote:
>>
>> The way I do this for another similar feature, using UIX objects, is to
>> add two new parameters, "enabled" and "order". When
displaying the
>> extensions for a particular point, I request them ordered by the
"order"
>> parameter, and then manually skip those
for which the "enabled"
>> parameter is set to "false" -- if the parameter is missing, it's
>> considered enabled by default.
>>
>> We can define that the order should have a value between 0 and 100, and
>> each extension can choose it's own relative number, as an expected
>> percentage, with the actual order depending on which other extensions
>> are installed and enabled, and their requested order.
>
> Yes but IMO this wouldn’t work here for this use case because the
information
as to whether a given app is displayed or not should not come
from the UIX itself (the app doesn’t know that info and shouldn’t set
this). It should come from the admin or from the flavor for this case at
hand.
>
> Also I don’t think that modifying the UIX of an app by the Application
Panel
admin UI is a good thing. The storage if this info should go in the
App Panel config page instead IMO.
WDYT?
True, I was just presenting another approach, which, by the way, also
has limitations that are making me look for improvements.
I don't agree that the application shouldn't know whether it's suitable
for being displayed or not. Who knows that an extension is too technical
to be displayed? Certainly not the Panels application, and flavors can't
know beforehand all the extensions that may be installed.
I think there may be 2 different use cases. The one I was addressing
mostly was the **default** list of Apps that are visible in the App Panel.
For this I still believe that the Flavor should have the configuration and
that the list of apps visible by **default* don’t depend on the app
themselves but depend on the flavor.
I think that
the application developers are the ones that should decide if their
application is to be displayed by default or not.
I think you’re talking about edge cases where some apps really don’t want
to be displayed in the Panel. For me these apps should probably not even be
apps. An example is an app providing only a wiki macro. This app shouldn’t
register as an app at all. And thus it wouldn’t be displayed in the App
Index or App Panel.
For all other apps, I’m personally fine that they appear in the App Panel
for discoverability. Others will contend that some shouldn’t appear. For
example the Scheduler app is an app that I had configured to appear in the
App panel for Admins only. Caty didn't agree for XE. But I’m sure she’d
have agreed for a technical flavor where the Scheduler app is key.
And these are just initial hints, the admins can
then choose to change
the default and manually hide/show/reorder applications.
Now, for the fact that the parameters are stored *only* in the
extension, that does indeed cause several problems:
- modifying them may cause extension upgrade conflicts
- only one global setting, no user or space settings
- flavors can't override these settings
How about this: we define a way of overriding extension parameters using
custom objects:
XWiki.UIExtensionParameterOverridesClass
- extensionPointId
- name
- parameters
extensionPointId and name must match an UIX, and parameters override the
extension's parameters.
Depending on where the object it placed, it can be valid for:
- the whole wiki if placed in XWiki.XWikiPreferences
- a space if placed in <Space>.WebPreferences
- a certain user if placed in XWiki.<UserProfile>
- any other page, and have a way of telling the uix manager that we want
to apply the parameter overrides in that page
- not sure what to do for flavors, is XWiki.XWikiPreferences good, or is
there a flavor-specific configuration page?
How does that sound?
At first sight, sounds complex to me. I don’t think we need this right
now. For me we only need an App Panel-level configuration that’s taken from
the flavor.
FTR I’m also open to not adding new apps by default to the App Panel (Edy
is also ok with this) since for me that’s the role of the App Index. Now, I
think the App Index could be more visible (i.e I think we need to make it
easier to navigate to various apps without having to open the drawer, click
on Apps Index and then find the app). I can think of several ways:
* Add the link to the App Index from “More Applications”. Maybe a “All
Applications” label
* Rework the “More Applicatios” even more so that without clicking on “All
Applications” (just by moving the mouse over it) it opens a lightbox
displaying all the apps.
* I’d also like to rework the Goto Page (Ctrl+G) to also add the ability
to navigate to apps more easily. Note that this one is not enough since
it’s harder to discover.
Now I also agree that a whitelist is interesting (in addition to a
blacklist) and that we should offer the 2 configuration possibilities to
users.
Thanks
-Vincent
> Thanks
> -Vincent
>
>> As a more advanced feature, in PhenoTips we also have a wizard that
>> allows enabling/disabling and manually reordering extensions, by
>> modifying the extension parameters.
>>
>> I didn't have time for this yet, but in the future I'd like to add
>> support for ordering and enable/disable flags in the core UIX module,
so
>> that extensions are automatically
filtered and ordered.
>>
>> On 10/05/2016 05:37 AM, Vincent Massol wrote:
>>> Hi devs,
>>>
>>> With the recent introduction of the Applications Index (see
http://extensions.xwiki.org/xwiki/bin/view/Extension/
Application+Index+Application/) we need to agree on a few things.
>>>
>>> In the past we had:
>>> * We wanted all new app that you installed to automatically be
visible
in the Applications Panel
>>> * This is why the Applications Panel
config had a blacklist (and not
a white list)
>>>
>>> What we’ve done:
>>> * We add the Applications Index
>>> * We removed some apps from the Applications Panel. Namely:
Invitation, Panels, Scheduler, User Directory and Tour applications. this
was done using hardcoded blacklist xobjects in PanelsCode.
ApplicationsPanelConfiguration.
>>>
>>> The need:
>>> * We need to remove this hack. It’s not normal for the Panels module
to know all the apps that shouldn’t be listed in it!
>>>
>>> Proposal:
>>> * Replace the blacklist configuration of the Applications Panel by a
whitelist one
>>> * When a new app is installed, list
it in the Applications Index but
don’t add it to the Applications Panel
>>> * If an admin wants to add this new
for his users, he’ll need to add
it in the Admin UI for the Applications Panel.
>>
>> WDYT?
>>
>> Thanks
>> -Vincent
>>
>
--
Sergiu Dumitriu
http://purl.org/net/sergiu
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs 
9:49 a.m.
New subject: [xwiki-devs] [Proposal] Change of behavior for Applications Panel and app registration in general
On Wed, Oct 19, 2016 at 9:39 AM, Guillaume Delhumeau
<guillaume.delhumeau(a)xwiki.com> wrote:
Hello.
I'm currently working on http://jira.xwiki.org/browse/XWIKI-13075 which is
on the roadmap for XWiki 8.4.
What I propose, is to save the order of the displayed apps in the page
"PanelsCode.ApplicationsPanelConfiguration", where the black list is
currently saved too.
So it won't add an "order" field to the UIX, and the UIX won't be
touched
when the order changes.
In the Panel Application, I must provide this page, because it hold a
"ConfigurableClass" XObject and a "DocumentSheetBinding" one.
However, I agree that the Panel Application should not decide which
applications are in the black list by default nor what is the order of the
apps. In my opinion, in the Panel app, the configuration should be provided
empty.
Indeed, it's the role of the flavor to provide a different configuration,
which also allows us to have different configurations according to the
different flavors.
Is it OK for you to let the flavor *overwrite* the default
"PanelsCode.ApplicationsPanelConfiguration" page, and let in the Panel
Application a default "PanelsCode.ApplicationsPanelConfiguration" page with
the configurable class but no configuration?
Is it OK from the EM point of view?
XAR extension handler has special support for pages overwritten in
some dependency so yes it's ok.
I'm not a big fan of extension providing modifiable configuration page
in the XAR, does not really help merging. But that's another matter.
When I was in charge of a flavor for XWikiSAS, this mechanism used to work
but I had to commit http://jira.xwiki.org/browse/XWIKI-11777 to make it
work on the packager plugin too.
Note: the applications that are installed after and that do not have an
"order" in the configuration will be located *after* the applications that
have an order set in the configuration. We could decide to not show them by
default afterwards.
It's better to have them displayed by default IMO. Then the admin can
decide to hide or reorder the applictation that has been installed.
Thanks,
Guillaume
2016-10-07 9:34 GMT+02:00 Vincent Massol <vincent(a)massol.net>et>:
--
Thomas Mortagne
Hi Sergiu,
I’ve never said the the app panel should know this. This would be
definitely wrong.
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Guillaume Delhumeau (guillaume.delhumeau(a)xwiki.com)
Research & Development Engineer at XWiki SAS
Committer on the XWiki.org project
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs On 06 Oct 2016, at 17:56, Sergiu Dumitriu
<sergiu(a)xwiki.org> wrote:
On 10/06/2016 11:36 AM, Vincent Massol wrote:
> Hi Sergiu,
>
>> On 06 Oct 2016, at 17:30, Sergiu Dumitriu <sergiu(a)xwiki.org> wrote:
>>
>> The way I do this for another similar feature, using UIX objects, is to
>> add two new parameters, "enabled" and "order". When
displaying the
>> extensions for a particular point, I request them ordered by the
"order"
>> parameter, and then manually skip those
for which the "enabled"
>> parameter is set to "false" -- if the parameter is missing, it's
>> considered enabled by default.
>>
>> We can define that the order should have a value between 0 and 100, and
>> each extension can choose it's own relative number, as an expected
>> percentage, with the actual order depending on which other extensions
>> are installed and enabled, and their requested order.
>
> Yes but IMO this wouldn’t work here for this use case because the
information
as to whether a given app is displayed or not should not come
from the UIX itself (the app doesn’t know that info and shouldn’t set
this). It should come from the admin or from the flavor for this case at
hand.
>
> Also I don’t think that modifying the UIX of an app by the Application
Panel
admin UI is a good thing. The storage if this info should go in the
App Panel config page instead IMO.
WDYT?
True, I was just presenting another approach, which, by the way, also
has limitations that are making me look for improvements.
I don't agree that the application shouldn't know whether it's suitable
for being displayed or not. Who knows that an extension is too technical
to be displayed? Certainly not the Panels application, and flavors can't
know beforehand all the extensions that may be installed.
I think there may be 2 different use cases. The one I was addressing
mostly was the **default** list of Apps that are visible in the App Panel.
For this I still believe that the Flavor should have the configuration and
that the list of apps visible by **default* don’t depend on the app
themselves but depend on the flavor.
I think that
the application developers are the ones that should decide if their
application is to be displayed by default or not.
I think you’re talking about edge cases where some apps really don’t want
to be displayed in the Panel. For me these apps should probably not even be
apps. An example is an app providing only a wiki macro. This app shouldn’t
register as an app at all. And thus it wouldn’t be displayed in the App
Index or App Panel.
For all other apps, I’m personally fine that they appear in the App Panel
for discoverability. Others will contend that some shouldn’t appear. For
example the Scheduler app is an app that I had configured to appear in the
App panel for Admins only. Caty didn't agree for XE. But I’m sure she’d
have agreed for a technical flavor where the Scheduler app is key.
And these are just initial hints, the admins can
then choose to change
the default and manually hide/show/reorder applications.
Now, for the fact that the parameters are stored *only* in the
extension, that does indeed cause several problems:
- modifying them may cause extension upgrade conflicts
- only one global setting, no user or space settings
- flavors can't override these settings
How about this: we define a way of overriding extension parameters using
custom objects:
XWiki.UIExtensionParameterOverridesClass
- extensionPointId
- name
- parameters
extensionPointId and name must match an UIX, and parameters override the
extension's parameters.
Depending on where the object it placed, it can be valid for:
- the whole wiki if placed in XWiki.XWikiPreferences
- a space if placed in <Space>.WebPreferences
- a certain user if placed in XWiki.<UserProfile>
- any other page, and have a way of telling the uix manager that we want
to apply the parameter overrides in that page
- not sure what to do for flavors, is XWiki.XWikiPreferences good, or is
there a flavor-specific configuration page?
How does that sound?
At first sight, sounds complex to me. I don’t think we need this right
now. For me we only need an App Panel-level configuration that’s taken from
the flavor.
FTR I’m also open to not adding new apps by default to the App Panel (Edy
is also ok with this) since for me that’s the role of the App Index. Now, I
think the App Index could be more visible (i.e I think we need to make it
easier to navigate to various apps without having to open the drawer, click
on Apps Index and then find the app). I can think of several ways:
* Add the link to the App Index from “More Applications”. Maybe a “All
Applications” label
* Rework the “More Applicatios” even more so that without clicking on “All
Applications” (just by moving the mouse over it) it opens a lightbox
displaying all the apps.
* I’d also like to rework the Goto Page (Ctrl+G) to also add the ability
to navigate to apps more easily. Note that this one is not enough since
it’s harder to discover.
Now I also agree that a whitelist is interesting (in addition to a
blacklist) and that we should offer the 2 configuration possibilities to
users.
Thanks
-Vincent
> Thanks
> -Vincent
>
>> As a more advanced feature, in PhenoTips we also have a wizard that
>> allows enabling/disabling and manually reordering extensions, by
>> modifying the extension parameters.
>>
>> I didn't have time for this yet, but in the future I'd like to add
>> support for ordering and enable/disable flags in the core UIX module,
so
>> that extensions are automatically
filtered and ordered.
>>
>> On 10/05/2016 05:37 AM, Vincent Massol wrote:
>>> Hi devs,
>>>
>>> With the recent introduction of the Applications Index (see
http://extensions.xwiki.org/xwiki/bin/view/Extension/
Application+Index+Application/) we need to agree on a few things.
>>>
>>> In the past we had:
>>> * We wanted all new app that you installed to automatically be
visible
in the Applications Panel
>>> * This is why the Applications Panel
config had a blacklist (and not
a white list)
>>>
>>> What we’ve done:
>>> * We add the Applications Index
>>> * We removed some apps from the Applications Panel. Namely:
Invitation, Panels, Scheduler, User Directory and Tour applications. this
was done using hardcoded blacklist xobjects in PanelsCode.
ApplicationsPanelConfiguration.
>>>
>>> The need:
>>> * We need to remove this hack. It’s not normal for the Panels module
to know all the apps that shouldn’t be listed in it!
>>>
>>> Proposal:
>>> * Replace the blacklist configuration of the Applications Panel by a
whitelist one
>>> * When a new app is installed, list
it in the Applications Index but
don’t add it to the Applications Panel
>>> * If an admin wants to add this new
for his users, he’ll need to add
it in the Admin UI for the Applications Panel.
>>
>> WDYT?
>>
>> Thanks
>> -Vincent
>>
>
--
Sergiu Dumitriu
http://purl.org/net/sergiu
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
10:27 a.m.
New subject: [xwiki-devs] [Proposal] Change of behavior for Applications Panel and app registration in general
Hi Guillaume,
On 19 Oct 2016, at 09:39, Guillaume Delhumeau
<guillaume.delhumeau(a)xwiki.com> wrote:
Hello.
I'm currently working on http://jira.xwiki.org/browse/XWIKI-13075 which is
on the roadmap for XWiki 8.4.
What I propose, is to save the order of the displayed apps in the page
"PanelsCode.ApplicationsPanelConfiguration", where the black list is
currently saved too.
So it won't add an "order" field to the UIX, and the UIX won't be
touched
when the order changes.
In the Panel Application, I must provide this page, because it hold a
"ConfigurableClass" XObject and a "DocumentSheetBinding" one.
However, I agree that the Panel Application should not decide which
applications are in the black list by default nor what is the order of the
apps. In my opinion, in the Panel app, the configuration should be provided
empty.
Indeed, it's the role of the flavor to provide a different configuration,
which also allows us to have different configurations according to the
different flavors.
Is it OK for you to let the flavor *overwrite* the default
"PanelsCode.ApplicationsPanelConfiguration" page, and let in the Panel
Application a default "PanelsCode.ApplicationsPanelConfiguration" page with
the configurable class but no configuration?
Is it OK from the EM point of view?
When I was in charge of a flavor for XWikiSAS, this mechanism used to work
but I had to commit http://jira.xwiki.org/browse/XWIKI-11777 to make it
work on the packager plugin too.
Note: the applications that are installed after and that do not have an
"order" in the configuration will be located *after* the applications that
have an order set in the configuration. We could decide to not show them by
default afterwards.
All this sounds good to me. One idea though:
* Don’t provide a PanelsCode.ApplicationsPanelConfiguration page by default. And at
execution time, if none exist have the Panel.Applications panel create one. In general I
think that extensions should not provide Config pages and that they should be created
dynamically with default values. The reason is that the user will configure them and if we
change the default value this generates merge conflicts. So better create the page
dynamically at first usage if it doesn’t exist.
* FTR I already do this in the Mail Sender app.
WDYT?
Thanks
-Vincent
Thanks,
Guillaume
2016-10-07 9:34 GMT+02:00 Vincent Massol <vincent(a)massol.net>et>:
> Hi Sergiu,
>
>> On 06 Oct 2016, at 17:56, Sergiu Dumitriu <sergiu(a)xwiki.org> wrote:
>>
>> On 10/06/2016 11:36 AM, Vincent Massol wrote:
>>> Hi Sergiu,
>>>
>>>> On 06 Oct 2016, at 17:30, Sergiu Dumitriu <sergiu(a)xwiki.org>
wrote:
>>>>
>>>> The way I do this for another similar feature, using UIX objects, is to
>>>> add two new parameters, "enabled" and "order". When
displaying the
>>>> extensions for a particular point, I request them ordered by the
> "order"
>>>> parameter, and then manually skip those for which the
"enabled"
>>>> parameter is set to "false" -- if the parameter is missing,
it's
>>>> considered enabled by default.
>>>>
>>>> We can define that the order should have a value between 0 and 100, and
>>>> each extension can choose it's own relative number, as an expected
>>>> percentage, with the actual order depending on which other extensions
>>>> are installed and enabled, and their requested order.
>>>
>>> Yes but IMO this wouldn’t work here for this use case because the
> information as to whether a given app is displayed or not should not come
> from the UIX itself (the app doesn’t know that info and shouldn’t set
> this). It should come from the admin or from the flavor for this case at
> hand.
>>>
>>> Also I don’t think that modifying the UIX of an app by the Application
> Panel admin UI is a good thing. The storage if this info should go in the
> App Panel config page instead IMO.
>>>
>>> WDYT?
>>
>> True, I was just presenting another approach, which, by the way, also
>> has limitations that are making me look for improvements.
>>
>> I don't agree that the application shouldn't know whether it's
suitable
>> for being displayed or not. Who knows that an extension is too technical
>> to be displayed? Certainly not the Panels application,
>
> I’ve never said the the app panel should know this. This would be
> definitely wrong.
>
>> and flavors can't
>> know beforehand all the extensions that may be installed.
>
> I think there may be 2 different use cases. The one I was addressing
> mostly was the **default** list of Apps that are visible in the App Panel.
>
> For this I still believe that the Flavor should have the configuration and
> that the list of apps visible by **default* don’t depend on the app
> themselves but depend on the flavor.
>
>> I think that
>> the application developers are the ones that should decide if their
>> application is to be displayed by default or not.
>
> I think you’re talking about edge cases where some apps really don’t want
> to be displayed in the Panel. For me these apps should probably not even be
> apps. An example is an app providing only a wiki macro. This app shouldn’t
> register as an app at all. And thus it wouldn’t be displayed in the App
> Index or App Panel.
>
> For all other apps, I’m personally fine that they appear in the App Panel
> for discoverability. Others will contend that some shouldn’t appear. For
> example the Scheduler app is an app that I had configured to appear in the
> App panel for Admins only. Caty didn't agree for XE. But I’m sure she’d
> have agreed for a technical flavor where the Scheduler app is key.
>
>> And these are just initial hints, the admins can then choose to change
>> the default and manually hide/show/reorder applications.
>>
>> Now, for the fact that the parameters are stored *only* in the
>> extension, that does indeed cause several problems:
>>
>> - modifying them may cause extension upgrade conflicts
>> - only one global setting, no user or space settings
>> - flavors can't override these settings
>>
>> How about this: we define a way of overriding extension parameters using
>> custom objects:
>>
>> XWiki.UIExtensionParameterOverridesClass
>> - extensionPointId
>> - name
>> - parameters
>>
>> extensionPointId and name must match an UIX, and parameters override the
>> extension's parameters.
>>
>> Depending on where the object it placed, it can be valid for:
>> - the whole wiki if placed in XWiki.XWikiPreferences
>> - a space if placed in <Space>.WebPreferences
>> - a certain user if placed in XWiki.<UserProfile>
>> - any other page, and have a way of telling the uix manager that we want
>> to apply the parameter overrides in that page
>> - not sure what to do for flavors, is XWiki.XWikiPreferences good, or is
>> there a flavor-specific configuration page?
>>
>> How does that sound?
>
> At first sight, sounds complex to me. I don’t think we need this right
> now. For me we only need an App Panel-level configuration that’s taken from
> the flavor.
>
> FTR I’m also open to not adding new apps by default to the App Panel (Edy
> is also ok with this) since for me that’s the role of the App Index. Now, I
> think the App Index could be more visible (i.e I think we need to make it
> easier to navigate to various apps without having to open the drawer, click
> on Apps Index and then find the app). I can think of several ways:
> * Add the link to the App Index from “More Applications”. Maybe a “All
> Applications” label
> * Rework the “More Applicatios” even more so that without clicking on “All
> Applications” (just by moving the mouse over it) it opens a lightbox
> displaying all the apps.
> * I’d also like to rework the Goto Page (Ctrl+G) to also add the ability
> to navigate to apps more easily. Note that this one is not enough since
> it’s harder to discover.
>
> Now I also agree that a whitelist is interesting (in addition to a
> blacklist) and that we should offer the 2 configuration possibilities to
> users.
>
> Thanks
> -Vincent
>>
>>> Thanks
>>> -Vincent
>>>
>>>> As a more advanced feature, in PhenoTips we also have a wizard that
>>>> allows enabling/disabling and manually reordering extensions, by
>>>> modifying the extension parameters.
>>>>
>>>> I didn't have time for this yet, but in the future I'd like to
add
>>>> support for ordering and enable/disable flags in the core UIX module,
> so
>>>> that extensions are automatically filtered and ordered.
>>>>
>>>> On 10/05/2016 05:37 AM, Vincent Massol wrote:
>>>>> Hi devs,
>>>>>
>>>>> With the recent introduction of the Applications Index (see
> http://extensions.xwiki.org/xwiki/bin/view/Extension/
> Application+Index+Application/) we need to agree on a few things.
>>>>>
>>>>> In the past we had:
>>>>> * We wanted all new app that you installed to automatically be
> visible in the Applications Panel
>>>>> * This is why the Applications Panel config had a blacklist (and not
> a white list)
>>>>>
>>>>> What we’ve done:
>>>>> * We add the Applications Index
>>>>> * We removed some apps from the Applications Panel. Namely:
> Invitation, Panels, Scheduler, User Directory and Tour applications. this
> was done using hardcoded blacklist xobjects in PanelsCode.
> ApplicationsPanelConfiguration.
>>>>>
>>>>> The need:
>>>>> * We need to remove this hack. It’s not normal for the Panels module
> to know all the apps that shouldn’t be listed in it!
>>>>>
>>>>> Proposal:
>>>>> * Replace the blacklist configuration of the Applications Panel by a
> whitelist one
>>>>> * When a new app is installed, list it in the Applications Index but
> don’t add it to the Applications Panel
>>>>> * If an admin wants to add this new for his users, he’ll need to add
> it in the Admin UI for the Applications Panel.
>>>>>
>>>>> WDYT?
>>>>>
>>>>> Thanks
>>>>> -Vincent
11:13 a.m.
New subject: [xwiki-devs] [Proposal] Change of behavior for Applications Panel and app registration in general
After talking directly with Vincent because I was badly thinking it was not
possible to have a configurable class on an other page than the
configuration, I am going to work in that direction.
Thanks,
2016-10-19 10:27 GMT+02:00 Vincent Massol <vincent(a)massol.net>et>:
Hi Guillaume,
--
Guillaume Delhumeau (guillaume.delhumeau(a)xwiki.com)
Research & Development Engineer at XWiki SAS
Committer on the XWiki.org project
On 19 Oct 2016, at 09:39, Guillaume Delhumeau
<
guillaume.delhumeau(a)xwiki.com> wrote:
Hello.
I'm currently working on http://jira.xwiki.org/browse/XWIKI-13075 which
is
on the roadmap for XWiki 8.4.
What I propose, is to save the order of the displayed apps in the page
"PanelsCode.ApplicationsPanelConfiguration", where the black list is
currently saved too.
So it won't add an "order" field to the UIX, and the UIX won't be
touched
when the order changes.
In the Panel Application, I must provide this page, because it hold a
"ConfigurableClass" XObject and a "DocumentSheetBinding" one.
However, I agree that the Panel Application should not decide which
applications are in the black list by default nor what is the order of
the
apps. In my opinion, in the Panel app, the
configuration should be
provided
empty.
Indeed, it's the role of the flavor to provide a different configuration,
which also allows us to have different configurations according to the
different flavors.
Is it OK for you to let the flavor *overwrite* the default
"PanelsCode.ApplicationsPanelConfiguration" page, and let in the Panel
Application a default "PanelsCode.ApplicationsPanelConfiguration" page
with
the configurable class but no configuration?
Is it OK from the EM point of view?
When I was in charge of a flavor for XWikiSAS, this mechanism used to
work
but I had to commit
http://jira.xwiki.org/browse/XWIKI-11777 to make it
work on the packager plugin too.
Note: the applications that are installed after and that do not have an
"order" in the configuration will be located *after* the applications
that
have an order set in the configuration. We could
decide to not show them
by
default afterwards.
All this sounds good to me. One idea though:
* Don’t provide a PanelsCode.ApplicationsPanelConfiguration page by
default. And at execution time, if none exist have the Panel.Applications
panel create one. In general I think that extensions should not provide
Config pages and that they should be created dynamically with default
values. The reason is that the user will configure them and if we change
the default value this generates merge conflicts. So better create the page
dynamically at first usage if it doesn’t exist.
* FTR I already do this in the Mail Sender app.
WDYT?
Thanks
-Vincent
Thanks,
Guillaume
2016-10-07 9:34 GMT+02:00 Vincent Massol <vincent(a)massol.net>et>:
> Hi Sergiu,
>
>> On 06 Oct 2016, at 17:56, Sergiu Dumitriu <sergiu(a)xwiki.org> wrote:
>>
>> On 10/06/2016 11:36 AM, Vincent Massol wrote:
>>> Hi Sergiu,
>>>
>>>> On 06 Oct 2016, at 17:30, Sergiu Dumitriu <sergiu(a)xwiki.org>
wrote:
>>>>
>>>> The way I do this for another similar feature, using UIX objects, is
to
>>>> add two new parameters,
"enabled" and "order". When displaying the
>>>> extensions for a particular point, I request them ordered by the
> "order"
>>>> parameter, and then manually skip those for which the
"enabled"
>>>> parameter is set to "false" -- if the parameter is missing,
it's
>>>> considered enabled by default.
>>>>
>>>> We can define that the order should have a value between 0 and 100,
and
>>>> each extension can choose
it's own relative number, as an expected
>>>> percentage, with the actual order depending on which other extensions
>>>> are installed and enabled, and their requested order.
>>>
>>> Yes but IMO this wouldn’t work here for this use case because the
> information as to whether a given app is displayed or not should not
come
> from the UIX itself (the app doesn’t know
that info and shouldn’t set
> this). It should come from the admin or from the flavor for this case at
> hand.
>>>
>>> Also I don’t think that modifying the UIX of an app by the Application
> Panel admin UI is a good thing. The storage if this info should go in
the
> App Panel config page instead IMO.
>>>
>>> WDYT?
>>
>> True, I was just presenting another approach, which, by the way, also
>> has limitations that are making me look for improvements.
>>
>> I don't agree that the application shouldn't know whether it's
suitable
>> for being displayed or not. Who knows that an extension is too
technical
>> to be displayed? Certainly not the Panels
application,
>
> I’ve never said the the app panel should know this. This would be
> definitely wrong.
>
>> and flavors can't
>> know beforehand all the extensions that may be installed.
>
> I think there may be 2 different use cases. The one I was addressing
> mostly was the **default** list of Apps that are visible in the App
Panel.
>
> For this I still believe that the Flavor should have the configuration
and
> that the list of apps visible by **default*
don’t depend on the app
> themselves but depend on the flavor.
>
>> I think that
>> the application developers are the ones that should decide if their
>> application is to be displayed by default or not.
>
> I think you’re talking about edge cases where some apps really don’t
want
> to be displayed in the Panel. For me these
apps should probably not
even be
> apps. An example is an app providing only a
wiki macro. This app
shouldn’t
> register as an app at all. And thus it
wouldn’t be displayed in the App
> Index or App Panel.
>
> For all other apps, I’m personally fine that they appear in the App
Panel
> for discoverability. Others will contend that
some shouldn’t appear. For
> example the Scheduler app is an app that I had configured to appear in
the
> App panel for Admins only. Caty didn't
agree for XE. But I’m sure she’d
> have agreed for a technical flavor where the Scheduler app is key.
>
>> And these are just initial hints, the admins can then choose to change
>> the default and manually hide/show/reorder applications.
>>
>> Now, for the fact that the parameters are stored *only* in the
>> extension, that does indeed cause several problems:
>>
>> - modifying them may cause extension upgrade conflicts
>> - only one global setting, no user or space settings
>> - flavors can't override these settings
>>
>> How about this: we define a way of overriding extension parameters
using
>> custom objects:
>>
>> XWiki.UIExtensionParameterOverridesClass
>> - extensionPointId
>> - name
>> - parameters
>>
>> extensionPointId and name must match an UIX, and parameters override
the
>> extension's parameters.
>>
>> Depending on where the object it placed, it can be valid for:
>> - the whole wiki if placed in XWiki.XWikiPreferences
>> - a space if placed in <Space>.WebPreferences
>> - a certain user if placed in XWiki.<UserProfile>
>> - any other page, and have a way of telling the uix manager that we
want
>> to apply the parameter overrides in that
page
>> - not sure what to do for flavors, is XWiki.XWikiPreferences good, or
is
>> there a flavor-specific configuration
page?
>>
>> How does that sound?
>
> At first sight, sounds complex to me. I don’t think we need this right
> now. For me we only need an App Panel-level configuration that’s taken
from
> the flavor.
>
> FTR I’m also open to not adding new apps by default to the App Panel
(Edy
> is also ok with this) since for me that’s the
role of the App Index.
Now, I
> think the App Index could be more visible
(i.e I think we need to make
it
> easier to navigate to various apps without
having to open the drawer,
click
> on Apps Index and then find the app). I can
think of several ways:
> * Add the link to the App Index from “More Applications”. Maybe a “All
> Applications” label
> * Rework the “More Applicatios” even more so that without clicking on
“All
> Applications” (just by moving the mouse over
it) it opens a lightbox
> displaying all the apps.
> * I’d also like to rework the Goto Page (Ctrl+G) to also add the ability
> to navigate to apps more easily. Note that this one is not enough since
> it’s harder to discover.
>
> Now I also agree that a whitelist is interesting (in addition to a
> blacklist) and that we should offer the 2 configuration possibilities to
> users.
>
> Thanks
> -Vincent
>>
>>> Thanks
>>> -Vincent
>>>
>>>> As a more advanced feature, in PhenoTips we also have a wizard that
>>>> allows enabling/disabling and manually reordering extensions, by
>>>> modifying the extension parameters.
>>>>
>>>> I didn't have time for this yet, but in the future I'd like to
add
>>>> support for ordering and enable/disable flags in the core UIX module,
> so
>>>> that extensions are automatically filtered and ordered.
>>>>
>>>> On 10/05/2016 05:37 AM, Vincent Massol wrote:
>>>>> Hi devs,
>>>>>
>>>>> With the recent introduction of the Applications Index (see
> http://extensions.xwiki.org/xwiki/bin/view/Extension/
> Application+Index+Application/) we need to agree on a few things.
>>>>>
>>>>> In the past we had:
>>>>> * We wanted all new app that you installed to automatically be
> visible in the Applications Panel
>>>>> * This is why the Applications Panel config had a blacklist (and not
> a white list)
>>>>>
>>>>> What we’ve done:
>>>>> * We add the Applications Index
>>>>> * We removed some apps from the Applications Panel. Namely:
> Invitation, Panels, Scheduler, User Directory and Tour applications.
this
> was done using hardcoded blacklist xobjects
in PanelsCode.
> ApplicationsPanelConfiguration.
>>>>>
>>>>> The need:
>>>>> * We need to remove this hack. It’s not normal for the Panels module
> to know all the apps that shouldn’t be listed in it!
>>>>>
>>>>> Proposal:
>>>>> * Replace the blacklist configuration of the Applications Panel by a
> whitelist one
>>>>> * When a new app is installed, list it in the Applications Index but
> don’t add it to the Applications Panel
>>>>> * If an admin wants to add this new for his users, he’ll need to add
> it in the Admin UI for the Applications Panel.
>>>>>
>>>>> WDYT?
>>>>>
>>>>> Thanks
>>>>> -Vincent
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
11:19 a.m.
New subject: [xwiki-devs] [Proposal] Change of behavior for Applications Panel and app registration in general
On 19 Oct 2016, at 10:27, Vincent Massol
<vincent(a)massol.net> wrote:
Hi Guillaume,
Or provide such a page but with no config xobject.
Thanks
-Vincent
On 19 Oct 2016, at 09:39, Guillaume Delhumeau
<guillaume.delhumeau(a)xwiki.com> wrote:
Hello.
I'm currently working on http://jira.xwiki.org/browse/XWIKI-13075 which is
on the roadmap for XWiki 8.4.
What I propose, is to save the order of the displayed apps in the page
"PanelsCode.ApplicationsPanelConfiguration", where the black list is
currently saved too.
So it won't add an "order" field to the UIX, and the UIX won't be
touched
when the order changes.
In the Panel Application, I must provide this page, because it hold a
"ConfigurableClass" XObject and a "DocumentSheetBinding" one.
However, I agree that the Panel Application should not decide which
applications are in the black list by default nor what is the order of the
apps. In my opinion, in the Panel app, the configuration should be provided
empty.
Indeed, it's the role of the flavor to provide a different configuration,
which also allows us to have different configurations according to the
different flavors.
Is it OK for you to let the flavor *overwrite* the default
"PanelsCode.ApplicationsPanelConfiguration" page, and let in the Panel
Application a default "PanelsCode.ApplicationsPanelConfiguration" page with
the configurable class but no configuration?
Is it OK from the EM point of view?
When I was in charge of a flavor for XWikiSAS, this mechanism used to work
but I had to commit http://jira.xwiki.org/browse/XWIKI-11777 to make it
work on the packager plugin too.
Note: the applications that are installed after and that do not have an
"order" in the configuration will be located *after* the applications that
have an order set in the configuration. We could decide to not show them by
default afterwards.
All this sounds good to me. One idea though:
* Don’t provide a PanelsCode.ApplicationsPanelConfiguration page by default. And at execution time, if none exist have the
Panel.Applications panel create one. In general I think that extensions should not provide
Config pages and that they should be created dynamically with default values. The reason
is that the user will configure them and if we change the default value this generates
merge conflicts. So better create the page dynamically at first usage if it doesn’t
exist.
* FTR I already do this in the Mail Sender app.
WDYT?
Thanks
-Vincent
Thanks,
Guillaume
2016-10-07 9:34 GMT+02:00 Vincent Massol <vincent(a)massol.net>et>:
> Hi Sergiu,
>
>> On 06 Oct 2016, at 17:56, Sergiu Dumitriu <sergiu(a)xwiki.org> wrote:
>>
>> On 10/06/2016 11:36 AM, Vincent Massol wrote:
>>> Hi Sergiu,
>>>
>>>> On 06 Oct 2016, at 17:30, Sergiu Dumitriu <sergiu(a)xwiki.org>
wrote:
>>>>
>>>> The way I do this for another similar feature, using UIX objects, is to
>>>> add two new parameters, "enabled" and "order". When
displaying the
>>>> extensions for a particular point, I request them ordered by the
> "order"
>>>> parameter, and then manually skip those for which the
"enabled"
>>>> parameter is set to "false" -- if the parameter is missing,
it's
>>>> considered enabled by default.
>>>>
>>>> We can define that the order should have a value between 0 and 100, and
>>>> each extension can choose it's own relative number, as an expected
>>>> percentage, with the actual order depending on which other extensions
>>>> are installed and enabled, and their requested order.
>>>
>>> Yes but IMO this wouldn’t work here for this use case because the
> information as to whether a given app is displayed or not should not come
> from the UIX itself (the app doesn’t know that info and shouldn’t set
> this). It should come from the admin or from the flavor for this case at
> hand.
>>>
>>> Also I don’t think that modifying the UIX of an app by the Application
> Panel admin UI is a good thing. The storage if this info should go in the
> App Panel config page instead IMO.
>>>
>>> WDYT?
>>
>> True, I was just presenting another approach, which, by the way, also
>> has limitations that are making me look for improvements.
>>
>> I don't agree that the application shouldn't know whether it's
suitable
>> for being displayed or not. Who knows that an extension is too technical
>> to be displayed? Certainly not the Panels application,
>
> I’ve never said the the app panel should know this. This would be
> definitely wrong.
>
>> and flavors can't
>> know beforehand all the extensions that may be installed.
>
> I think there may be 2 different use cases. The one I was addressing
> mostly was the **default** list of Apps that are visible in the App Panel.
>
> For this I still believe that the Flavor should have the configuration and
> that the list of apps visible by **default* don’t depend on the app
> themselves but depend on the flavor.
>
>> I think that
>> the application developers are the ones that should decide if their
>> application is to be displayed by default or not.
>
> I think you’re talking about edge cases where some apps really don’t want
> to be displayed in the Panel. For me these apps should probably not even be
> apps. An example is an app providing only a wiki macro. This app shouldn’t
> register as an app at all. And thus it wouldn’t be displayed in the App
> Index or App Panel.
>
> For all other apps, I’m personally fine that they appear in the App Panel
> for discoverability. Others will contend that some shouldn’t appear. For
> example the Scheduler app is an app that I had configured to appear in the
> App panel for Admins only. Caty didn't agree for XE. But I’m sure she’d
> have agreed for a technical flavor where the Scheduler app is key.
>
>> And these are just initial hints, the admins can then choose to change
>> the default and manually hide/show/reorder applications.
>>
>> Now, for the fact that the parameters are stored *only* in the
>> extension, that does indeed cause several problems:
>>
>> - modifying them may cause extension upgrade conflicts
>> - only one global setting, no user or space settings
>> - flavors can't override these settings
>>
>> How about this: we define a way of overriding extension parameters using
>> custom objects:
>>
>> XWiki.UIExtensionParameterOverridesClass
>> - extensionPointId
>> - name
>> - parameters
>>
>> extensionPointId and name must match an UIX, and parameters override the
>> extension's parameters.
>>
>> Depending on where the object it placed, it can be valid for:
>> - the whole wiki if placed in XWiki.XWikiPreferences
>> - a space if placed in <Space>.WebPreferences
>> - a certain user if placed in XWiki.<UserProfile>
>> - any other page, and have a way of telling the uix manager that we want
>> to apply the parameter overrides in that page
>> - not sure what to do for flavors, is XWiki.XWikiPreferences good, or is
>> there a flavor-specific configuration page?
>>
>> How does that sound?
>
> At first sight, sounds complex to me. I don’t think we need this right
> now. For me we only need an App Panel-level configuration that’s taken from
> the flavor.
>
> FTR I’m also open to not adding new apps by default to the App Panel (Edy
> is also ok with this) since for me that’s the role of the App Index. Now, I
> think the App Index could be more visible (i.e I think we need to make it
> easier to navigate to various apps without having to open the drawer, click
> on Apps Index and then find the app). I can think of several ways:
> * Add the link to the App Index from “More Applications”. Maybe a “All
> Applications” label
> * Rework the “More Applicatios” even more so that without clicking on “All
> Applications” (just by moving the mouse over it) it opens a lightbox
> displaying all the apps.
> * I’d also like to rework the Goto Page (Ctrl+G) to also add the ability
> to navigate to apps more easily. Note that this one is not enough since
> it’s harder to discover.
>
> Now I also agree that a whitelist is interesting (in addition to a
> blacklist) and that we should offer the 2 configuration possibilities to
> users.
>
> Thanks
> -Vincent
>>
>>> Thanks
>>> -Vincent
>>>
>>>> As a more advanced feature, in PhenoTips we also have a wizard that
>>>> allows enabling/disabling and manually reordering extensions, by
>>>> modifying the extension parameters.
>>>>
>>>> I didn't have time for this yet, but in the future I'd like to
add
>>>> support for ordering and enable/disable flags in the core UIX module,
> so
>>>> that extensions are automatically filtered and ordered.
>>>>
>>>> On 10/05/2016 05:37 AM, Vincent Massol wrote:
>>>>> Hi devs,
>>>>>
>>>>> With the recent introduction of the Applications Index (see
> http://extensions.xwiki.org/xwiki/bin/view/Extension/
> Application+Index+Application/) we need to agree on a few things.
>>>>>
>>>>> In the past we had:
>>>>> * We wanted all new app that you installed to automatically be
> visible in the Applications Panel
>>>>> * This is why the Applications Panel config had a blacklist (and not
> a white list)
>>>>>
>>>>> What we’ve done:
>>>>> * We add the Applications Index
>>>>> * We removed some apps from the Applications Panel. Namely:
> Invitation, Panels, Scheduler, User Directory and Tour applications. this
> was done using hardcoded blacklist xobjects in PanelsCode.
> ApplicationsPanelConfiguration.
>>>>>
>>>>> The need:
>>>>> * We need to remove this hack. It’s not normal for the Panels module
> to know all the apps that shouldn’t be listed in it!
>>>>>
>>>>> Proposal:
>>>>> * Replace the blacklist configuration of the Applications Panel by a
> whitelist one
>>>>> * When a new app is installed, list it in the Applications Index but
> don’t add it to the Applications Panel
>>>>> * If an admin wants to add this new for his users, he’ll need to add
> it in the Admin UI for the Applications Panel.
>>>>>
>>>>> WDYT?
>>>>>
>>>>> Thanks
>>>>> -Vincent
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
11:28 a.m.
New subject: [xwiki-devs] [Proposal] Change of behavior for Applications Panel and app registration in general
Related issue: http://jira.xwiki.org/browse/XWIKI-13814
2016-10-19 11:19 GMT+02:00 Vincent Massol <vincent(a)massol.net>et>:
default.
Or provide such a page but with no config xobject.
Thanks
-Vincent
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Guillaume Delhumeau (guillaume.delhumeau(a)xwiki.com)
Research & Development Engineer at XWiki SAS
Committer on the XWiki.org project
On 19 Oct 2016, at 10:27, Vincent Massol
<vincent(a)massol.net> wrote:
Hi Guillaume,
> On 19 Oct 2016, at 09:39, Guillaume Delhumeau <
guillaume.delhumeau(a)xwiki.com> wrote:
>
> Hello.
>
> I'm currently working on http://jira.xwiki.org/browse/XWIKI-13075
which
is
> on the roadmap for XWiki 8.4.
>
> What I propose, is to save the order of the displayed apps in the page
> "PanelsCode.ApplicationsPanelConfiguration", where the black list is
> currently saved too.
>
> So it won't add an "order" field to the UIX, and the UIX won't be
touched
> when the order changes.
>
> In the Panel Application, I must provide this page, because it hold a
> "ConfigurableClass" XObject and a "DocumentSheetBinding" one.
>
> However, I agree that the Panel Application should not decide which
> applications are in the black list by default nor what is the order of
the
> apps. In my opinion, in the Panel app, the
configuration should be
provided
> empty.
>
> Indeed, it's the role of the flavor to provide a different
configuration,
> which also allows us to have different
configurations according to the
> different flavors.
>
> Is it OK for you to let the flavor *overwrite* the default
> "PanelsCode.ApplicationsPanelConfiguration" page, and let in the Panel
> Application a default "PanelsCode.ApplicationsPanelConfiguration" page
with
> the configurable class but no configuration?
>
> Is it OK from the EM point of view?
>
> When I was in charge of a flavor for XWikiSAS, this mechanism used to
work
> but I had to commit
http://jira.xwiki.org/browse/XWIKI-11777 to make it
> work on the packager plugin too.
>
> Note: the applications that are installed after and that do not have an
> "order" in the configuration will be located *after* the applications
that
> have an order set in the configuration. We
could decide to not show
them by
default
afterwards.
All this sounds good to me. One idea though:
* Don’t provide a PanelsCode.ApplicationsPanelConfiguration page by And at execution time, if none exist have the
Panel.Applications panel
create one. In general I think that extensions should not
provide Config
pages and that they should be created dynamically with default values. The
reason is that the user will configure them and if we change the default
value this generates merge conflicts. So better create the page dynamically
at first usage if it doesn’t exist.
* FTR I already do this in the Mail Sender app.
WDYT?
Thanks
-Vincent
>
> Thanks,
>
> Guillaume
>
>
> 2016-10-07 9:34 GMT+02:00 Vincent Massol <vincent(a)massol.net>et>:
>
>> Hi Sergiu,
>>
>>> On 06 Oct 2016, at 17:56, Sergiu Dumitriu <sergiu(a)xwiki.org> wrote:
>>>
>>> On 10/06/2016 11:36 AM, Vincent Massol wrote:
>>>> Hi Sergiu,
>>>>
>>>>> On 06 Oct 2016, at 17:30, Sergiu Dumitriu <sergiu(a)xwiki.org>
wrote:
>>>>>
>>>>> The way I do this for another similar feature, using UIX objects,
is to
>>>>> add two new parameters,
"enabled" and "order". When displaying the
>>>>> extensions for a particular point, I request them ordered by the
>> "order"
>>>>> parameter, and then manually skip those for which the
"enabled"
>>>>> parameter is set to "false" -- if the parameter is missing,
it's
>>>>> considered enabled by default.
>>>>>
>>>>> We can define that the order should have a value between 0 and 100,
and
>>>>> each extension can choose
it's own relative number, as an expected
>>>>> percentage, with the actual order depending on which other
extensions
>>>>> are installed and enabled,
and their requested order.
>>>>
>>>> Yes but IMO this wouldn’t work here for this use case because the
>> information as to whether a given app is displayed or not should not
come
>> from the UIX itself (the app doesn’t know
that info and shouldn’t set
>> this). It should come from the admin or from the flavor for this case
at
>> hand.
>>>>
>>>> Also I don’t think that modifying the UIX of an app by the
Application
>> Panel admin UI is a good thing. The
storage if this info should go in
the
>> App Panel config page instead IMO.
>>>>
>>>> WDYT?
>>>
>>> True, I was just presenting another approach, which, by the way, also
>>> has limitations that are making me look for improvements.
>>>
>>> I don't agree that the application shouldn't know whether it's
suitable
>>> for being displayed or not. Who knows
that an extension is too
technical
>>> to be displayed? Certainly not the
Panels application,
>>
>> I’ve never said the the app panel should know this. This would be
>> definitely wrong.
>>
>>> and flavors can't
>>> know beforehand all the extensions that may be installed.
>>
>> I think there may be 2 different use cases. The one I was addressing
>> mostly was the **default** list of Apps that are visible in the App
Panel.
>>
>> For this I still believe that the Flavor should have the configuration
and
>> that the list of apps visible by
**default* don’t depend on the app
>> themselves but depend on the flavor.
>>
>>> I think that
>>> the application developers are the ones that should decide if their
>>> application is to be displayed by default or not.
>>
>> I think you’re talking about edge cases where some apps really don’t
want
>> to be displayed in the Panel. For me
these apps should probably not
even be
>> apps. An example is an app providing only
a wiki macro. This app
shouldn’t
>> register as an app at all. And thus it
wouldn’t be displayed in the App
>> Index or App Panel.
>>
>> For all other apps, I’m personally fine that they appear in the App
Panel
>> for discoverability. Others will contend
that some shouldn’t appear.
For
>> example the Scheduler app is an app that
I had configured to appear in
the
>> App panel for Admins only. Caty
didn't agree for XE. But I’m sure she’d
>> have agreed for a technical flavor where the Scheduler app is key.
>>
>>> And these are just initial hints, the admins can then choose to change
>>> the default and manually hide/show/reorder applications.
>>>
>>> Now, for the fact that the parameters are stored *only* in the
>>> extension, that does indeed cause several problems:
>>>
>>> - modifying them may cause extension upgrade conflicts
>>> - only one global setting, no user or space settings
>>> - flavors can't override these settings
>>>
>>> How about this: we define a way of overriding extension parameters
using
>>> custom objects:
>>>
>>> XWiki.UIExtensionParameterOverridesClass
>>> - extensionPointId
>>> - name
>>> - parameters
>>>
>>> extensionPointId and name must match an UIX, and parameters override
the
>>> extension's parameters.
>>>
>>> Depending on where the object it placed, it can be valid for:
>>> - the whole wiki if placed in XWiki.XWikiPreferences
>>> - a space if placed in <Space>.WebPreferences
>>> - a certain user if placed in XWiki.<UserProfile>
>>> - any other page, and have a way of telling the uix manager that we
want
>>> to apply the parameter overrides in
that page
>>> - not sure what to do for flavors, is XWiki.XWikiPreferences good, or
is
>>> there a flavor-specific configuration
page?
>>>
>>> How does that sound?
>>
>> At first sight, sounds complex to me. I don’t think we need this right
>> now. For me we only need an App Panel-level configuration that’s taken
from
>> the flavor.
>>
>> FTR I’m also open to not adding new apps by default to the App Panel
(Edy
>> is also ok with this) since for me that’s
the role of the App Index.
Now, I
>> think the App Index could be more visible
(i.e I think we need to make
it
>> easier to navigate to various apps
without having to open the drawer,
click
>> on Apps Index and then find the app). I
can think of several ways:
>> * Add the link to the App Index from “More Applications”. Maybe a “All
>> Applications” label
>> * Rework the “More Applicatios” even more so that without clicking on
“All
>> Applications” (just by moving the mouse
over it) it opens a lightbox
>> displaying all the apps.
>> * I’d also like to rework the Goto Page (Ctrl+G) to also add the
ability
>> to navigate to apps more easily. Note
that this one is not enough since
>> it’s harder to discover.
>>
>> Now I also agree that a whitelist is interesting (in addition to a
>> blacklist) and that we should offer the 2 configuration possibilities
to
>> users.
>>
>> Thanks
>> -Vincent
>>>
>>>> Thanks
>>>> -Vincent
>>>>
>>>>> As a more advanced feature, in PhenoTips we also have a wizard that
>>>>> allows enabling/disabling and manually reordering extensions, by
>>>>> modifying the extension parameters.
>>>>>
>>>>> I didn't have time for this yet, but in the future I'd like
to add
>>>>> support for ordering and enable/disable flags in the core UIX
module,
>> so
>>>>> that extensions are automatically filtered and ordered.
>>>>>
>>>>> On 10/05/2016 05:37 AM, Vincent Massol wrote:
>>>>>> Hi devs,
>>>>>>
>>>>>> With the recent introduction of the Applications Index (see
>> http://extensions.xwiki.org/xwiki/bin/view/Extension/
>> Application+Index+Application/) we need to agree on a few things.
>>>>>>
>>>>>> In the past we had:
>>>>>> * We wanted all new app that you installed to automatically be
>> visible in the Applications Panel
>>>>>> * This is why the Applications Panel config had a blacklist (and
not
>> a white list)
>>>>>>
>>>>>> What we’ve done:
>>>>>> * We add the Applications Index
>>>>>> * We removed some apps from the Applications Panel. Namely:
>> Invitation, Panels, Scheduler, User Directory and Tour applications.
this
>> was done using hardcoded blacklist
xobjects in PanelsCode.
>> ApplicationsPanelConfiguration.
>>>>>>
>>>>>> The need:
>>>>>> * We need to remove this hack. It’s not normal for the Panels
module
>> to know all the apps that shouldn’t be
listed in it!
>>>>>>
>>>>>> Proposal:
>>>>>> * Replace the blacklist configuration of the Applications Panel
by
a
>> whitelist one
>>>>>> * When a new app is installed, list it in the Applications Index
but
>> don’t add it to the Applications Panel
>>>>>> * If an admin wants to add this new for his users, he’ll need to
add
> it in
the Admin UI for the Applications Panel.
>>>>>
>>>>> WDYT?
>>>>>
>>>>> Thanks
>>>>> -Vincent
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
2889
days inactive
2903
days old
16 comments
6 participants
participants (6)
-
Ecaterina Moraru (Valica) -
Eduard Moraru -
Guillaume Delhumeau -
Sergiu Dumitriu -
Thomas Mortagne -
Vincent Massol