JSON, Cache and Date/Time
I have a Cache classes with %TimeStamp (e.g. 2016-04-18 12:29:11) and %Date (eg. 64027) properties. And I have a javascript client app, which needs full CRUD over this properties.
But in javascript date/time are defined by ISO8601 (e.g. timestamp 2016-04-18T12:29:11Z, date 2016-04-18).
Communication between a server and a client on a server side are done via following classes/methods:
- SQL → JSON via %ZEN.Auxiliary.jsonSQLProvider:%WriteJSONFromSQL
- Object → JSON via %ZEN.Auxiliary.jsonProvider:%WriteJSONFromObject
- JSON → Object via %ZEN.Auxiliary.jsonProvider:%ConvertJSONToObject
- Dynamic Object → JSON via %Library.AbstractObject:$toJSON
- JSON → Dynamic Object via %Library.AbstractObject:$fromJSON
The question is, how can I enable all this types of communication with:
- no work on a client side (client always receives/sends ISO8601 timestamp/date)
- minimum amount of work on a server side for each new property
Restrictions: I can't just use %String because Cache classes are also used by other Cache applications with SQL and object access and they may require ORDER BY date/time values, etc.
There are good options for what you want available in 2016.2, and possibly better answers for SQL -> JSON after that.
In 2016.2, %RegisteredObject also supports $toJSON and $fromJSON, so there won't be any need to use %ZEN.Auxiliary.jsonProvider to do that conversion. Under the hood, the path is really RegisteredObject -> Dynamic Object (via $compose) -> JSON, and JSON -> Dynamic Object -> RegisteredObject (via $compose)
Therefore, the behavior of $toJSON and $fromJSON can be modified for %RegisteredObject subclasses by overriding (typically) %ToDynamicObject and %FromObject. Here's an example that might serve as a useful starting point for Object -> JSON/JSON -> Object on 2016.2+:
The output of this is:
The matter of SQL -> JSON is a bit more complicated. ODBC select mode for SQL is similar to ISO 8601, but not completely (the timestamp format is different). One option would be to create a class (extending %RegisteredObject) to represent a query result with date/time fields in ISO 8601 format, and to override the same methods in it so that:
This could probably be done in 2016.2, but might be less work to accomplish in a future version when SQL result sets support $fromJSON/$toJSON. (I think this plan was mentioned in a different post.)
I suppose there are some possible complications with all this, depending on whether times/timestamps in your application are actually local or UTC. (Or worse, a mix...)