> 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
