[xwiki-devs] [Proposal] Change of behavior for Applications Panel and app registration in general
Hi devs, With the recent introduction of the Applications Index (see http://extensions.xwiki.org/xwiki/bin/view/Extension/Application+Index+Appli...) 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
On Wed, Oct 5, 2016 at 12:37 PM, Vincent Massol <[email protected]> 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 [email protected] http://lists.xwiki.org/mailman/listinfo/devs
On 05 Oct 2016, at 12:08, Ecaterina Moraru (Valica) <[email protected]> wrote:
On Wed, Oct 5, 2016 at 12:37 PM, Vincent Massol <[email protected]> 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.
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?
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.
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. Thanks -Vincent
WDYT?
Thanks, Caty
Thanks -Vincent
On Wed, Oct 5, 2016 at 1:35 PM, Vincent Massol <[email protected]> wrote:
On 05 Oct 2016, at 12:08, Ecaterina Moraru (Valica) <[email protected]> wrote:
On Wed, Oct 5, 2016 at 12:37 PM, Vincent Massol <[email protected]> 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.
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/ 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.
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 [email protected] http://lists.xwiki.org/mailman/listinfo/devs
On Wed, Oct 5, 2016 at 5:47 PM, Ecaterina Moraru (Valica) <[email protected]
wrote:
On Wed, Oct 5, 2016 at 1:35 PM, Vincent Massol <[email protected]> wrote:
On 05 Oct 2016, at 12:08, Ecaterina Moraru (Valica) <[email protected]> wrote:
On Wed, Oct 5, 2016 at 12:37 PM, Vincent Massol <[email protected]> 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 [email protected] http://lists.xwiki.org/mailman/listinfo/devs
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) <[email protected]
wrote:
On Wed, Oct 5, 2016 at 5:47 PM, Ecaterina Moraru (Valica) < [email protected]
wrote:
On Wed, Oct 5, 2016 at 1:35 PM, Vincent Massol <[email protected]>
wrote:
On 05 Oct 2016, at 12:08, Ecaterina Moraru (Valica) <
wrote:
On Wed, Oct 5, 2016 at 12:37 PM, Vincent Massol <[email protected]>
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 [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
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+Appli...) 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
Hi Sergiu,
On 06 Oct 2016, at 17:30, Sergiu Dumitriu <[email protected]> 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+Appli...) 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
On 10/06/2016 11:36 AM, Vincent Massol wrote:
Hi Sergiu,
On 06 Oct 2016, at 17:30, Sergiu Dumitriu <[email protected]> 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 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+Appli...) 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
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 <[email protected]> wrote:
On 10/06/2016 11:36 AM, Vincent Massol wrote:
Hi Sergiu,
On 06 Oct 2016, at 17:30, Sergiu Dumitriu <[email protected]> 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 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 [email protected] http://lists.xwiki.org/mailman/listinfo/devs
Hi Sergiu,
On 06 Oct 2016, at 17:56, Sergiu Dumitriu <[email protected]> wrote:
On 10/06/2016 11:36 AM, Vincent Massol wrote:
Hi Sergiu,
On 06 Oct 2016, at 17:30, Sergiu Dumitriu <[email protected]> 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+Appli...) 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 [email protected] http://lists.xwiki.org/mailman/listinfo/devs
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 <[email protected]>:
Hi Sergiu,
On 06 Oct 2016, at 17:56, Sergiu Dumitriu <[email protected]> wrote:
On 10/06/2016 11:36 AM, Vincent Massol wrote:
Hi Sergiu,
On 06 Oct 2016, at 17:30, Sergiu Dumitriu <[email protected]> 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
-- Sergiu Dumitriu http://purl.org/net/sergiu _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Guillaume Delhumeau ([email protected]) Research & Development Engineer at XWiki SAS Committer on the XWiki.org project
On Wed, Oct 19, 2016 at 9:39 AM, Guillaume Delhumeau <[email protected]> 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 <[email protected]>:
Hi Sergiu,
On 06 Oct 2016, at 17:56, Sergiu Dumitriu <[email protected]> wrote:
On 10/06/2016 11:36 AM, Vincent Massol wrote:
Hi Sergiu,
On 06 Oct 2016, at 17:30, Sergiu Dumitriu <[email protected]> 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
-- Sergiu Dumitriu http://purl.org/net/sergiu _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Guillaume Delhumeau ([email protected]) Research & Development Engineer at XWiki SAS Committer on the XWiki.org project _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne
Hi Guillaume,
On 19 Oct 2016, at 09:39, Guillaume Delhumeau <[email protected]> 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 <[email protected]>:
Hi Sergiu,
On 06 Oct 2016, at 17:56, Sergiu Dumitriu <[email protected]> wrote:
On 10/06/2016 11:36 AM, Vincent Massol wrote:
Hi Sergiu,
On 06 Oct 2016, at 17:30, Sergiu Dumitriu <[email protected]> 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
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 <[email protected]>:
Hi Guillaume,
On 19 Oct 2016, at 09:39, Guillaume Delhumeau < [email protected]> 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 <[email protected]>:
Hi Sergiu,
On 06 Oct 2016, at 17:56, Sergiu Dumitriu <[email protected]> wrote:
On 10/06/2016 11:36 AM, Vincent Massol wrote:
Hi Sergiu,
On 06 Oct 2016, at 17:30, Sergiu Dumitriu <[email protected]> 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 [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Guillaume Delhumeau ([email protected]) Research & Development Engineer at XWiki SAS Committer on the XWiki.org project
On 19 Oct 2016, at 10:27, Vincent Massol <[email protected]> wrote:
Hi Guillaume,
On 19 Oct 2016, at 09:39, Guillaume Delhumeau <[email protected]> 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.
Or provide such a page but with no config xobject. Thanks -Vincent
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 <[email protected]>:
Hi Sergiu,
On 06 Oct 2016, at 17:56, Sergiu Dumitriu <[email protected]> wrote:
On 10/06/2016 11:36 AM, Vincent Massol wrote:
Hi Sergiu,
On 06 Oct 2016, at 17:30, Sergiu Dumitriu <[email protected]> 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 [email protected] http://lists.xwiki.org/mailman/listinfo/devs
Related issue: http://jira.xwiki.org/browse/XWIKI-13814 2016-10-19 11:19 GMT+02:00 Vincent Massol <[email protected]>:
On 19 Oct 2016, at 10:27, Vincent Massol <[email protected]> wrote:
Hi Guillaume,
On 19 Oct 2016, at 09:39, Guillaume Delhumeau < [email protected]> 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.
Or provide such a page but with no config xobject.
Thanks -Vincent
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 <[email protected]>:
Hi Sergiu,
On 06 Oct 2016, at 17:56, Sergiu Dumitriu <[email protected]> wrote:
On 10/06/2016 11:36 AM, Vincent Massol wrote:
Hi Sergiu,
> On 06 Oct 2016, at 17:30, Sergiu Dumitriu <[email protected]> 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 [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Guillaume Delhumeau ([email protected]) Research & Development Engineer at XWiki SAS Committer on the XWiki.org project
participants (6)
-
Ecaterina Moraru (Valica) -
Eduard Moraru -
Guillaume Delhumeau -
Sergiu Dumitriu -
Thomas Mortagne -
Vincent Massol