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 _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
