My name is Ismael Chang Ghalimi. I build the STOIC platform. I am a stoic, and this blog is my agora.
Victory! After days of epic bug fighting and stuborn resistance against the mere idea of conducting proper functional testing before making critical Git commits, the Tags field of Bootstrap is working again. We can all breathe a huge sigh of relief…
Why is it such a big deal? Because the Tags field is using the Tags datatype, which itself uses the JSON primitive. Up until now, the values of fields which datatype was using this primitive were serialized in plain text within our database (Elasticsearch). It was a quick and easy way of implementing this primitive in the early days, but it created some severe limitations, especially regarding the lookup of values within arrays and collections.
Fortunately, Elasticsearch provides native support for JSON structures, especially those that have a consistent schema across all records of the same object. Such is the case for the Tags datatypes, which is a simple array of strings. It’s also the case for advanced relationships, which are modeled as arrays of two key/value pairs (target object, target record).
Last week, Hugues and I decided that our quick and easy implementation of JSON primitive had run its course, and that native JSON mapping was overdue. Hugues worked on it, and delivered an implementation much faster than he had anticipated. He forgot to perform the minimum functional testing that would have been required to find a couple of trivial bugs though. A few email and Skype exchanges followed, and the bugs were eventually fixed, but without any functional testing to back it up. If I’m not going to do my fair share of unit testing, why should Hugues do any functional testing after all?
Hugues got lucky on this one, and his bravado (and talent) paid off.
Cheers mate!
PS: And as I’m writing all this, François is playing Daft Punk’s Get Lucky in the office…
Victory! After days of epic bug fighting and stuborn resistance against the mere idea of conducting proper functional testing before making critical Git commits, the Tags field of Bootstrap is working again. We can all breathe a huge sigh of relief…
Why is it such a big deal? Because the Tags field is using the Tags datatype, which itself uses the JSON primitive. Up until now, the values of fields which datatype was using this primitive were serialized in plain text within our database (Elasticsearch). It was a quick and easy way of implementing this primitive in the early days, but it created some severe limitations, especially regarding the lookup of values within arrays and collections.
Fortunately, Elasticsearch provides native support for JSON structures, especially those that have a consistent schema across all records of the same object. Such is the case for the Tags datatypes, which is a simple array of strings. It’s also the case for advanced relationships, which are modeled as arrays of two key/value pairs (target object, target record).
Last week, Hugues and I decided that our quick and easy implementation of JSON primitive had run its course, and that native JSON mapping was overdue. Hugues worked on it, and delivered an implementation much faster than he had anticipated. He forgot to perform the minimum functional testing that would have been required to find a couple of trivial bugs though. A few email and Skype exchanges followed, and the bugs were eventually fixed, but without any functional testing to back it up. If I’m not going to do my fair share of unit testing, why should Hugues do any functional testing after all?
Hugues got lucky on this one, and his bravado (and talent) paid off.
Cheers mate!
PS: And as I’m writing all this, François is playing Daft Punk’s Get Lucky in the office…

Victory! After days of epic bug fighting and stuborn resistance against the mere idea of conducting proper functional testing before making critical Git commits, the Tags field of Bootstrap is working again. We can all breathe a huge sigh of relief…

Why is it such a big deal? Because the Tags field is using the Tags datatype, which itself uses the JSON primitive. Up until now, the values of fields which datatype was using this primitive were serialized in plain text within our database (Elasticsearch). It was a quick and easy way of implementing this primitive in the early days, but it created some severe limitations, especially regarding the lookup of values within arrays and collections.

Fortunately, Elasticsearch provides native support for JSON structures, especially those that have a consistent schema across all records of the same object. Such is the case for the Tags datatypes, which is a simple array of strings. It’s also the case for advanced relationships, which are modeled as arrays of two key/value pairs (target object, target record).

Last week, Hugues and I decided that our quick and easy implementation of JSON primitive had run its course, and that native JSON mapping was overdue. Hugues worked on it, and delivered an implementation much faster than he had anticipated. He forgot to perform the minimum functional testing that would have been required to find a couple of trivial bugs though. A few email and Skype exchanges followed, and the bugs were eventually fixed, but without any functional testing to back it up. If I’m not going to do my fair share of unit testing, why should Hugues do any functional testing after all?

Hugues got lucky on this one, and his bravado (and talent) paid off.

Cheers mate!

PS: And as I’m writing all this, François is playing Daft Punk’s Get Lucky in the office…

The list of objects that you see on the Quick Create Shortcuts is now driven by a setting. Unfortunately, the setting is not being displayed properly by the Settings object because we’ve had a regression with the Dynamic datatype. Florian has been working on it for a couple hours trying to fix it. Stay tuned…
The list of objects that you see on the Quick Create Shortcuts is now driven by a setting. Unfortunately, the setting is not being displayed properly by the Settings object because we’ve had a regression with the Dynamic datatype. Florian has been working on it for a couple hours trying to fix it. Stay tuned…

The list of objects that you see on the Quick Create Shortcuts is now driven by a setting. Unfortunately, the setting is not being displayed properly by the Settings object because we’ve had a regression with the Dynamic datatype. Florian has been working on it for a couple hours trying to fix it. Stay tuned…

We just added a Cron datatype to deal with Cron schedules. These are used by the Schedules and Services object, and cron is such an arcane syntax that we really need a solid control for it. The datatype is there, but the control won’t be available before a few weeks.

Our new Dynamic datatype (Cf. earlier post) is starting to work, as you can see on the last two screenshots. One shows an Integer and the other a Boolean, for the exact same Value field. And when the dynamic datatype is undefined, as is the case for a configuration (a group of settings), the field is dynamically hidden.
Our new Dynamic datatype (Cf. earlier post) is starting to work, as you can see on the last two screenshots. One shows an Integer and the other a Boolean, for the exact same Value field. And when the dynamic datatype is undefined, as is the case for a configuration (a group of settings), the field is dynamically hidden.
Our new Dynamic datatype (Cf. earlier post) is starting to work, as you can see on the last two screenshots. One shows an Integer and the other a Boolean, for the exact same Value field. And when the dynamic datatype is undefined, as is the case for a configuration (a group of settings), the field is dynamically hidden.

Our new Dynamic datatype (Cf. earlier post) is starting to work, as you can see on the last two screenshots. One shows an Integer and the other a Boolean, for the exact same Value field. And when the dynamic datatype is undefined, as is the case for a configuration (a group of settings), the field is dynamically hidden.

As you can see on this screenshot, the Result field of the Functions object now supports the Dynamic datatype, which itself was configured with a Formula.js expression for specifying the dynamic datatype. Here is the expression we used for it

=stc_output.datatype

Unfortunately, I cannot show it to you, because our Field Options editor does not yet support Formula Field Options. We should be able to fix that by tomorrow hopefully, at which point the end-to-end scenario will be complete.

Victory! The Dynamic datatype is working, as you can see for the Value field of the Settings object. Next, we’re going to add support for Formula.js expressions within Field Options so that Field Options themselves could be dynamic. This will be used to properly implement the Result field of the Functions object. More on this very soon…
Victory! The Dynamic datatype is working, as you can see for the Value field of the Settings object. Next, we’re going to add support for Formula.js expressions within Field Options so that Field Options themselves could be dynamic. This will be used to properly implement the Result field of the Functions object. More on this very soon…

Victory! The Dynamic datatype is working, as you can see for the Value field of the Settings object. Next, we’re going to add support for Formula.js expressions within Field Options so that Field Options themselves could be dynamic. This will be used to properly implement the Result field of the Functions object. More on this very soon…

New Datatypes are few and far between nowadays, but yesterday we felt compelled to add one. It’s called Dynamic, and as its name implies, it is used to implement fields that capture values which datatypes are not known in advance and can change from one record to another for the very same field.

Who needs that are you asking? Well, not very many people indeed. Nevertheless, we had three perfectly valid use cases that called for it. First, the Default value field of the Fields object, which datatype should be the datatype of the field, which can be different from one record of the Fields object to another. Second, the Value field of the Settings object (Cf. previous post). Third, the Result field of the Functions object, which captures the expected result of a default automated test for a Formula.js function.

This datatype is defined with three options:

  • Datatype, which references a field of the object defining the dynamic datatype
  • Datatype reference, which stores a Formula.js expression to dynamically define the datatype
  • Options, which references a field of the object defining the options of the datatype

Internally to the system, this datatype is implemented using the String primitive, which is the most generic one, and onto which any datatype can be mapped without any data loss. And from a user interface standpoint, we’ve added a new control that dynamically displays the right control for the datatype associated to a particular field value (the value of a field for a particular record).

This all might seem pretty complex, but the use cases that are using this new datatype could not be properly implemented in any simpler fashion. In fact, we’ve been trying to avoid the issue for a while, but as we’re getting closer to making our first beta release, we realized that Settings had to be improved. In the past, they were defined using the JSON datatype, for which no user-friendly control can be developed. We also realized that we needed to improve the way default values are defined for fields. And the straw that broke the camel’s back was when Hannes started to add test cases to the Functions object. So we decided to bite the bullet and do it right.

Florian should be done with the Dynamic Control later today…

We now have 66 datatypes…

We just completed the implementation of the Rating datatype. It allows you to add rating fields to any object, to capture ratings on a per-user basis, to display average rating values, and to configure the number of levels (stars) for rating fields individually. From an implementation standpoint, individual ratings are stored using the Rating object.
We just completed the implementation of the Rating datatype. It allows you to add rating fields to any object, to capture ratings on a per-user basis, to display average rating values, and to configure the number of levels (stars) for rating fields individually. From an implementation standpoint, individual ratings are stored using the Rating object.
We just completed the implementation of the Rating datatype. It allows you to add rating fields to any object, to capture ratings on a per-user basis, to display average rating values, and to configure the number of levels (stars) for rating fields individually. From an implementation standpoint, individual ratings are stored using the Rating object.
We just completed the implementation of the Rating datatype. It allows you to add rating fields to any object, to capture ratings on a per-user basis, to display average rating values, and to configure the number of levels (stars) for rating fields individually. From an implementation standpoint, individual ratings are stored using the Rating object.

We just completed the implementation of the Rating datatype. It allows you to add rating fields to any object, to capture ratings on a per-user basis, to display average rating values, and to configure the number of levels (stars) for rating fields individually. From an implementation standpoint, individual ratings are stored using the Rating object.