[XWIKI-14119] Propositions about in-page notifications design

classic Classic list List threaded Threaded
17 messages Options
Reply | Threaded
Open this post in threaded view
|

[XWIKI-14119] Propositions about in-page notifications design

Clément Aubin
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 [hidden email]
More about us at http://www.xwiki.com

Reply | Threaded
Open this post in threaded view
|

Re: [XWIKI-14119] Propositions about in-page notifications design

Thomas Mortagne
Administrator
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 <[hidden email]> 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 [hidden email]
> More about us at http://www.xwiki.com
>



--
Thomas Mortagne
Reply | Threaded
Open this post in threaded view
|

Re: [XWIKI-14119] Propositions about in-page notifications design

Clément Aubin
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
[hidden email]
More about us at http://www.xwiki.com
Reply | Threaded
Open this post in threaded view
|

Re: [XWIKI-14119] Propositions about in-page notifications design

Thomas Mortagne
Administrator
On Thu, May 18, 2017 at 9:20 AM, Clément Aubin <[hidden email]> 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
> [hidden email]
> More about us at http://www.xwiki.com


--
Thomas Mortagne
Reply | Threaded
Open this post in threaded view
|

Re: [XWIKI-14119] Propositions about in-page notifications design

Guillaume Delhumeau
In reply to this post by Thomas Mortagne
Hello

2017-05-18 9:10 GMT+02:00 Thomas Mortagne <[hidden email]>:

> 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 <[hidden email]>
> 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 [hidden email]
> > More about us at http://www.xwiki.com
> >
>
>
>
> --
> Thomas Mortagne
>



--
Guillaume Delhumeau ([hidden email])
Research & Development Engineer at XWiki SAS
Committer on the XWiki.org project
Reply | Threaded
Open this post in threaded view
|

Re: [XWIKI-14119] Propositions about in-page notifications design

Guillaume Delhumeau
In reply to this post by Clément Aubin
Hi Clément

2017-05-17 23:29 GMT+02:00 Clément Aubin <[hidden email]>:

> 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 [hidden email]
> More about us at http://www.xwiki.com
>
>
Thanks


--
Guillaume Delhumeau ([hidden email])
Research & Development Engineer at XWiki SAS
Committer on the XWiki.org project
Reply | Threaded
Open this post in threaded view
|

Re: [XWIKI-14119] Propositions about in-page notifications design

Guillaume Delhumeau
In reply to this post by Thomas Mortagne
2017-05-18 9:56 GMT+02:00 Thomas Mortagne <[hidden email]>:

> On Thu, May 18, 2017 at 9:20 AM, Clément Aubin <[hidden email]>
> 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
> > [hidden email]
> > More about us at http://www.xwiki.com
>
>
> --
> Thomas Mortagne
>



--
Guillaume Delhumeau ([hidden email])
Research & Development Engineer at XWiki SAS
Committer on the XWiki.org project
Reply | Threaded
Open this post in threaded view
|

Re: [XWIKI-14119] Propositions about in-page notifications design

Clément Aubin
In reply to this post by Thomas Mortagne
On 05/18/2017 09:56 AM, Thomas Mortagne wrote:

> On Thu, May 18, 2017 at 9:20 AM, Clément Aubin <[hidden email]> 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
[hidden email]
More about us at http://www.xwiki.com
Reply | Threaded
Open this post in threaded view
|

Re: [XWIKI-14119] Propositions about in-page notifications design

Clément Aubin
In reply to this post by Guillaume Delhumeau
On 05/18/2017 10:18 AM, Guillaume Delhumeau wrote:

> Hi Clément
>
> 2017-05-17 23:29 GMT+02:00 Clément Aubin <[hidden email]>:
>
>> 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 [hidden email]
>> More about us at http://www.xwiki.com
>>
>>
> Thanks
>
>

--
Clément Aubin
Web Developer Intern @XWiki SAS
[hidden email]
More about us at http://www.xwiki.com
Reply | Threaded
Open this post in threaded view
|

Re: [XWIKI-14119] Propositions about in-page notifications design

Guillaume Delhumeau
2017-05-18 10:34 GMT+02:00 Clément Aubin <[hidden email]>:

> On 05/18/2017 10:18 AM, Guillaume Delhumeau wrote:
> > Hi Clément
> >
> > 2017-05-17 23:29 GMT+02:00 Clément Aubin <[hidden email]>:
> >
> >> 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
> [hidden email]
> >> More about us at http://www.xwiki.com
> >>
> >>
> > Thanks
> >
> >
>
> --
> Clément Aubin
> Web Developer Intern @XWiki SAS
> [hidden email]
> More about us at http://www.xwiki.com
>



--
Guillaume Delhumeau ([hidden email])
Research & Development Engineer at XWiki SAS
Committer on the XWiki.org project
Reply | Threaded
Open this post in threaded view
|

Re: [XWIKI-14119] Propositions about in-page notifications design

Thomas Mortagne
Administrator
In reply to this post by Clément Aubin
On Thu, May 18, 2017 at 10:34 AM, Clément Aubin <[hidden email]> 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 <[hidden email]>:
>>
>>> 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 [hidden email]
>>> More about us at http://www.xwiki.com
>>>
>>>
>> Thanks
>>
>>
>
> --
> Clément Aubin
> Web Developer Intern @XWiki SAS
> [hidden email]
> More about us at http://www.xwiki.com



--
Thomas Mortagne
Reply | Threaded
Open this post in threaded view
|

Re: [XWIKI-14119] Propositions about in-page notifications design

Thomas Mortagne
Administrator
On Thu, May 18, 2017 at 2:11 PM, Thomas Mortagne
<[hidden email]> wrote:

> On Thu, May 18, 2017 at 10:34 AM, Clément Aubin <[hidden email]> 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 <[hidden email]>:
>>>
>>>> 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 [hidden email]
>>>> More about us at http://www.xwiki.com
>>>>
>>>>
>>> Thanks
>>>
>>>
>>
>> --
>> Clément Aubin
>> Web Developer Intern @XWiki SAS
>> [hidden email]
>> More about us at http://www.xwiki.com
>
>
>
> --
> Thomas Mortagne



--
Thomas Mortagne
Reply | Threaded
Open this post in threaded view
|

Re: [XWIKI-14119] Propositions about in-page notifications design

Clément Aubin
On 05/18/2017 02:17 PM, Thomas Mortagne wrote:

> On Thu, May 18, 2017 at 2:11 PM, Thomas Mortagne
> <[hidden email]> wrote:
>> On Thu, May 18, 2017 at 10:34 AM, Clément Aubin <[hidden email]> 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 <[hidden email]>:
>>>>
>>>>> 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
[hidden email]
More about us at http://www.xwiki.com
Reply | Threaded
Open this post in threaded view
|

Re: [XWIKI-14119] Propositions about in-page notifications design

vmassol
Administrator
In reply to this post by Clément Aubin
Hi,

> On 17 May 2017, at 23:29, Clément Aubin <[hidden email]> 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 [hidden email]
> More about us at http://www.xwiki.com
>

Reply | Threaded
Open this post in threaded view
|

Re: [XWIKI-14119] Propositions about in-page notifications design

Guillaume Delhumeau
2017-05-18 15:15 GMT+02:00 Vincent Massol <[hidden email]>:

> Hi,
>
> > On 17 May 2017, at 23:29, Clément Aubin <[hidden email]> 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 [hidden email]
> > More about us at http://www.xwiki.com
> >
>
>


--
Guillaume Delhumeau ([hidden email])
Research & Development Engineer at XWiki SAS
Committer on the XWiki.org project
Reply | Threaded
Open this post in threaded view
|

Re: [XWIKI-14119] Propositions about in-page notifications design

vmassol
Administrator
In reply to this post by Clément Aubin

> On 17 May 2017, at 23:29, Clément Aubin <[hidden email]> 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 [hidden email]
> More about us at http://www.xwiki.com
>

Reply | Threaded
Open this post in threaded view
|

Re: [XWIKI-14119] Propositions about in-page notifications design

Guillaume Delhumeau
2017-05-18 18:26 GMT+02:00 Vincent Massol <[hidden email]>:

>
> > On 17 May 2017, at 23:29, Clément Aubin <[hidden email]> 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 [hidden email]
> > More about us at http://www.xwiki.com
> >
>
>


--
Guillaume Delhumeau ([hidden email])
Research & Development Engineer at XWiki SAS
Committer on the XWiki.org project