Hi Caty,
On 17 Oct 2016, at 12:45, Ecaterina Moraru (Valica)
<valicac(a)gmail.com> wrote:
So it's problematic that the feature get oldish and it creates more
confusion than being useful. So I agree to disable it. The problem is that
disabling it means it will not be used anymore at all, so a better solution
would be to remove it from XE/Platform instead.
I don’t understand the logic and how removing it would make it easier for users to use it.
I understand that this means more work since it's
integrated in AS and
Profile,
Yep. Step 1 is disable, step 2 might be to remove it but we need to do step 1 first,
especially since there are several issues to fix first (see the jira).
but I want to raise a point for this use case.
One of the problems I see with XWiki Applications is their ability to
interconnect between them. For example, I would like to install the Meeting
app and that if I also install the Calendar app, the meetings would also be
displayed in the Calendar, and not be independent pages.
The same is also for the Message Stream app. This app was integrated to
display it's messages in Activity Stream, to be able to follow someone from
the User Profile and to display just an user messages in the Profile. We
had integration into several applications and although maybe the feature
was not complete or not very useful for our users, it affected multiple
zones of the UI.
Since we don't have any easy 'insertion/app collaborations' mechanisms is
hard for us to remove the Message Stream from XE, and is hard for us to
make multiple apps interconnect.
This is not correct. We do have several "'insertion/app collaborations’
mechanisms”. It’s just that the app integration wasn’t coded so nicely and some of these
mechanisms didn’t exist back then.
FTR we have 3 mechanisms:
* If you depend on a given app: we use an “#if”. Either on a given wiki page or better, on
a given extension installed (using the $services.extension script service when you’re in
velocity). For example the Meeting app can have an optional dependency on the Calendar app
and use such an if.
* If you want to define a place where other apps can integrate content. This can be
achieved using an UIXP. However we said that for apps we should favor custom XClass
instead. So the app should define such an XClass and then have other apps depend on it. In
the case of the User Profile, this is achieved by allowing apps to add new tabs with
UserProfileSectionClass). The bug here was to mix the Message sending feature in the tab
for the Profile. It should have had its own tab probably. Now even for a given tab, it’s
still possible for that tab to offer custom extension point by offering some other
XClass.
* For apps that need to extend skin/templates we offer the UIXP mechanism.
I'm not sure these kind of "magic integration
mechanisms" (it goes beyond
UIXP since you need also API) exists or if it means just plain old good
coding :) between apps, but it's just a point I wanted to make.
I don’t understand the problem. Do the 3 mechanism listed above answer your question?
What’s the problem with the API? Each extension can provide any number of API they want
already.
Thanks
-Vincent
Thanks,
Caty
On Mon, Oct 17, 2016 at 11:22 AM, Guillaume Delhumeau <
guillaume.delhumeau(a)xwiki.com> wrote:
> +1
>
> 2016-10-17 8:42 GMT+02:00 Alexandru Cotiuga <alexandru.cotiuga(a)xwiki.com>om>:
>
>> +1