Re: [xwiki-devs] [Proposal] Change of behavior for Applications Panel and app registration in general

[Guillaume Delhumeau]

Related issue: http://jira.xwiki.org/browse/XWIKI-13814

2016-10-19 11:19 GMT+02:00 Vincent Massol :

>
> > On 19 Oct 2016, at 10:27, Vincent Massol  wrote:
> >
> > Hi Guillaume,
> >
> >> On 19 Oct 2016, at 09:39, Guillaume Delhumeau <
> guillaume.delhum...@xwiki.com> wrote:
> >>
> >> Hello.
> >>
> >> I'm currently working on http://jira.xwiki.org/browse/XWIKI-13075
> which is
> >> on the roadmap for XWiki 8.4.
> >>
> >> What I propose, is to save the order of the displayed apps in the page
> >> "PanelsCode.ApplicationsPanelConfiguration", where the black list is
> >> currently saved too.
> >>
> >> So it won't add an "order" field to the UIX, and the UIX won't be
> touched
> >> when the order changes.
> >>
> >> In the Panel Application, I must provide this page, because it hold a
> >> "ConfigurableClass" XObject and a "DocumentSheetBinding" one.
> >>
> >> However, I agree that the Panel Application should not decide which
> >> applications are in the black list by default nor what is the order of
> the
> >> apps. In my opinion, in the Panel app, the configuration should be
> provided
> >> empty.
> >>
> >> Indeed, it's the role of the flavor to provide a different
> configuration,
> >> which also allows us to have different configurations according to the
> >> different flavors.
> >>
> >> Is it OK for you to let the flavor *overwrite* the default
> >> "PanelsCode.ApplicationsPanelConfiguration" page, and let in the Panel
> >> Application a default "PanelsCode.ApplicationsPanelConfiguration" page
> with
> >> the configurable class but no configuration?
> >>
> >> Is it OK from the EM point of view?
> >>
> >> When I was in charge of a flavor for XWikiSAS, this mechanism used to
> work
> >> but I had to commit http://jira.xwiki.org/browse/XWIKI-11777 to make it
> >> work on the packager plugin too.
> >>
> >> Note: the applications that are installed after and that do not have an
> >> "order" in the configuration will be located *after* the applications
> that
> >> have an order set in the configuration. We could decide to not show
> them by
> >> default afterwards.
> >
> > All this sounds good to me. One idea though:
> > * Don’t provide a PanelsCode.ApplicationsPanelConfiguration page by
> default.
>
> 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 :
> >>
> >>> Hi Sergiu,
> >>>
>  On 06 Oct 2016, at 17:56, Sergiu Dumitriu  wrote:
> 
>  On 10/06/2016 11:36 AM, Vincent Massol wrote:
> > Hi Sergiu,
> >
> >> On 06 Oct 2016, at 17:30, Sergiu Dumitriu  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 

Re: [xwiki-devs] [Proposal] Change of behavior for Applications Panel and app registration in general

[Vincent Massol]

> On 19 Oct 2016, at 10:27, Vincent Massol  wrote:
> 
> Hi Guillaume,
> 
>> On 19 Oct 2016, at 09:39, Guillaume Delhumeau 
>>  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 :
>> 
>>> Hi Sergiu,
>>> 
 On 06 Oct 2016, at 17:56, Sergiu Dumitriu  wrote:
 
 On 10/06/2016 11:36 AM, Vincent Massol wrote:
> Hi Sergiu,
> 
>> On 06 Oct 2016, at 17:30, Sergiu Dumitriu  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 

Re: [xwiki-devs] [Proposal] Change of behavior for Applications Panel and app registration in general

[Guillaume Delhumeau]

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 :

> Hi Guillaume,
>
> > On 19 Oct 2016, at 09:39, Guillaume Delhumeau <
> guillaume.delhum...@xwiki.com> wrote:
> >
> > Hello.
> >
> > I'm currently working on http://jira.xwiki.org/browse/XWIKI-13075 which
> is
> > on the roadmap for XWiki 8.4.
> >
> > What I propose, is to save the order of the displayed apps in the page
> > "PanelsCode.ApplicationsPanelConfiguration", where the black list is
> > currently saved too.
> >
> > So it won't add an "order" field to the UIX, and the UIX won't be touched
> > when the order changes.
> >
> > In the Panel Application, I must provide this page, because it hold a
> > "ConfigurableClass" XObject and a "DocumentSheetBinding" one.
> >
> > However, I agree that the Panel Application should not decide which
> > applications are in the black list by default nor what is the order of
> the
> > apps. In my opinion, in the Panel app, the configuration should be
> provided
> > empty.
> >
> > Indeed, it's the role of the flavor to provide a different configuration,
> > which also allows us to have different configurations according to the
> > different flavors.
> >
> > Is it OK for you to let the flavor *overwrite* the default
> > "PanelsCode.ApplicationsPanelConfiguration" page, and let in the Panel
> > Application a default "PanelsCode.ApplicationsPanelConfiguration" page
> with
> > the configurable class but no configuration?
> >
> > Is it OK from the EM point of view?
> >
> > When I was in charge of a flavor for XWikiSAS, this mechanism used to
> work
> > but I had to commit http://jira.xwiki.org/browse/XWIKI-11777 to make it
> > work on the packager plugin too.
> >
> > Note: the applications that are installed after and that do not have an
> > "order" in the configuration will be located *after* the applications
> that
> > have an order set in the configuration. We could decide to not show them
> by
> > default afterwards.
>
> All this sounds good to me. One idea though:
> * Don’t provide a PanelsCode.ApplicationsPanelConfiguration page by
> default. And at execution time, if none exist have the Panel.Applications
> panel create one. In general I think that extensions should not provide
> Config pages and that they should be created dynamically with default
> values. The reason is that the user will configure them and if we change
> the default value this generates merge conflicts. So better create the page
> dynamically at first usage if it doesn’t exist.
> * FTR I already do this in the Mail Sender app.
>
> WDYT?
>
> Thanks
> -Vincent
>
> >
> > Thanks,
> >
> > Guillaume
> >
> >
> > 2016-10-07 9:34 GMT+02:00 Vincent Massol :
> >
> >> Hi Sergiu,
> >>
> >>> On 06 Oct 2016, at 17:56, Sergiu Dumitriu  wrote:
> >>>
> >>> On 10/06/2016 11:36 AM, Vincent Massol wrote:
>  Hi Sergiu,
> 
> > On 06 Oct 2016, at 17:30, Sergiu Dumitriu  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 

Re: [xwiki-devs] [Proposal] Change of behavior for Applications Panel and app registration in general

[Vincent Massol]

Hi Guillaume,

> On 19 Oct 2016, at 09:39, Guillaume Delhumeau  
> 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 :
> 
>> Hi Sergiu,
>> 
>>> On 06 Oct 2016, at 17:56, Sergiu Dumitriu  wrote:
>>> 
>>> On 10/06/2016 11:36 AM, Vincent Massol wrote:
 Hi Sergiu,
 
> On 06 Oct 2016, at 17:30, Sergiu Dumitriu  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 

Re: [xwiki-devs] [Proposal] Change of behavior for Applications Panel and app registration in general

[Thomas Mortagne]

On Wed, Oct 19, 2016 at 9:39 AM, Guillaume Delhumeau
 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 :
>
>> Hi Sergiu,
>>
>> > On 06 Oct 2016, at 17:56, Sergiu Dumitriu  wrote:
>> >
>> > On 10/06/2016 11:36 AM, Vincent Massol wrote:
>> >> Hi Sergiu,
>> >>
>> >>> On 06 Oct 2016, at 17:30, Sergiu Dumitriu  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 

Re: [xwiki-devs] [Proposal] Change of behavior for Applications Panel and app registration in general

[Guillaume Delhumeau]

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 :

> Hi Sergiu,
>
> > On 06 Oct 2016, at 17:56, Sergiu Dumitriu  wrote:
> >
> > On 10/06/2016 11:36 AM, Vincent Massol wrote:
> >> Hi Sergiu,
> >>
> >>> On 06 Oct 2016, at 17:30, Sergiu Dumitriu  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 

Re: [xwiki-devs] [Proposal] Change of behavior for Applications Panel and app registration in general

[Vincent Massol]

Hi Sergiu,

> On 06 Oct 2016, at 17:56, Sergiu Dumitriu  wrote:
> 
> On 10/06/2016 11:36 AM, Vincent Massol wrote:
>> Hi Sergiu,
>> 
>>> On 06 Oct 2016, at 17:30, Sergiu Dumitriu  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 .WebPreferences
> - a certain user if placed in XWiki.
> - 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 

Re: [xwiki-devs] [Proposal] Change of behavior for Applications Panel and app registration in general

[Eduard Moraru]

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  wrote:

> On 10/06/2016 11:36 AM, Vincent Massol wrote:
> > Hi Sergiu,
> >
> >> On 06 Oct 2016, at 17:30, Sergiu Dumitriu  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 .WebPreferences
> - a certain user if placed in XWiki.
> - 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 

Re: [xwiki-devs] [Proposal] Change of behavior for Applications Panel and app registration in general

[Sergiu Dumitriu]

On 10/06/2016 11:36 AM, Vincent Massol wrote:
> Hi Sergiu,
> 
>> On 06 Oct 2016, at 17:30, Sergiu Dumitriu  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 .WebPreferences
- a certain user if placed in XWiki.
- any other page, and have a way of telling the uix manager that we want
to apply the parameter overrides in that page
- not sure what to do for flavors, is XWiki.XWikiPreferences good, or is
there a flavor-specific configuration page?

How does that sound?

> Thanks
> -Vincent
> 
>> As a more advanced feature, in PhenoTips we also have a wizard that
>> allows enabling/disabling and manually reordering extensions, by
>> modifying the extension parameters.
>>
>> I didn't have time for this yet, but in the future I'd like to add
>> support for ordering and enable/disable flags in the core UIX module, so
>> that extensions are automatically filtered and ordered.
>>
>> On 10/05/2016 05:37 AM, Vincent Massol wrote:
>>> Hi devs,
>>>
>>> With the recent introduction of the Applications Index (see 
>>> http://extensions.xwiki.org/xwiki/bin/view/Extension/Application+Index+Application/)
>>>  we need to agree on a few things.
>>>
>>> In the past we had:
>>> * We wanted all new app that you installed to automatically be visible in 
>>> the Applications Panel
>>> * This is why the Applications Panel config had a blacklist (and not a 
>>> white list)
>>>
>>> What we’ve done:
>>> * We add the Applications Index
>>> * We removed some apps from the Applications Panel. Namely: Invitation, 
>>> Panels, Scheduler, User Directory and Tour applications. this was done 
>>> using hardcoded blacklist xobjects in 
>>> PanelsCode.ApplicationsPanelConfiguration.
>>>
>>> The need:
>>> * We need to remove this hack. It’s not normal for the Panels module to 
>>> know all the apps that shouldn’t be listed in it!
>>>
>>> Proposal:
>>> * Replace the blacklist configuration of the Applications Panel by a 
>>> whitelist one
>>> * When a new app is installed, list it in the Applications Index but don’t 
>>> add it to the Applications Panel
>>> * If an admin wants to add this new for his users, he’ll need to add it in 
>>> the Admin UI for the Applications Panel.
>>>
>>> WDYT?
>>>
>>> Thanks
>>> -Vincent
>>>
>>

-- 
Sergiu Dumitriu
http://purl.org/net/sergiu
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

Re: [xwiki-devs] [Proposal] Change of behavior for Applications Panel and app registration in general

[Vincent Massol]

Hi Sergiu,

> On 06 Oct 2016, at 17:30, Sergiu Dumitriu  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+Application/)
>>  we need to agree on a few things.
>> 
>> In the past we had:
>> * We wanted all new app that you installed to automatically be visible in 
>> the Applications Panel
>> * This is why the Applications Panel config had a blacklist (and not a white 
>> list)
>> 
>> What we’ve done:
>> * We add the Applications Index
>> * We removed some apps from the Applications Panel. Namely: Invitation, 
>> Panels, Scheduler, User Directory and Tour applications. this was done using 
>> hardcoded blacklist xobjects in PanelsCode.ApplicationsPanelConfiguration.
>> 
>> The need:
>> * We need to remove this hack. It’s not normal for the Panels module to know 
>> all the apps that shouldn’t be listed in it!
>> 
>> Proposal:
>> * Replace the blacklist configuration of the Applications Panel by a 
>> whitelist one
>> * When a new app is installed, list it in the Applications Index but don’t 
>> add it to the Applications Panel
>> * If an admin wants to add this new for his users, he’ll need to add it in 
>> the Admin UI for the Applications Panel.
>> 
>> WDYT?
>> 
>> Thanks
>> -Vincent
>> 
> 
> 
> -- 
> Sergiu Dumitriu
> http://purl.org/net/sergiu
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

Re: [xwiki-devs] [Proposal] Change of behavior for Applications Panel and app registration in general

[Sergiu Dumitriu]

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+Application/)
>  we need to agree on a few things.
> 
> In the past we had:
> * We wanted all new app that you installed to automatically be visible in the 
> Applications Panel
> * This is why the Applications Panel config had a blacklist (and not a white 
> list)
> 
> What we’ve done:
> * We add the Applications Index
> * We removed some apps from the Applications Panel. Namely: Invitation, 
> Panels, Scheduler, User Directory and Tour applications. this was done using 
> hardcoded blacklist xobjects in PanelsCode.ApplicationsPanelConfiguration.
> 
> The need:
> * We need to remove this hack. It’s not normal for the Panels module to know 
> all the apps that shouldn’t be listed in it!
> 
> Proposal:
> * Replace the blacklist configuration of the Applications Panel by a 
> whitelist one
> * When a new app is installed, list it in the Applications Index but don’t 
> add it to the Applications Panel
> * If an admin wants to add this new for his users, he’ll need to add it in 
> the Admin UI for the Applications Panel.
> 
> WDYT?
> 
> Thanks
> -Vincent
> 


-- 
Sergiu Dumitriu
http://purl.org/net/sergiu
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

Re: [xwiki-devs] [Proposal] Change of behavior for Applications Panel and app registration in general

[Eduard Moraru]

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)  wrote:

> On Wed, Oct 5, 2016 at 5:47 PM, Ecaterina Moraru (Valica) <
> vali...@gmail.com
> > wrote:
>
> >
> >
> > On Wed, Oct 5, 2016 at 1:35 PM, Vincent Massol 
> wrote:
> >
> >>
> >> > On 05 Oct 2016, at 12:08, Ecaterina Moraru (Valica) <
> vali...@gmail.com>
> >> wrote:
> >> >
> >> > On Wed, Oct 5, 2016 at 12:37 PM, 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)
> >> >>
> >> >
> >> > 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 

Re: [xwiki-devs] [Proposal] Change of behavior for Applications Panel and app registration in general

[Ecaterina Moraru (Valica)]

On Wed, Oct 5, 2016 at 1:35 PM, Vincent Massol  wrote:

>
> > On 05 Oct 2016, at 12:08, Ecaterina Moraru (Valica) 
> wrote:
> >
> > On Wed, Oct 5, 2016 at 12:37 PM, 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)
> >>
> >
> > 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

Re: [xwiki-devs] [Proposal] Change of behavior for Applications Panel and app registration in general

[Ecaterina Moraru (Valica)]

On Wed, Oct 5, 2016 at 5:47 PM, Ecaterina Moraru (Valica)  wrote:

>
>
> On Wed, Oct 5, 2016 at 1:35 PM, Vincent Massol  wrote:
>
>>
>> > On 05 Oct 2016, at 12:08, Ecaterina Moraru (Valica) 
>> wrote:
>> >
>> > On Wed, Oct 5, 2016 at 12:37 PM, 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)
>> >>
>> >
>> > 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 

Re: [xwiki-devs] [Proposal] Change of behavior for Applications Panel and app registration in general

[Vincent Massol]

> On 05 Oct 2016, at 12:08, Ecaterina Moraru (Valica)  wrote:
> 
> On Wed, Oct 5, 2016 at 12:37 PM, 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)
>> 
> 
> 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 

Re: [xwiki-devs] [Proposal] Change of behavior for Applications Panel and app registration in general

[Ecaterina Moraru (Valica)]

On Wed, Oct 5, 2016 at 12:37 PM, 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)
>

There are some nice side effects of the current behavior that I would not
want to lose:
A. after you install an app with the EM, it immediately appears (if it has
the UIX defined) in the AppBar and is ready for usage. The admin does not
need to do the second step manually. We save him a click (in practice is
more than a click).
B. after you create a new app with AWM, you automatically have it in the
AppBar. In theory that app should be useful for the user, since he manually
create it to his own liking. We are saving him a click+.

The only problem is when the wiki is getting out of control, too many apps,
no favorite order, just alphabetical. For this there is this issue
http://jira.xwiki.org/browse/XWIKI-13075


>
> What we’ve done:
> * We add the Applications Index
>
* We removed some apps from the Applications Panel. Namely: Invitation,
> Panels, Scheduler, User Directory and Tour applications. this was done
> using hardcoded blacklist xobjects in PanelsCode.
> ApplicationsPanelConfiguration.
>
> The need:
> * We need to remove this hack. It’s not normal for the Panels module to
> know all the apps that shouldn’t be listed in it!
>

So the main problem is that currently the AppBar is defined in Panels
module, instead of the Application module. This is known and we also have
an issue for the move, see http://jira.xwiki.org/browse/XWIKI-13502 , we
just didn't had the time to do it.


>
> Proposal:
> * Replace the blacklist configuration of the Applications Panel by a
> whitelist one
> * When a new app is installed, list it in the Applications Index but don’t
> add it to the Applications Panel
> * If an admin wants to add this new for his users, he’ll need to add it in
> the Admin UI for the Applications Panel.
>
> WDYT?
>

I'm not sure I like this very much :)

IMO the main problem is that we are using the "Add Application" UIX
http://platform.xwiki.org/xwiki/bin/view/ExtensionPoint/AddApplicationUIX
to define applications.
For me, ideally, we would have a separate mechanism to define an app (not
this UIX). Application Index would display all the XARs that contain an app
descritor, while the AppBar would list the apps that have the UIX.

The problem with the AppBar and the blacklisting appeared when we added the
UIX to applications that were not "user-oriented", not useful in the daily
flow, not needed for fast navigation prioritization, but that contained the
UIX since we added this step to our recommended development app practices.
Ideally the UIX should be added to applications intended for normal users
that need a fast access point in the AppBar.

Having it as a white list, will reduce the user-centered applications
discoverability and rapid access.

WDYT?

Thanks,
Caty


>
> Thanks
> -Vincent
>
> ___
> devs mailing list
> devs@xwiki.org
> http://lists.xwiki.org/mailman/listinfo/devs
>
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

[xwiki-devs] [Proposal] Change of behavior for Applications Panel and app registration in general

[Vincent Massol]

Hi devs,

With the recent introduction of the Applications Index (see 
http://extensions.xwiki.org/xwiki/bin/view/Extension/Application+Index+Application/)
 we need to agree on a few things.

In the past we had:
* We wanted all new app that you installed to automatically be visible in the 
Applications Panel
* This is why the Applications Panel config had a blacklist (and not a white 
list)

What we’ve done:
* We add the Applications Index
* We removed some apps from the Applications Panel. Namely: Invitation, Panels, 
Scheduler, User Directory and Tour applications. this was done using hardcoded 
blacklist xobjects in PanelsCode.ApplicationsPanelConfiguration.

The need:
* We need to remove this hack. It’s not normal for the Panels module to know 
all the apps that shouldn’t be listed in it!

Proposal:
* Replace the blacklist configuration of the Applications Panel by a whitelist 
one
* When a new app is installed, list it in the Applications Index but don’t add 
it to the Applications Panel
* If an admin wants to add this new for his users, he’ll need to add it in the 
Admin UI for the Applications Panel.

WDYT?

Thanks
-Vincent

___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs