21 Jul
2014
21 Jul
'14
8:31 p.m.
Hello fellow developers,
Why exactly are you subclassing ActivityStream to
achieve that?
Mmm, I am not sure of the original reason. That was Ludovic and Marius in 2008.
At that point, it makes sense to subclass the ActivityStreamPlugin and register the…
CurrikiActivityStream.
Why not use XWiki`s Observation Modules [1]? That`s
what AS uses to
immediately catch events and store them.
It is very likely that the CurrikiActivityStream has been a shallow copy of the
ActivityStream of XWiki with overrides where needed, and grew at the same times as the
activityStream grew.
You can do the same for immediate notifications.
That's what we are doing right now.
The listener needs some application-special logic: e.g. so that events can say "sent
to roles x/y/z of this group" or "sent this message".
For daily digests, just use a daily scheduler job and
get the recorded
events from AS for the day that just passed.
That's done and deployed on gpsnetwork.org.
Also, how exactly are you using the events to offer
"notifications"? Can
you offer more details?
That's in
https://github.com/xwiki-contrib/currikiorg/blob/master/plugins/currikiacti…
and following.
The idea is that the application-specific processing is something we want to leverage but
still use Groovy pages to send the mail the appropriate group members. So we call back
groovy from java, in a background thread triggered by the observation listener call.
On a related topic, would you find it interesting to
have the output of the
activity macro (with your filters/parameters applied to it) as JSON so that
you would use it in your application?
Would a REST (xml/json output) resource for reading events be better
instead of a macro in a wiki page?
Probably one of them.
But we've had different macros since ages… there's no urgency to use a new API.
Also, service-based displays of data are more fragile because they break if javascript
breaks.
paul