2017-05-18 9:56 GMT+02:00 Thomas Mortagne <[email protected]>:
> On Thu, May 18, 2017 at 9:20 AM, Clément Aubin <[email protected]> > wrote: > > Hi, > > > > On 05/18/2017 09:10 AM, Thomas Mortagne wrote: > >> I'm not sure I understand the goal here. > >> > >> For me what we need to do is provide a wiki version of > >> org.xwiki.eventstream.RecordableEventDescriptor and then send events > >> of that type using the script service but here you seems to be > >> designing a way to send events trough xobject creating which does not > >> make sense to me. > > > > This feature is, indeed, using the RecordableEventDescriptor role in > > order to work properly (the event type, the application name, the event > > description and the event icon are properties needed in a solution > > implementing RecordableEventDescriptor). > > > > 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. > I don't think Clément wanted to store the events as XObject. The idea is to be able create a *rule* that automatically send events when some xobjects are saved. That's all. > > * 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. > That's the idea. I think you get confused by the fact Clément proposed a field called "eventId', which has nothing to do here. Thanks > > > > > -- > > Clément Aubin > > Web Developer Intern @XWiki SAS > > [email protected] > > More about us at http://www.xwiki.com > > > -- > Thomas Mortagne > -- Guillaume Delhumeau ([email protected]) Research & Development Engineer at XWiki SAS Committer on the XWiki.org project
