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