[xwiki-devs] [XWIKI-14119] Propositions about in-page notifications design
Hi everyone, I’m currently working on a feature that should allow users to define custom notification types in XWiki only through the definition of an XObject (link to the issue : https://jira.xwiki.org/browse/XWIKI-14119). In this context, I wanted to know your thoughts about what properties should be proposed by this XObject. Currently, here is my proposition : - The application name (applicationName) : the event application name - A unique ID for the event (eventId) - An event «pretty» name / description (eventPrettyName) - An event icon, mainly displayed in the user notification preferences pane (eventIcon) - An event type (eventType) : the name of the event that should trigger the notification (such as org.xwiki.bridge.event.DocumentUpdatedEvent) - An object type (objectType) : an XObject that _has_ to be associated with the document triggering the event in order to trigger the custom notification - A validation expression (validationExpression) : a script that will be parsed in the event context in order to filter certain event kinds. - A notification template (notificationTemplate) : the template that should be used for rendering the notification in the notification center To summarize, a custom notification is triggered if the following expression is fully satisfied : «The (eventType) has been triggered on a document having (objectType) in his XObjects and the (validationExpression) is true in the current context». What do you think ? Thanks, -- Clément Aubin Web Developer Intern @XWiki SAS clement.aubin@xwiki.com More about us at http://www.xwiki.com
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. On Wed, May 17, 2017 at 11:29 PM, Clément Aubin <clement.aubin@xwiki.com> wrote:
Hi everyone,
I’m currently working on a feature that should allow users to define custom notification types in XWiki only through the definition of an XObject (link to the issue : https://jira.xwiki.org/browse/XWIKI-14119).
In this context, I wanted to know your thoughts about what properties should be proposed by this XObject.
Currently, here is my proposition :
- The application name (applicationName) : the event application name
- A unique ID for the event (eventId)
- An event «pretty» name / description (eventPrettyName)
- An event icon, mainly displayed in the user notification preferences pane (eventIcon)
- An event type (eventType) : the name of the event that should trigger the notification (such as org.xwiki.bridge.event.DocumentUpdatedEvent)
- An object type (objectType) : an XObject that _has_ to be associated with the document triggering the event in order to trigger the custom notification
- A validation expression (validationExpression) : a script that will be parsed in the event context in order to filter certain event kinds.
- A notification template (notificationTemplate) : the template that should be used for rendering the notification in the notification center
To summarize, a custom notification is triggered if the following expression is fully satisfied : «The (eventType) has been triggered on a document having (objectType) in his XObjects and the (validationExpression) is true in the current context».
What do you think ?
Thanks,
-- Clément Aubin Web Developer Intern @XWiki SAS clement.aubin@xwiki.com More about us at http://www.xwiki.com
-- Thomas Mortagne
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 ? -- Clément Aubin Web Developer Intern @XWiki SAS clement.aubin@xwiki.com More about us at http://www.xwiki.com
On Thu, May 18, 2017 at 9:20 AM, Clément Aubin <clement.aubin@xwiki.com> 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. * 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.
-- Clément Aubin Web Developer Intern @XWiki SAS clement.aubin@xwiki.com More about us at http://www.xwiki.com
-- Thomas Mortagne
2017-05-18 9:56 GMT+02:00 Thomas Mortagne <thomas.mortagne@xwiki.com>:
On Thu, May 18, 2017 at 9:20 AM, Clément Aubin <clement.aubin@xwiki.com> 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 clement.aubin@xwiki.com More about us at http://www.xwiki.com
-- Thomas Mortagne
-- Guillaume Delhumeau (guillaume.delhumeau@xwiki.com) Research & Development Engineer at XWiki SAS Committer on the XWiki.org project
On 05/18/2017 09:56 AM, Thomas Mortagne wrote:
On Thu, May 18, 2017 at 9:20 AM, Clément Aubin <clement.aubin@xwiki.com> 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 clement.aubin@xwiki.com More about us at http://www.xwiki.com
Hello 2017-05-18 9:10 GMT+02:00 Thomas Mortagne <thomas.mortagne@xwiki.com>:
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.
What I have in mind was not to create a script service to send events, but a system that send automatically a recordable event when an XObject of a certain type is saved. Let me explain with an example. Image a descriptor that say: * listen to all DocumentUpdatedEvent and DocumentCreatedEvent * if the saved page hold an XObject "Blog.BlogPost" * then send a RecordableEvent with a parameter "eventType" to "blogPostPublished" Then, somewhere, a listener that listen to every RecordableEvent receives the event with the parameter "blogPostPublished", and saves into the Event Stream the event with the type "blogPostPublished". Currently, to have this behaviour, the blog application has to create a subclass of RecordableEvent, a RecordableEventDescriptor and a listener that check when an blog post is saved. It's a lot of work and must be done in java. But I am convinced that it is a frequent use-case. Having an XObject saying "every time the object Blog.BlogPost is saved, then send and record a custom RecordableEvent with the eventType "blogPostPublished" will help a lot and will not require any java dependency. Thanks
On Wed, May 17, 2017 at 11:29 PM, Clément Aubin <clement.aubin@xwiki.com> wrote:
Hi everyone,
I’m currently working on a feature that should allow users to define custom notification types in XWiki only through the definition of an XObject (link to the issue : https://jira.xwiki.org/browse/XWIKI-14119).
In this context, I wanted to know your thoughts about what properties should be proposed by this XObject.
Currently, here is my proposition :
- The application name (applicationName) : the event application name
- A unique ID for the event (eventId)
- An event «pretty» name / description (eventPrettyName)
- An event icon, mainly displayed in the user notification preferences pane (eventIcon)
- An event type (eventType) : the name of the event that should trigger the notification (such as org.xwiki.bridge.event.DocumentUpdatedEvent)
- An object type (objectType) : an XObject that _has_ to be associated with the document triggering the event in order to trigger the custom notification
- A validation expression (validationExpression) : a script that will be parsed in the event context in order to filter certain event kinds.
- A notification template (notificationTemplate) : the template that should be used for rendering the notification in the notification center
To summarize, a custom notification is triggered if the following expression is fully satisfied : «The (eventType) has been triggered on a document having (objectType) in his XObjects and the (validationExpression) is true in the current context».
What do you think ?
Thanks,
-- Clément Aubin Web Developer Intern @XWiki SAS clement.aubin@xwiki.com More about us at http://www.xwiki.com
-- Thomas Mortagne
-- Guillaume Delhumeau (guillaume.delhumeau@xwiki.com) Research & Development Engineer at XWiki SAS Committer on the XWiki.org project
Hi Clément 2017-05-17 23:29 GMT+02:00 Clément Aubin <clement.aubin@xwiki.com>:
Hi everyone,
I’m currently working on a feature that should allow users to define custom notification types in XWiki only through the definition of an XObject (link to the issue : https://jira.xwiki.org/browse/XWIKI-14119).
In this context, I wanted to know your thoughts about what properties should be proposed by this XObject.
Currently, here is my proposition :
- The application name (applicationName) : the event application name
- A unique ID for the event (eventId)
What does it mean? If the ID is unique, it must be computed every time an event is created and it's not the job of the event descriptor to generate this.
- An event «pretty» name / description (eventPrettyName)
- An event icon, mainly displayed in the user notification preferences pane (eventIcon)
- An event type (eventType) : the name of the event that should trigger the notification (such as org.xwiki.bridge.event.DocumentUpdatedEvent)
- An object type (objectType) : an XObject that _has_ to be associated with the document triggering the event in order to trigger the custom notification
- A validation expression (validationExpression) : a script that will be parsed in the event context in order to filter certain event kinds.
- A notification template (notificationTemplate) : the template that should be used for rendering the notification in the notification center
To summarize, a custom notification is triggered if the following expression is fully satisfied : «The (eventType) has been triggered on a document having (objectType) in his XObjects and the (validationExpression) is true in the current context».
What do you think ?
Thanks,
-- Clément Aubin Web Developer Intern @XWiki SAS clement.aubin@xwiki.com More about us at http://www.xwiki.com
Thanks -- Guillaume Delhumeau (guillaume.delhumeau@xwiki.com) Research & Development Engineer at XWiki SAS Committer on the XWiki.org project
On 05/18/2017 10:18 AM, Guillaume Delhumeau wrote:
Hi Clément
2017-05-17 23:29 GMT+02:00 Clément Aubin <clement.aubin@xwiki.com>:
Hi everyone,
I’m currently working on a feature that should allow users to define custom notification types in XWiki only through the definition of an XObject (link to the issue : https://jira.xwiki.org/browse/XWIKI-14119).
In this context, I wanted to know your thoughts about what properties should be proposed by this XObject.
Currently, here is my proposition :
- The application name (applicationName) : the event application name
- A unique ID for the event (eventId)
What does it mean? If the ID is unique, it must be computed every time an event is created and it's not the job of the event descriptor to generate this.
This event ID is used to uniquely identify an event type (I should maybe rename it to eventTypeID in order to avoid some confusion), but the idea of generating this ID automatically is very interesting !
- An event «pretty» name / description (eventPrettyName)
- An event icon, mainly displayed in the user notification preferences pane (eventIcon)
- An event type (eventType) : the name of the event that should trigger the notification (such as org.xwiki.bridge.event.DocumentUpdatedEvent)
- An object type (objectType) : an XObject that _has_ to be associated with the document triggering the event in order to trigger the custom notification
- A validation expression (validationExpression) : a script that will be parsed in the event context in order to filter certain event kinds.
- A notification template (notificationTemplate) : the template that should be used for rendering the notification in the notification center
To summarize, a custom notification is triggered if the following expression is fully satisfied : «The (eventType) has been triggered on a document having (objectType) in his XObjects and the (validationExpression) is true in the current context».
What do you think ?
Thanks,
-- Clément Aubin Web Developer Intern @XWiki SAS clement.aubin@xwiki.com More about us at http://www.xwiki.com
Thanks
-- Clément Aubin Web Developer Intern @XWiki SAS clement.aubin@xwiki.com More about us at http://www.xwiki.com
2017-05-18 10:34 GMT+02:00 Clément Aubin <clement.aubin@xwiki.com>:
On 05/18/2017 10:18 AM, Guillaume Delhumeau wrote:
Hi Clément
2017-05-17 23:29 GMT+02:00 Clément Aubin <clement.aubin@xwiki.com>:
Hi everyone,
I’m currently working on a feature that should allow users to define custom notification types in XWiki only through the definition of an XObject (link to the issue : https://jira.xwiki.org/browse/XWIKI-14119 ).
In this context, I wanted to know your thoughts about what properties should be proposed by this XObject.
Currently, here is my proposition :
- The application name (applicationName) : the event application name
- A unique ID for the event (eventId)
What does it mean? If the ID is unique, it must be computed every time an event is created and it's not the job of the event descriptor to generate this.
This event ID is used to uniquely identify an event type (I should maybe rename it to eventTypeID in order to avoid some confusion), but the idea of generating this ID automatically is very interesting !
Si it's not "eventId" but "eventType". The other field that specify which events to listen should be called "listenTo".
- An event «pretty» name / description (eventPrettyName)
- An event icon, mainly displayed in the user notification preferences pane (eventIcon)
- An event type (eventType) : the name of the event that should trigger the notification (such as org.xwiki.bridge.event.DocumentUpdatedEvent)
- An object type (objectType) : an XObject that _has_ to be associated with the document triggering the event in order to trigger the custom notification
- A validation expression (validationExpression) : a script that will be parsed in the event context in order to filter certain event kinds.
- A notification template (notificationTemplate) : the template that should be used for rendering the notification in the notification center
To summarize, a custom notification is triggered if the following expression is fully satisfied : «The (eventType) has been triggered on a document having (objectType) in his XObjects and the (validationExpression) is true in the current context».
What do you think ?
Thanks,
-- Clément Aubin Web Developer Intern @XWiki SAS
clement.aubin@xwiki.com
More about us at http://www.xwiki.com
Thanks
-- Clément Aubin Web Developer Intern @XWiki SAS clement.aubin@xwiki.com More about us at http://www.xwiki.com
-- Guillaume Delhumeau (guillaume.delhumeau@xwiki.com) Research & Development Engineer at XWiki SAS Committer on the XWiki.org project
On Thu, May 18, 2017 at 10:34 AM, Clément Aubin <clement.aubin@xwiki.com> wrote:
On 05/18/2017 10:18 AM, Guillaume Delhumeau wrote:
Hi Clément
2017-05-17 23:29 GMT+02:00 Clément Aubin <clement.aubin@xwiki.com>:
Hi everyone,
I’m currently working on a feature that should allow users to define custom notification types in XWiki only through the definition of an XObject (link to the issue : https://jira.xwiki.org/browse/XWIKI-14119).
In this context, I wanted to know your thoughts about what properties should be proposed by this XObject.
Currently, here is my proposition :
- The application name (applicationName) : the event application name
- A unique ID for the event (eventId)
What does it mean? If the ID is unique, it must be computed every time an event is created and it's not the job of the event descriptor to generate this.
This event ID is used to uniquely identify an event type (I should maybe rename it to eventTypeID in order to avoid some confusion), but the idea of generating this ID automatically is very interesting !
You already have another field with the event type so I still don't see what this eventid field is about.
- An event «pretty» name / description (eventPrettyName)
- An event icon, mainly displayed in the user notification preferences pane (eventIcon)
- An event type (eventType) : the name of the event that should trigger the notification (such as org.xwiki.bridge.event.DocumentUpdatedEvent)
- An object type (objectType) : an XObject that _has_ to be associated with the document triggering the event in order to trigger the custom notification
- A validation expression (validationExpression) : a script that will be parsed in the event context in order to filter certain event kinds.
- A notification template (notificationTemplate) : the template that should be used for rendering the notification in the notification center
To summarize, a custom notification is triggered if the following expression is fully satisfied : «The (eventType) has been triggered on a document having (objectType) in his XObjects and the (validationExpression) is true in the current context».
What do you think ?
Thanks,
-- Clément Aubin Web Developer Intern @XWiki SAS clement.aubin@xwiki.com More about us at http://www.xwiki.com
Thanks
-- Clément Aubin Web Developer Intern @XWiki SAS clement.aubin@xwiki.com More about us at http://www.xwiki.com
-- Thomas Mortagne
On Thu, May 18, 2017 at 2:11 PM, Thomas Mortagne <thomas.mortagne@xwiki.com> wrote:
On Thu, May 18, 2017 at 10:34 AM, Clément Aubin <clement.aubin@xwiki.com> wrote:
On 05/18/2017 10:18 AM, Guillaume Delhumeau wrote:
Hi Clément
2017-05-17 23:29 GMT+02:00 Clément Aubin <clement.aubin@xwiki.com>:
Hi everyone,
I’m currently working on a feature that should allow users to define custom notification types in XWiki only through the definition of an XObject (link to the issue : https://jira.xwiki.org/browse/XWIKI-14119).
In this context, I wanted to know your thoughts about what properties should be proposed by this XObject.
Currently, here is my proposition :
- The application name (applicationName) : the event application name
- A unique ID for the event (eventId)
What does it mean? If the ID is unique, it must be computed every time an event is created and it's not the job of the event descriptor to generate this.
This event ID is used to uniquely identify an event type (I should maybe rename it to eventTypeID in order to avoid some confusion), but the idea of generating this ID automatically is very interesting !
You already have another field with the event type so I still don't see what this eventid field is about.
- An event «pretty» name / description (eventPrettyName)
- An event icon, mainly displayed in the user notification preferences pane (eventIcon)
- An event type (eventType) : the name of the event that should trigger the notification (such as org.xwiki.bridge.event.DocumentUpdatedEvent)
- An object type (objectType) : an XObject that _has_ to be associated with the document triggering the event in order to trigger the custom notification
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.
- A validation expression (validationExpression) : a script that will be parsed in the event context in order to filter certain event kinds.
- A notification template (notificationTemplate) : the template that should be used for rendering the notification in the notification center
What do you mean exactly by "template" ? A reference to a template, the actual wiki content that will do the display ?
To summarize, a custom notification is triggered if the following expression is fully satisfied : «The (eventType) has been triggered on a document having (objectType) in his XObjects and the (validationExpression) is true in the current context».
What do you think ?
Thanks,
-- Clément Aubin Web Developer Intern @XWiki SAS clement.aubin@xwiki.com More about us at http://www.xwiki.com
Thanks
-- Clément Aubin Web Developer Intern @XWiki SAS clement.aubin@xwiki.com More about us at http://www.xwiki.com
-- Thomas Mortagne
-- Thomas Mortagne
On 05/18/2017 02:17 PM, Thomas Mortagne wrote:
On Thu, May 18, 2017 at 2:11 PM, Thomas Mortagne <thomas.mortagne@xwiki.com> wrote:
On Thu, May 18, 2017 at 10:34 AM, Clément Aubin <clement.aubin@xwiki.com> wrote:
On 05/18/2017 10:18 AM, Guillaume Delhumeau wrote:
Hi Clément
2017-05-17 23:29 GMT+02:00 Clément Aubin <clement.aubin@xwiki.com>:
Hi everyone,
I’m currently working on a feature that should allow users to define custom notification types in XWiki only through the definition of an XObject (link to the issue : https://jira.xwiki.org/browse/XWIKI-14119).
In this context, I wanted to know your thoughts about what properties should be proposed by this XObject.
Currently, here is my proposition :
- The application name (applicationName) : the event application name
- A unique ID for the event (eventId)
What does it mean? If the ID is unique, it must be computed every time an event is created and it's not the job of the event descriptor to generate this.
This event ID is used to uniquely identify an event type (I should maybe rename it to eventTypeID in order to avoid some confusion), but the idea of generating this ID automatically is very interesting !
You already have another field with the event type so I still don't see what this eventid field is about.
Here, eventId is used to uniquely identify an event. If I take the exemple of the application-blog, this eventId would be «BlogPostPublishedEvent». Note that, as Guillaume suggested, I plan to rename it eventType in order to avoid confusion. The current «eventType» field will be renamed «listenTo» or «eventTrigger».
- An event «pretty» name / description (eventPrettyName)
- An event icon, mainly displayed in the user notification preferences pane (eventIcon)
- An event type (eventType) : the name of the event that should trigger the notification (such as org.xwiki.bridge.event.DocumentUpdatedEvent)
- An object type (objectType) : an XObject that _has_ to be associated with the document triggering the event in order to trigger the custom notification
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.
Ok !
- A validation expression (validationExpression) : a script that will be parsed in the event context in order to filter certain event kinds.
- A notification template (notificationTemplate) : the template that should be used for rendering the notification in the notification center
What do you mean exactly by "template" ? A reference to a template, the actual wiki content that will do the display ?
Currently, it’s the actual wiki content that will be displayed.
To summarize, a custom notification is triggered if the following expression is fully satisfied : «The (eventType) has been triggered on a document having (objectType) in his XObjects and the (validationExpression) is true in the current context».
What do you think ?
Thanks,
-- Clément Aubin Web Developer Intern @XWiki SAS clement.aubin@xwiki.com More about us at http://www.xwiki.com
Hi,
On 17 May 2017, at 23:29, Clément Aubin <clement.aubin@xwiki.com> wrote:
Hi everyone,
I’m currently working on a feature that should allow users to define custom notification types in XWiki only through the definition of an XObject (link to the issue : https://jira.xwiki.org/browse/XWIKI-14119).
In this context, I wanted to know your thoughts about what properties should be proposed by this XObject.
Currently, here is my proposition :
- The application name (applicationName) : the event application name
- A unique ID for the event (eventId)
- An event «pretty» name / description (eventPrettyName)
- An event icon, mainly displayed in the user notification preferences pane (eventIcon)
- An event type (eventType) : the name of the event that should trigger the notification (such as org.xwiki.bridge.event.DocumentUpdatedEvent)
So this means that the application would still need to have some java to generate the custom event? Of course it’s possible to define a wiki component that implements EventListener but this requires PR. There are 2 ways I can think of: 1) We could offer a specific XClass that would be a specific wrapper around Wiki Components for EventListener and that wouldn’t require PR. It could require Admin permissions if we want to err on the safe side. A typical use case is the ability to register an EventListener when an xobject of a given type is modified and allow executing some script. 2) Have something specific to notifications for some specific use cases. For example we could have 3 xproperties: - an xproperty to specify its name (eg “BlogPostPublished”) - a “strategy” xproperty with one option being to “send on save”. - a “object” xproperty representing the xobject type to listen to (e.g. Blog.BlogPostClass). Note: this xproperty depends on the “strategy” one. With these 3 pieces of info you can write a generic (but specific to this use case) listener that would listen on 2) is nice but only solves specific use cases but it could be extended with a “custom” strategy.
- An object type (objectType) : an XObject that _has_ to be associated with the document triggering the event in order to trigger the custom notification
I don’t understand what this is. What would be nice would be to take the example of the Blog application and show us how you’d use your xobject to represent the notification for it. Thanks! -Vincent
- A validation expression (validationExpression) : a script that will be parsed in the event context in order to filter certain event kinds.
- A notification template (notificationTemplate) : the template that should be used for rendering the notification in the notification center
To summarize, a custom notification is triggered if the following expression is fully satisfied : «The (eventType) has been triggered on a document having (objectType) in his XObjects and the (validationExpression) is true in the current context».
What do you think ?
Thanks,
-- Clément Aubin Web Developer Intern @XWiki SAS clement.aubin@xwiki.com More about us at http://www.xwiki.com
2017-05-18 15:15 GMT+02:00 Vincent Massol <vincent@massol.net>:
Hi,
On 17 May 2017, at 23:29, Clément Aubin <clement.aubin@xwiki.com> wrote:
Hi everyone,
I’m currently working on a feature that should allow users to define custom notification types in XWiki only through the definition of an XObject (link to the issue : https://jira.xwiki.org/browse/XWIKI-14119).
In this context, I wanted to know your thoughts about what properties should be proposed by this XObject.
Currently, here is my proposition :
- The application name (applicationName) : the event application name
- A unique ID for the event (eventId)
- An event «pretty» name / description (eventPrettyName)
- An event icon, mainly displayed in the user notification preferences pane (eventIcon)
- An event type (eventType) : the name of the event that should trigger the notification (such as org.xwiki.bridge.event.DocumentUpdatedEvent)
So this means that the application would still need to have some java to generate the custom event?
No. Clement is making a generic listener. When the listener receive an event of the type defined by a descriptor, it will perform some actions (ie: sending a more specific event that will be stored in the event stream). All the application have to do is to specify with event to listen, what is the specific event to send (which is a generic ParametrizableRecordableEvent with a "type" parameter), and what XObject to look at in order to send or not the specific event.
Of course it’s possible to define a wiki component that implements EventListener but this requires PR.
There are 2 ways I can think of:
1) We could offer a specific XClass that would be a specific wrapper around Wiki Components for EventListener and that wouldn’t require PR. It could require Admin permissions if we want to err on the safe side. A typical use case is the ability to register an EventListener when an xobject of a given type is modified and allow executing some script.
2) Have something specific to notifications for some specific use cases. For example we could have 3 xproperties: - an xproperty to specify its name (eg “BlogPostPublished”) - a “strategy” xproperty with one option being to “send on save”. - a “object” xproperty representing the xobject type to listen to (e.g. Blog.BlogPostClass). Note: this xproperty depends on the “strategy” one.
With these 3 pieces of info you can write a generic (but specific to this use case) listener that would listen on
That is the idea. Clément and I did not think about this "strategy" property but it's a good idea.
2) is nice but only solves specific use cases but it could be extended with a “custom” strategy.
- An object type (objectType) : an XObject that _has_ to be associated with the document triggering the event in order to trigger the custom notification
I don’t understand what this is.
It's what you call the "object” xproperty (representing the xobject type to listen to (e.g. Blog.BlogPostClass)).
What would be nice would be to take the example of the Blog application and show us how you’d use your xobject to represent the notification for it.
Thanks! -Vincent
- A validation expression (validationExpression) : a script that will be parsed in the event context in order to filter certain event kinds.
- A notification template (notificationTemplate) : the template that should be used for rendering the notification in the notification center
To summarize, a custom notification is triggered if the following expression is fully satisfied : «The (eventType) has been triggered on a document having (objectType) in his XObjects and the (validationExpression) is true in the current context».
What do you think ?
Thanks,
-- Clément Aubin Web Developer Intern @XWiki SAS clement.aubin@xwiki.com More about us at http://www.xwiki.com
-- Guillaume Delhumeau (guillaume.delhumeau@xwiki.com) Research & Development Engineer at XWiki SAS Committer on the XWiki.org project
On 17 May 2017, at 23:29, Clément Aubin <clement.aubin@xwiki.com> wrote:
Hi everyone,
I’m currently working on a feature that should allow users to define custom notification types in XWiki only through the definition of an XObject (link to the issue : https://jira.xwiki.org/browse/XWIKI-14119).
In this context, I wanted to know your thoughts about what properties should be proposed by this XObject.
Currently, here is my proposition :
- The application name (applicationName) : the event application name
- A unique ID for the event (eventId)
- An event «pretty» name / description (eventPrettyName)
- An event icon, mainly displayed in the user notification preferences pane (eventIcon)
- An event type (eventType) : the name of the event that should trigger the notification (such as org.xwiki.bridge.event.DocumentUpdatedEvent)
I think this should be a list since for example for the Blog use case you’ll want to send a Blog Post Published event by listening to 2 events: * DocumentUpdatedEvent (when the use publishes an existing non-published Blog post) * DocumentCreatedEvent (when the user creates and publishes at the same time a new Blog post) In those 2 cases, I think you’d use the same app name, event id, pretty name, icon, etc.
- An object type (objectType) : an XObject that _has_ to be associated with the document triggering the event in order to trigger the custom notification
- A validation expression (validationExpression) : a script that will be parsed in the event context in order to filter certain event kinds.
This is not very clear but I think this is what I asked Clement to add yesterday in order to implement the Blog Post Published use case. For this example you need to check the BlogPostClass XObject to verify if it’s published or not. Is that it? Thanks -Vincent
- A notification template (notificationTemplate) : the template that should be used for rendering the notification in the notification center
To summarize, a custom notification is triggered if the following expression is fully satisfied : «The (eventType) has been triggered on a document having (objectType) in his XObjects and the (validationExpression) is true in the current context».
What do you think ?
Thanks,
-- Clément Aubin Web Developer Intern @XWiki SAS clement.aubin@xwiki.com More about us at http://www.xwiki.com
2017-05-18 18:26 GMT+02:00 Vincent Massol <vincent@massol.net>:
On 17 May 2017, at 23:29, Clément Aubin <clement.aubin@xwiki.com> wrote:
Hi everyone,
I’m currently working on a feature that should allow users to define custom notification types in XWiki only through the definition of an XObject (link to the issue : https://jira.xwiki.org/browse/XWIKI-14119).
In this context, I wanted to know your thoughts about what properties should be proposed by this XObject.
Currently, here is my proposition :
- The application name (applicationName) : the event application name
- A unique ID for the event (eventId)
- An event «pretty» name / description (eventPrettyName)
- An event icon, mainly displayed in the user notification preferences pane (eventIcon)
- An event type (eventType) : the name of the event that should trigger the notification (such as org.xwiki.bridge.event.DocumentUpdatedEvent)
I think this should be a list since for example for the Blog use case you’ll want to send a Blog Post Published event by listening to 2 events: * DocumentUpdatedEvent (when the use publishes an existing non-published Blog post) * DocumentCreatedEvent (when the user creates and publishes at the same time a new Blog post)
In those 2 cases, I think you’d use the same app name, event id, pretty name, icon, etc.
+1
- An object type (objectType) : an XObject that _has_ to be associated with the document triggering the event in order to trigger the custom notification
- A validation expression (validationExpression) : a script that will be parsed in the event context in order to filter certain event kinds.
This is not very clear but I think this is what I asked Clement to add yesterday in order to implement the Blog Post Published use case. For this example you need to check the BlogPostClass XObject to verify if it’s published or not.
Is that it?
It's how I understand it too.
Thanks -Vincent
- A notification template (notificationTemplate) : the template that should be used for rendering the notification in the notification center
To summarize, a custom notification is triggered if the following expression is fully satisfied : «The (eventType) has been triggered on a document having (objectType) in his XObjects and the (validationExpression) is true in the current context».
What do you think ?
Thanks,
-- Clément Aubin Web Developer Intern @XWiki SAS clement.aubin@xwiki.com More about us at http://www.xwiki.com
-- Guillaume Delhumeau (guillaume.delhumeau@xwiki.com) Research & Development Engineer at XWiki SAS Committer on the XWiki.org project
participants (4)
-
Clément Aubin -
Guillaume Delhumeau -
Thomas Mortagne -
Vincent Massol