On 05/18/2017 09:56 AM, Thomas Mortagne wrote:
On Thu, May 18, 2017 at 9:20 AM, Clément Aubin <[email protected]> wrote:
[…]
Then, why does sending events through XObjects does not make sense to you ?
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.
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.
* keeping them as XObject forever is totally useless and does not scale for very frequent events
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.
* it duplicates what is already stored in the event stream table
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.
* 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
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 [email protected] More about us at http://www.xwiki.com