After talking directly with Vincent because I was badly thinking it was not possible to have a configurable class on an other page than the configuration, I am going to work in that direction.
Thanks, 2016-10-19 10:27 GMT+02:00 Vincent Massol <[email protected]>: > Hi Guillaume, > > > On 19 Oct 2016, at 09:39, Guillaume Delhumeau < > [email protected]> wrote: > > > > Hello. > > > > I'm currently working on http://jira.xwiki.org/browse/XWIKI-13075 which > is > > on the roadmap for XWiki 8.4. > > > > What I propose, is to save the order of the displayed apps in the page > > "PanelsCode.ApplicationsPanelConfiguration", where the black list is > > currently saved too. > > > > So it won't add an "order" field to the UIX, and the UIX won't be touched > > when the order changes. > > > > In the Panel Application, I must provide this page, because it hold a > > "ConfigurableClass" XObject and a "DocumentSheetBinding" one. > > > > However, I agree that the Panel Application should not decide which > > applications are in the black list by default nor what is the order of > the > > apps. In my opinion, in the Panel app, the configuration should be > provided > > empty. > > > > Indeed, it's the role of the flavor to provide a different configuration, > > which also allows us to have different configurations according to the > > different flavors. > > > > Is it OK for you to let the flavor *overwrite* the default > > "PanelsCode.ApplicationsPanelConfiguration" page, and let in the Panel > > Application a default "PanelsCode.ApplicationsPanelConfiguration" page > with > > the configurable class but no configuration? > > > > Is it OK from the EM point of view? > > > > When I was in charge of a flavor for XWikiSAS, this mechanism used to > work > > but I had to commit http://jira.xwiki.org/browse/XWIKI-11777 to make it > > work on the packager plugin too. > > > > Note: the applications that are installed after and that do not have an > > "order" in the configuration will be located *after* the applications > that > > have an order set in the configuration. We could decide to not show them > by > > default afterwards. > > All this sounds good to me. One idea though: > * Don’t provide a PanelsCode.ApplicationsPanelConfiguration page by > default. And at execution time, if none exist have the Panel.Applications > panel create one. In general I think that extensions should not provide > Config pages and that they should be created dynamically with default > values. The reason is that the user will configure them and if we change > the default value this generates merge conflicts. So better create the page > dynamically at first usage if it doesn’t exist. > * FTR I already do this in the Mail Sender app. > > WDYT? > > Thanks > -Vincent > > > > > Thanks, > > > > Guillaume > > > > > > 2016-10-07 9:34 GMT+02:00 Vincent Massol <[email protected]>: > > > >> Hi Sergiu, > >> > >>> On 06 Oct 2016, at 17:56, Sergiu Dumitriu <[email protected]> wrote: > >>> > >>> On 10/06/2016 11:36 AM, Vincent Massol wrote: > >>>> Hi Sergiu, > >>>> > >>>>> On 06 Oct 2016, at 17:30, Sergiu Dumitriu <[email protected]> wrote: > >>>>> > >>>>> The way I do this for another similar feature, using UIX objects, is > to > >>>>> add two new parameters, "enabled" and "order". When displaying the > >>>>> extensions for a particular point, I request them ordered by the > >> "order" > >>>>> parameter, and then manually skip those for which the "enabled" > >>>>> parameter is set to "false" -- if the parameter is missing, it's > >>>>> considered enabled by default. > >>>>> > >>>>> We can define that the order should have a value between 0 and 100, > and > >>>>> each extension can choose it's own relative number, as an expected > >>>>> percentage, with the actual order depending on which other extensions > >>>>> are installed and enabled, and their requested order. > >>>> > >>>> Yes but IMO this wouldn’t work here for this use case because the > >> information as to whether a given app is displayed or not should not > come > >> from the UIX itself (the app doesn’t know that info and shouldn’t set > >> this). It should come from the admin or from the flavor for this case at > >> hand. > >>>> > >>>> Also I don’t think that modifying the UIX of an app by the Application > >> Panel admin UI is a good thing. The storage if this info should go in > the > >> App Panel config page instead IMO. > >>>> > >>>> WDYT? > >>> > >>> True, I was just presenting another approach, which, by the way, also > >>> has limitations that are making me look for improvements. > >>> > >>> I don't agree that the application shouldn't know whether it's suitable > >>> for being displayed or not. Who knows that an extension is too > technical > >>> to be displayed? Certainly not the Panels application, > >> > >> I’ve never said the the app panel should know this. This would be > >> definitely wrong. > >> > >>> and flavors can't > >>> know beforehand all the extensions that may be installed. > >> > >> I think there may be 2 different use cases. The one I was addressing > >> mostly was the **default** list of Apps that are visible in the App > Panel. > >> > >> For this I still believe that the Flavor should have the configuration > and > >> that the list of apps visible by **default* don’t depend on the app > >> themselves but depend on the flavor. > >> > >>> I think that > >>> the application developers are the ones that should decide if their > >>> application is to be displayed by default or not. > >> > >> I think you’re talking about edge cases where some apps really don’t > want > >> to be displayed in the Panel. For me these apps should probably not > even be > >> apps. An example is an app providing only a wiki macro. This app > shouldn’t > >> register as an app at all. And thus it wouldn’t be displayed in the App > >> Index or App Panel. > >> > >> For all other apps, I’m personally fine that they appear in the App > Panel > >> for discoverability. Others will contend that some shouldn’t appear. For > >> example the Scheduler app is an app that I had configured to appear in > the > >> App panel for Admins only. Caty didn't agree for XE. But I’m sure she’d > >> have agreed for a technical flavor where the Scheduler app is key. > >> > >>> And these are just initial hints, the admins can then choose to change > >>> the default and manually hide/show/reorder applications. > >>> > >>> Now, for the fact that the parameters are stored *only* in the > >>> extension, that does indeed cause several problems: > >>> > >>> - modifying them may cause extension upgrade conflicts > >>> - only one global setting, no user or space settings > >>> - flavors can't override these settings > >>> > >>> How about this: we define a way of overriding extension parameters > using > >>> custom objects: > >>> > >>> XWiki.UIExtensionParameterOverridesClass > >>> - extensionPointId > >>> - name > >>> - parameters > >>> > >>> extensionPointId and name must match an UIX, and parameters override > the > >>> extension's parameters. > >>> > >>> Depending on where the object it placed, it can be valid for: > >>> - the whole wiki if placed in XWiki.XWikiPreferences > >>> - a space if placed in <Space>.WebPreferences > >>> - a certain user if placed in XWiki.<UserProfile> > >>> - any other page, and have a way of telling the uix manager that we > want > >>> to apply the parameter overrides in that page > >>> - not sure what to do for flavors, is XWiki.XWikiPreferences good, or > is > >>> there a flavor-specific configuration page? > >>> > >>> How does that sound? > >> > >> At first sight, sounds complex to me. I don’t think we need this right > >> now. For me we only need an App Panel-level configuration that’s taken > from > >> the flavor. > >> > >> FTR I’m also open to not adding new apps by default to the App Panel > (Edy > >> is also ok with this) since for me that’s the role of the App Index. > Now, I > >> think the App Index could be more visible (i.e I think we need to make > it > >> easier to navigate to various apps without having to open the drawer, > click > >> on Apps Index and then find the app). I can think of several ways: > >> * Add the link to the App Index from “More Applications”. Maybe a “All > >> Applications” label > >> * Rework the “More Applicatios” even more so that without clicking on > “All > >> Applications” (just by moving the mouse over it) it opens a lightbox > >> displaying all the apps. > >> * I’d also like to rework the Goto Page (Ctrl+G) to also add the ability > >> to navigate to apps more easily. Note that this one is not enough since > >> it’s harder to discover. > >> > >> Now I also agree that a whitelist is interesting (in addition to a > >> blacklist) and that we should offer the 2 configuration possibilities to > >> users. > >> > >> Thanks > >> -Vincent > >>> > >>>> Thanks > >>>> -Vincent > >>>> > >>>>> As a more advanced feature, in PhenoTips we also have a wizard that > >>>>> allows enabling/disabling and manually reordering extensions, by > >>>>> modifying the extension parameters. > >>>>> > >>>>> I didn't have time for this yet, but in the future I'd like to add > >>>>> support for ordering and enable/disable flags in the core UIX module, > >> so > >>>>> that extensions are automatically filtered and ordered. > >>>>> > >>>>> On 10/05/2016 05:37 AM, Vincent Massol wrote: > >>>>>> Hi devs, > >>>>>> > >>>>>> With the recent introduction of the Applications Index (see > >> http://extensions.xwiki.org/xwiki/bin/view/Extension/ > >> Application+Index+Application/) we need to agree on a few things. > >>>>>> > >>>>>> In the past we had: > >>>>>> * We wanted all new app that you installed to automatically be > >> visible in the Applications Panel > >>>>>> * This is why the Applications Panel config had a blacklist (and not > >> a white list) > >>>>>> > >>>>>> What we’ve done: > >>>>>> * We add the Applications Index > >>>>>> * We removed some apps from the Applications Panel. Namely: > >> Invitation, Panels, Scheduler, User Directory and Tour applications. > this > >> was done using hardcoded blacklist xobjects in PanelsCode. > >> ApplicationsPanelConfiguration. > >>>>>> > >>>>>> The need: > >>>>>> * We need to remove this hack. It’s not normal for the Panels module > >> to know all the apps that shouldn’t be listed in it! > >>>>>> > >>>>>> Proposal: > >>>>>> * Replace the blacklist configuration of the Applications Panel by a > >> whitelist one > >>>>>> * When a new app is installed, list it in the Applications Index but > >> don’t add it to the Applications Panel > >>>>>> * If an admin wants to add this new for his users, he’ll need to add > >> it in the Admin UI for the Applications Panel. > >>>>>> > >>>>>> WDYT? > >>>>>> > >>>>>> Thanks > >>>>>> -Vincent > > _______________________________________________ > devs mailing list > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs > -- Guillaume Delhumeau ([email protected]) Research & Development Engineer at XWiki SAS Committer on the XWiki.org project _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
