On Thu, May 18, 2017 at 9:20 AM, Clément Aubin <clement.aubin(a)xwiki.com> wrote: Because xobjects are stored while events are temporary objects by definition. You then have a event/activity stream listener which use the database to cache events to remind users about them but it's really just caching, not infinite storage like xobjetc are. * keeping them as XObject forever is totally useless and does not scale for very frequent events * it duplicates what is already stored in the event stream table * many kind of events are generated by some code and calling something like $services.notification.sendEvent('mytype', $data) make much more sense than having to create some xobject when you want to send an event in your script If the only use case you have in mind is events related to the creation of some kind type of documents (like a blog post) then you should at the very least separate the event descriptor xobject (which would be defined in the document of the blog post xclass for example) and the xobject used as helper to generate an event (since in this use case it's not so easy to have a script called when the document is created) which would be in the saved blog post document. Still it's quite crappy (you still store something to generate a temporary object) and it would be much cleaner (and a lot easier for the application) to have something more dynamic. For example a generic listener on Java side which listen to XObjectAddedEvent and if the xclass document of this xobject contains an event descriptor, automatically send a corresponding event. No useless stiff stored and no need for the application to remember to add a special object every time it create a new entry. -- Thomas Mortagne

On 05/18/2017 09:56 AM, Thomas Mortagne wrote: Ok, so I think that I have to explain myself in more details here. The goal is *not* to store an event as an XObject. I use an XObject to define a custom event type (that you can compare in some ways to a RecordableEventDescriptor), which is then translated into a Java object that has a similar behavior to a RecordableEventDescriptor apart from the fact that it’s not a Component. Actually, it does scale because the XObjects are translated into objects at application startup or when they are created / updated. So no database interaction is needed in order to trigger a XObject-based notification when an event is received. As far as I know, the event stream table currently contains both a trace of the events that have been saved and a trace of the notifications that have been triggered by those events. The solution we’re talking about will not change this comportment. Actually, I do agree that adding the API call you just described in templates would be great, but this call should rely on an event type already defined either in Java classes or using a way to create event types directly in the platform, which is exactly the solution that we’re talking about. -- Clément Aubin Web Developer Intern @XWiki SAS clement.aubin(a)xwiki.com More about us at http://www.xwiki.com

2017-05-18 10:34 GMT+02:00 Clément Aubin <clement.aubin(a)xwiki.com>om>: Si it's not "eventId" but "eventType". The other field that specify which events to listen should be called "listenTo". -- Guillaume Delhumeau (guillaume.delhumeau(a)xwiki.com) Research & Development Engineer at XWiki SAS Committer on the XWiki.org project

On Thu, May 18, 2017 at 2:11 PM, Thomas Mortagne <thomas.mortagne(a)xwiki.com> wrote: Should be optional IMO and most of the time the class should be the document in which the event type descriptor it's stored like I explained in my example. What do you mean exactly by "template" ? A reference to a template, the actual wiki content that will do the display ? -- Thomas Mortagne