> On 17 Oct 2016, at 12:45, Ecaterina Moraru (Valica) <vali...@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
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
What’s the problem with the API? Each extension can provide any number of API
they want already.
> On Mon, Oct 17, 2016 at 11:22 AM, Guillaume Delhumeau <
> guillaume.delhum...@xwiki.com> wrote:
>> 2016-10-17 8:42 GMT+02:00 Alexandru Cotiuga <alexandru.coti...@xwiki.com>:
devs mailing list