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 <[email protected]> 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é <[email protected]> > 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é >> [email protected] >> http://blog.nanthrax.net >> Talend - http://www.talend.com >> >
