You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@unomi.apache.org by Thomas Draier <td...@jahia.com> on 2016/04/08 11:39:21 UTC
custom condition types
Hi,
I was thinking of some possible improvements on the condition types, to
make them more flexible.
Currently, condition types are defined in unomi plugins - they are read
from a json inside a plugin bundle, and then loaded into memory. Some of
the base conditions rely on actual java code, so it make sense to put them
into a bundle - but other some other conditions are only simple combination
of other conditions, and are usually very specific to a domain. An end user
may want to create his own condition using simple JSON definition, and may
not want to develop and deploy a bundle just for that. It would be nice to
be able to add new condition types by simply using REST API.
If you look at the pageViewEventCondition - it is only based on simple
boolean and property conditions, and is very specific to the type of events
that will be sent by a third party server. They should get out of default
unomi installation, and rather be created directly by the server that will
send these events.
Allowing to create/edit conditions will of course require to persist them,
and so require some changes in the ConditionType object, changing from
"PluginType" to "Item", and the way they are read by the definitions
service.
What do you think ?
thomas
Re: custom condition types
Posted by Clément,
Jahia <ce...@jahia.com>.
I do agree
2016-04-08 12:36 GMT+02:00 Serge Huber <sh...@jahia.com>:
> I think this could indeed be a good idea :)
>
> cheers,
> Serge…
>
> > On 8 avr. 2016, at 11:39, Thomas Draier <td...@jahia.com> wrote:
> >
> > Hi,
> >
> > I was thinking of some possible improvements on the condition types, to
> > make them more flexible.
> > Currently, condition types are defined in unomi plugins - they are read
> > from a json inside a plugin bundle, and then loaded into memory. Some of
> > the base conditions rely on actual java code, so it make sense to put
> them
> > into a bundle - but other some other conditions are only simple
> combination
> > of other conditions, and are usually very specific to a domain. An end
> user
> > may want to create his own condition using simple JSON definition, and
> may
> > not want to develop and deploy a bundle just for that. It would be nice
> to
> > be able to add new condition types by simply using REST API.
> > If you look at the pageViewEventCondition - it is only based on simple
> > boolean and property conditions, and is very specific to the type of
> events
> > that will be sent by a third party server. They should get out of default
> > unomi installation, and rather be created directly by the server that
> will
> > send these events.
> > Allowing to create/edit conditions will of course require to persist
> them,
> > and so require some changes in the ConditionType object, changing from
> > "PluginType" to "Item", and the way they are read by the definitions
> > service.
> > What do you think ?
> > thomas
>
>
--
Clément Egger
Senior Vice President, Product Marketing
M +33 688 190 579
8 rue du Sentier | 75002 Paris | France
jahia.com <http://www.jahia.com/>
SKYPE | TWITTER <https://twitter.com/theklem> | VCARD
<http://www.jahia.com/vcard/EggerClement.vcf>
Re: custom condition types
Posted by Serge Huber <sh...@jahia.com>.
I think this could indeed be a good idea :)
cheers,
Serge…
> On 8 avr. 2016, at 11:39, Thomas Draier <td...@jahia.com> wrote:
>
> Hi,
>
> I was thinking of some possible improvements on the condition types, to
> make them more flexible.
> Currently, condition types are defined in unomi plugins - they are read
> from a json inside a plugin bundle, and then loaded into memory. Some of
> the base conditions rely on actual java code, so it make sense to put them
> into a bundle - but other some other conditions are only simple combination
> of other conditions, and are usually very specific to a domain. An end user
> may want to create his own condition using simple JSON definition, and may
> not want to develop and deploy a bundle just for that. It would be nice to
> be able to add new condition types by simply using REST API.
> If you look at the pageViewEventCondition - it is only based on simple
> boolean and property conditions, and is very specific to the type of events
> that will be sent by a third party server. They should get out of default
> unomi installation, and rather be created directly by the server that will
> send these events.
> Allowing to create/edit conditions will of course require to persist them,
> and so require some changes in the ConditionType object, changing from
> "PluginType" to "Item", and the way they are read by the definitions
> service.
> What do you think ?
> thomas
Re: custom condition types
Posted by Serge Huber <sh...@jahia.com>.
Hmm… I struggled with that in initial designs.
I think we might be possible to maybe created some kind of i18n marker to a resource or something ? The problem is that (for the moment) we haven’t addressed any i18n stuff in the spec, so we’ll have to see how we can handle that (although for the moment condition types are not really a part of it either).
If we provide the possibility for condition types to be internationalized, we’ll have to also think about automated / manual translation, as very often it is not the same people doing the condition type design and the UI translation. So maybe we would need some kind of system that would work with resources and uses OSGi fragments to deploy translations ?
cheers,
Serge…
> On 13 avr. 2016, at 14:57, Thomas Draier <td...@jahia.com> wrote:
>
> Ok,
> Working on this task, I have the issue that I cannot have
> "internationalized" data in stored items (yet), but right now condition
> types do have translation for names/descriptions handled by resource
> bundles. So - either we drop the support for any translation inside Unomi
> and let all clients handle that somehow, or we add an (optional) attribute
> for names/description per language in the metadata object. In my opinion it
> would make more sense to handle that on unomi side, as any end user can
> create new condition types - it would be nice if he's able to store
> translations for the items he creates. Any opinion ?
>
>
> On Wed, Apr 13, 2016 at 1:30 PM Thomas Draier <td...@jahia.com> wrote:
>
>> Ok, I'll create a ticket and start working on that.
>>
>> thomas
>>
>>
>> On Sat, Apr 9, 2016 at 9:18 PM Jean-Baptiste Onofré <jb...@nanthrax.net>
>> wrote:
>>
>>> +1
>>>
>>> It sounds good to me.
>>>
>>> Regards
>>> JB
>>>
>>> On 04/08/2016 11:39 AM, Thomas Draier wrote:
>>>> Hi,
>>>>
>>>> I was thinking of some possible improvements on the condition types, to
>>>> make them more flexible.
>>>> Currently, condition types are defined in unomi plugins - they are read
>>>> from a json inside a plugin bundle, and then loaded into memory. Some of
>>>> the base conditions rely on actual java code, so it make sense to put
>>> them
>>>> into a bundle - but other some other conditions are only simple
>>> combination
>>>> of other conditions, and are usually very specific to a domain. An end
>>> user
>>>> may want to create his own condition using simple JSON definition, and
>>> may
>>>> not want to develop and deploy a bundle just for that. It would be nice
>>> to
>>>> be able to add new condition types by simply using REST API.
>>>> If you look at the pageViewEventCondition - it is only based on simple
>>>> boolean and property conditions, and is very specific to the type of
>>> events
>>>> that will be sent by a third party server. They should get out of
>>> default
>>>> unomi installation, and rather be created directly by the server that
>>> will
>>>> send these events.
>>>> Allowing to create/edit conditions will of course require to persist
>>> them,
>>>> and so require some changes in the ConditionType object, changing from
>>>> "PluginType" to "Item", and the way they are read by the definitions
>>>> service.
>>>> What do you think ?
>>>> thomas
>>>>
>>>
>>> --
>>> Jean-Baptiste Onofré
>>> jbonofre@apache.org
>>> http://blog.nanthrax.net
>>> Talend - http://www.talend.com
>>>
>>
Re: custom condition types
Posted by Thomas Draier <td...@jahia.com>.
Ok,
Working on this task, I have the issue that I cannot have
"internationalized" data in stored items (yet), but right now condition
types do have translation for names/descriptions handled by resource
bundles. So - either we drop the support for any translation inside Unomi
and let all clients handle that somehow, or we add an (optional) attribute
for names/description per language in the metadata object. In my opinion it
would make more sense to handle that on unomi side, as any end user can
create new condition types - it would be nice if he's able to store
translations for the items he creates. Any opinion ?
On Wed, Apr 13, 2016 at 1:30 PM Thomas Draier <td...@jahia.com> wrote:
> Ok, I'll create a ticket and start working on that.
>
> thomas
>
>
> On Sat, Apr 9, 2016 at 9:18 PM Jean-Baptiste Onofré <jb...@nanthrax.net>
> wrote:
>
>> +1
>>
>> It sounds good to me.
>>
>> Regards
>> JB
>>
>> On 04/08/2016 11:39 AM, Thomas Draier wrote:
>> > Hi,
>> >
>> > I was thinking of some possible improvements on the condition types, to
>> > make them more flexible.
>> > Currently, condition types are defined in unomi plugins - they are read
>> > from a json inside a plugin bundle, and then loaded into memory. Some of
>> > the base conditions rely on actual java code, so it make sense to put
>> them
>> > into a bundle - but other some other conditions are only simple
>> combination
>> > of other conditions, and are usually very specific to a domain. An end
>> user
>> > may want to create his own condition using simple JSON definition, and
>> may
>> > not want to develop and deploy a bundle just for that. It would be nice
>> to
>> > be able to add new condition types by simply using REST API.
>> > If you look at the pageViewEventCondition - it is only based on simple
>> > boolean and property conditions, and is very specific to the type of
>> events
>> > that will be sent by a third party server. They should get out of
>> default
>> > unomi installation, and rather be created directly by the server that
>> will
>> > send these events.
>> > Allowing to create/edit conditions will of course require to persist
>> them,
>> > and so require some changes in the ConditionType object, changing from
>> > "PluginType" to "Item", and the way they are read by the definitions
>> > service.
>> > What do you think ?
>> > thomas
>> >
>>
>> --
>> Jean-Baptiste Onofré
>> jbonofre@apache.org
>> http://blog.nanthrax.net
>> Talend - http://www.talend.com
>>
>
Re: custom condition types
Posted by Thomas Draier <td...@jahia.com>.
Ok, I'll create a ticket and start working on that.
thomas
On Sat, Apr 9, 2016 at 9:18 PM Jean-Baptiste Onofré <jb...@nanthrax.net> wrote:
> +1
>
> It sounds good to me.
>
> Regards
> JB
>
> On 04/08/2016 11:39 AM, Thomas Draier wrote:
> > Hi,
> >
> > I was thinking of some possible improvements on the condition types, to
> > make them more flexible.
> > Currently, condition types are defined in unomi plugins - they are read
> > from a json inside a plugin bundle, and then loaded into memory. Some of
> > the base conditions rely on actual java code, so it make sense to put
> them
> > into a bundle - but other some other conditions are only simple
> combination
> > of other conditions, and are usually very specific to a domain. An end
> user
> > may want to create his own condition using simple JSON definition, and
> may
> > not want to develop and deploy a bundle just for that. It would be nice
> to
> > be able to add new condition types by simply using REST API.
> > If you look at the pageViewEventCondition - it is only based on simple
> > boolean and property conditions, and is very specific to the type of
> events
> > that will be sent by a third party server. They should get out of default
> > unomi installation, and rather be created directly by the server that
> will
> > send these events.
> > Allowing to create/edit conditions will of course require to persist
> them,
> > and so require some changes in the ConditionType object, changing from
> > "PluginType" to "Item", and the way they are read by the definitions
> > service.
> > What do you think ?
> > thomas
> >
>
> --
> Jean-Baptiste Onofré
> jbonofre@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>
Re: custom condition types
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
+1
It sounds good to me.
Regards
JB
On 04/08/2016 11:39 AM, Thomas Draier wrote:
> Hi,
>
> I was thinking of some possible improvements on the condition types, to
> make them more flexible.
> Currently, condition types are defined in unomi plugins - they are read
> from a json inside a plugin bundle, and then loaded into memory. Some of
> the base conditions rely on actual java code, so it make sense to put them
> into a bundle - but other some other conditions are only simple combination
> of other conditions, and are usually very specific to a domain. An end user
> may want to create his own condition using simple JSON definition, and may
> not want to develop and deploy a bundle just for that. It would be nice to
> be able to add new condition types by simply using REST API.
> If you look at the pageViewEventCondition - it is only based on simple
> boolean and property conditions, and is very specific to the type of events
> that will be sent by a third party server. They should get out of default
> unomi installation, and rather be created directly by the server that will
> send these events.
> Allowing to create/edit conditions will of course require to persist them,
> and so require some changes in the ConditionType object, changing from
> "PluginType" to "Item", and the way they are read by the definitions
> service.
> What do you think ?
> thomas
>
--
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
Re: custom condition types
Posted by Quentin Lamerand <ql...@jahia.com>.
As you already know, I completely agree.
On Fri, Apr 8, 2016 at 11:39 AM Thomas Draier <td...@jahia.com> wrote:
> Hi,
>
> I was thinking of some possible improvements on the condition types, to
> make them more flexible.
> Currently, condition types are defined in unomi plugins - they are read
> from a json inside a plugin bundle, and then loaded into memory. Some of
> the base conditions rely on actual java code, so it make sense to put them
> into a bundle - but other some other conditions are only simple combination
> of other conditions, and are usually very specific to a domain. An end user
> may want to create his own condition using simple JSON definition, and may
> not want to develop and deploy a bundle just for that. It would be nice to
> be able to add new condition types by simply using REST API.
> If you look at the pageViewEventCondition - it is only based on simple
> boolean and property conditions, and is very specific to the type of events
> that will be sent by a third party server. They should get out of default
> unomi installation, and rather be created directly by the server that will
> send these events.
> Allowing to create/edit conditions will of course require to persist them,
> and so require some changes in the ConditionType object, changing from
> "PluginType" to "Item", and the way they are read by the definitions
> service.
> What do you think ?
> thomas
>
Re: custom condition types
Posted by Christophe Laprun <cl...@jahia.com>.
+1 on my side as well.
> On 08 Apr 2016, at 11:39, Thomas Draier <td...@jahia.com> wrote:
>
> Hi,
>
> I was thinking of some possible improvements on the condition types, to
> make them more flexible.
> Currently, condition types are defined in unomi plugins - they are read
> from a json inside a plugin bundle, and then loaded into memory. Some of
> the base conditions rely on actual java code, so it make sense to put them
> into a bundle - but other some other conditions are only simple combination
> of other conditions, and are usually very specific to a domain. An end user
> may want to create his own condition using simple JSON definition, and may
> not want to develop and deploy a bundle just for that. It would be nice to
> be able to add new condition types by simply using REST API.
> If you look at the pageViewEventCondition - it is only based on simple
> boolean and property conditions, and is very specific to the type of events
> that will be sent by a third party server. They should get out of default
> unomi installation, and rather be created directly by the server that will
> send these events.
> Allowing to create/edit conditions will of course require to persist them,
> and so require some changes in the ConditionType object, changing from
> "PluginType" to "Item", and the way they are read by the definitions
> service.
> What do you think ?
> thomas
Christophe Laprun
Senior Software Engineer
8 rue du Sentier | 75002 Paris | France
jahia.com <http://www.jahia.com/>
SKYPE <skype:chris.laprun?add> | LINKEDIN <https://www.linkedin.com/in/chrislaprun> | TWITTER <https://twitter.com/metacosm> | VCARD <http://www.jahia.com/vcard/LaprunChristophe.vcf>
> JOIN OUR COMMUNITY <http://www.jahia.com/> to evaluate, get trained and to discover why Jahia is a leading User Experience Platform (UXP) for Digital Transformation.