19 Oct
2016
19 Oct
'16
9:49 a.m.
On Wed, Oct 19, 2016 at 9:39 AM, Guillaume Delhumeau
<guillaume.delhumeau(a)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?
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 <vincent(a)massol.net>et>:
--
Thomas Mortagne
Hi Sergiu,
I’ve never said the the app panel should know this. This would be
definitely wrong.
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Guillaume Delhumeau (guillaume.delhumeau(a)xwiki.com)
Research & Development Engineer at XWiki SAS
Committer on the XWiki.org project
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs On 06 Oct 2016, at 17:56, Sergiu Dumitriu
<sergiu(a)xwiki.org> wrote:
On 10/06/2016 11:36 AM, Vincent Massol wrote:
> Hi Sergiu,
>
>> On 06 Oct 2016, at 17:30, Sergiu Dumitriu <sergiu(a)xwiki.org> 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 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
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs