Dojo JSON serialization, using various serialization strategies - javascript

I have the issue with serializing inputs of DateTextBox and TimeTextBox to JSON - during serialization the timezone convertion is made, which forces me to send timezone to server and do appropriate adaptations there.
To prevent there I'd like to change the date format for serialization purposes. I can alter Date's prototype, as described here (I've done that in JSFiddle), but I'd prefer not to alter the behaviour for the scope of single request. Something like that:
someDojoUtil.jsonSerialize(obj, {option1: 'value1'...})
Does Dojo provide the way for achieving it, or the only way is to globally alter Date's prototype?

Based on comment elaboration in OP, I would use the second argument to Json.stringify, the so-called "replacer". Something like this:
require(['dojo/json'], function(Json) {
function replacer(key, value) {
if ('string' === typeof (value)) {
var d = new Date(value);
if (isNaN(d.getTime())) {
return value; // string, but not a date
}
// do whatever you want to do, this is just an example
d.setSeconds(0);
return d.toJSON();
}
return value;
}
var data = {'a':new Date(), 'b':123, 'c':'foo', 'd':[new Date()]};
var str = Json.stringify(data, replacer);
console.log(str);
});
I suggest writing this as a mixin for dojo/request, then creating yourself a custom request class that has this behavior, then using that custom request object as needed.
This feels hackish, but I think it will meet your need (as I'm understanding it!).

Related

Kotlin JavaScript Date.now() return type

I was wondering why the Kotlin JavaScript Date class returns a Double for the getTime function. According to the documentation, the getTime function should return the number of milliseconds since 1 January 1970 00:00:00 UTC.
I know that JS doesn't have a 64 bit numeric representation, but since Kotlin emulates Longs I feel like the value returned by Date.now() and Date().getTime() should be a Long. At the very least it would make more sense to return an Int.
Is there any reason that it returns a Double instead of a whole number?
There are two separate reasons for that: consistency and performance.
But before I get into that please note that you can easily get the desired behavior via extensions, e.g.:
inline val Date.time get() = getTime().toLong()
println(Date().time) // 1522757176433
Consistency. As you can see in the Date documentation page, it an external class. Which means it just describes an existing JavaScript API. Is it a good design decision to reuse it as it? Maybe not. But it has a benefit of being familiar to the JS folks. Changing the return type of a single function ruins that and makes the whole API quite inconsistent.
Performance. It is possible hide the original getTime and create a helper function instead. But keep in mind that in order to emulate Long Kotlin creates an object with 2 Number's. Creation, comparison, binary operations, storage - emulated Long's perform a lot worse than native JS Numbers.
Summing up. Changing the return type would make the API inconsistent and inefficient. If you value semantics over performance, just write a few helper functions.
P.S. I think the Date API will be redesigned at some point to make it possible to use it in multiplatform projects. But that's another story.
In kotlin use Date().time .It will return the long Values you will get whole number
val s= Date().time
print(s)
for example
val date = "01-02-2018 07:05:00.999"
val fmt = SimpleDateFormat("MM-dd-yyyy HH:mm:ss.S") //parse date based your format
var myDate: Date? = null
try {
myDate = fmt.parse(date)
} catch (e: ParseException) {
e.printStackTrace()
}
println(myDate)
val timestamp = myDate!!.time //timestamp values in long only not double
println(timestamp)

Parsing date in Json Encoded array

I have built a MVC site and I am passing in my model to the view and attempting to use it in some javascript in the view using:
var records = #Html.Raw(Json.Encode(Model));
I am aiming on using these records in a custom calendar object that accepts an object array as a datasource. However, the datasource expects date variables to know where to put appointments etc. I've read that Json does not have any date format of it's own. So, all the dates that are returned from the encode are formatted like:
/Date(1462921200000)/
The object doesn't seem to accept this and nothing is shown on the view. In the posts that I've read they have stated that you can parse the date back into the correct format but this seems to be only on individual values.
My question is: is there an easy way to take the encoded object I've got and parse the dates into the correct format? Or would I have to loop through them in order to do it?
Thanks.
Warning: This answer is opinionated.
The opinionated part is: when you need something done with Json, use Json.Net.
namespace System.Web.MVC
{
public static class HtmlHelperJsonExtensions
{
public string JsonEncode(this System.Web.MVC.HtmlHelper html, object o)
{
var jsonSettings = new Newtonsoft.Json.JsonSerializerSettings()
{
// Here you can apply a LOT of formatting, as a small example regarding dates:
// 1 - formats dates as iso strings (probably what you want)
DateFormatHandling = Newtonsoft.Json.DateFormatHandling.IsoDateFormat,
// 2 - formats dates with Microsoft format (what you're experiencing)
//DateFormatHandling = Newtonsoft.Json.DateFormatHandling.MicrosoftDateFormat,
// 3 - formats date in a custom format as for DateTime.ToString(string) overload
//DateFormatString = "yyyy-MM-dd"
Formatting = Indented
};
var json = Newtonsoft.Json.JsonConvert.SerializeObject(o, jsonSettings);
return html.Raw(json);
}
}
}
Usage:
var records = #Html.JsonEncode(Model);
Refer to the excellent Json.Net documentation here for insights.
Asp.Net MVC application return the dates in the ISO-8601 format by default.
You can convert the value in the client side with a function like this:
function ConvertDate(dateString) {
return new Date(parseInt(dateString.replace("/Date(", "").replace(")/", ""), 10));
}
Or you can use a library like momentjs (https://momentjs.com/docs/#/parsing/asp-net-json-date/):
moment("/Date(1198908717056-0700)/"); // 2007-12-28T23:11:57.056-07:00
Disclaimer: question was not identified as ASP.NET when I composed this answer. I presume the OP is asking for some feature provided by his yet to be disclosed framework. I keep the answer because I think it's valid for manual decoding in vanilla JavaScript.
The format can be parsed with a simple regular expression
var asText = "Date(1462921200000)";
var asDate = null;
var parsed = asText.match(/^Date\((\d+)\)$/);
if (parsed!==null) {
asDate = new Date(+parsed[1]);
}
console.log(asDate);

How to create a datetime object in javascript when using javascript remoteTK/remote toolkit

I am new to salesforce and I know my question sounds silly. But I need someone to tell me the direction I should go.
My question is how can I convert string or object like this
{Start_time__C:"2014-07-24T20:55:00.000+0000"}
and this
{perDiem: true}
into salesforce object. And then I can use create function in remoteTK.
I am currently building custom app on salesforce1. In my visualforce page, I need to create new record, which has datetime, and boolean as its fields.
Thank you in advance!
I don't know much about the remoteTK but before you deep dive into it you might want to look into the "Remote Objects" from Spring'14. This seems to be the new hip / official way of doing remoting (which doesn't mean I'm saying rTK is bad!) and slightly easier to use.
https://salesforce.stackexchange.com/questions/33072/visualforce-remote-objects
https://developer.salesforce.com/blogs/developer-relations/2014/03/spring-14-using-visualforce-remote-objects-with-canjs.html
http://andyinthecloud.com/2014/01/22/spring14-visualforce-remote-objects-introduction/
http://www.salesforce.com/us/developer/docs/pages/Content/pages_remote_objects_example_extended.htm
The main difference between them seems to be that you could use rTK in a non-visualforce page as underneath it just relies on REST callouts. The remote objects use a special VF tag so it's VF-only.
In the end I think it won't matter much which library you'll use. Sample remote object code:
// Create work order line item
var workOrderLineItem = new SObjectModel.WorkOrderLineItem__c();
workOrderLineItem.set('Description__c', 'Answering the question');
workOrderLineItem.set('Hours__c', answer);
workOrderLineItem.set('WorkOrder__c', result[0]);
workOrderLineItem.create(function(error, result, event)
{
// Errors?
if(error!=null)
alert(error);
else
alert('Success');
});
vs. the sample from remoteTK:
var objectType = 'Account';
var fields = {'Name': 'salesforce.com', 'Description':'CRM'};
client.create(objectType , fields,
function(response) {
getAccounts(function() {
$j.mobile.pageLoading(true);
$j.mobile.changePage('#mainpage', "slide", true, true);
});
}, errorCallback);
So a JavaScript object with fields is being created in both cases. For Booleans you should be good sending 'true' or 'false' strings.
For dates you might have to experiment a bit. Generally I've been passing Unix timestamp (miliseconds since Jan 1 1970), this seemed to work OK for me in REST calls or Visualforce Remoting (by which I mean #RemoteAction stuff, yet another tool).
The RemoteTKController.writeFields() seems to be using Date.valueOf(someString) when casting. This means the format should be 'yyyy-MM-dd HH:mm:ss' which is close enough - check if it will work out of the box and remove the timezone part from your string if it causes problems? You could simplify your examples a lot by skipping the remote part and directly check in Developer Console or Execute Anonymous how the parser reacts to different dates you'll feed it.
There's another function that seems to use REST API instead of the controller. This one will just pass the payload to REST API's POST request. Looking at how it's built you should be fine just passing a real JavaScript Date object as value, the JSON.stringify call should figure out how to serialize that. If you really want to craft the string yourself - check the REST API guide. The dates should look like that and all remoteTK'create call does is make a request similar to this one
This is an old thread, but in case it helps someone I was able to get this working. The yyyy-MM-dd HH:mm:ss format was very close. All it needed was a 'T' between the date and time to be acceptable. From there is was just making sure that all components came through as two digits, and converting the date to UTC time. Here's my final Javascript function:
function ConvertDate(dtin){
var d = new Date(dtin);
var convertdate = d.getUTCFullYear() + '-' + ('0' + (d.getUTCMonth()+1)).slice(-2) + '-' + ('0' + d.getUTCDate()).slice(-2) +'T' + ('0' + d.getUTCHours()).slice(-2)+':'+('0' + d.getUTCMinutes()).slice(-2)+':'+d.getUTCSeconds()+'0';
return convertdate;
}
From there I could pass the converted date to the sObject function without error.

JSON Date without eval?

Short description:
Is there a javascript JSON-converter out there that is able to preserve Dates and does not use eval?
Example:
var obj1 = { someInt: 1, someDate: new Date(1388361600000) };
var obj2 = parseJSON(toJSON(obj1));
//obj2.someDate should now be of type Date and not String
//(like in ordinary json-parsers).
Long description:
I think most people working with JSON already had the problem of how to transmit a Date:
var obj = { someInt: 1, someDate: new Date(1388361600000) }
When converting this to JSON and back, the date suddenly became a String:
JSON.parse(JSON.stringify(obj))
== { someInt: 1, someDate: "2013-12-30T00:00:00.000Z" }
This is a huge disadvantage since you cannot easily submit a Date using JSON. There is always some post-processing necessary (and you need to know where to look for the dates).
Then Microsoft found a loophole in the specification of JSON and - by convention - encodes a date as follows:
{"someInt":1,"someDate":"\/Date(1388361600000)\/"}
The brilliance in this is that there is a now a definitive way to tell a String from a Date inside a valid JSON-string: An encoded String will never contain the substring #"/" (a backslash followed by a slash, not to be confused with an escaped slash). Thus a parser that knows this convention can now safely create the Date-object.
If a parser does not know this convention, the date will just be parsed to the harmless and readable String "/Date(1388361600000)/".
The huge drawback is that there seems to be no parser that can read this without using eval. Microsoft proposes the following way to read this:
var obj = eval("(" + s.replace(/\"\\\/Date\((\d+)\)\\\/\"/g, function (match, time) { return "new Date(" + time + ")"; }) + ")");
This works like a charm: You never have to care about Dates in JSON anymore. But it uses the very unsafe eval-method.
Do you know any ready-to-use-parser that achieves the same result without using eval?
EDIT
There was some confusion in the comments about the advantages of the tweaked encoding.
I set up a jsFiddle that should make the intentions clear: http://jsfiddle.net/AJheH/
I disagree with adeno's comment that JSON is a notation for strings and cannot represent objects. Json is a notation for compound data types which must be in the form of a serialized objects, albeit that the primitive types can only be integer, float, string or bool. (update: if you've ever had deal with spaghetti coded XML, then you'll appreciate that maybe this is a good thing too!)
Presumably hungarian notation has lost favour with Microsoft if they now think that creating a non-standard notation incorporating the data type to describe a type is better idea.
Of itself 'eval' is not evil - it makes solving some problems a lot easier - but it's very difficult to implement good security while using it. Indeed it's disabled by default with a Content Security Policy.
IMHO it boils down to storing the date as 1388361600000 or "2013-12-30T00:00:00.000Z". IMHO the latter has significantly more semantic value - taken out of context it is clearly a date+time while the latter could be just about anything. Both can be parsed by the ECMAscript Date object without resorting to using eval. Yes this does require code to process the data - but what can you do with an sort of data without parsing it? he only time I can see this as being an advanage is with a schemaless database - but in fairness this is a BIG problem.
The issue is the following line of code, here is an example function and take a look at parseWithDate function, add the script to the page and change the following line to this it will work.
http://www.asp.net/ajaxlibrary/jquery_webforms_serialize_dates_to_json.ashx
var parsed1 = JSON.parse(s1); // changed to below
var parsed1 = JSON.parseWithDate(s1);
Updated jsFiddle that works http://jsfiddle.net/GLb67/1/

How to reliably hash JavaScript objects?

Is there a reliable way to JSON.stringify a JavaScript object that guarantees that the ceated JSON string is the same across all browsers, Node.js and so on, given that the JavaScript object is the same?
I want to hash JavaScript objects like
{
signed_data: object_to_sign,
signature: md5(JSON.stringify(object_to_sign) + secret_code)
}
and pass them around across web applications (e.g. Python and Node.js) and the user so that the user can authenticate against one service and show the next service "signed data" for that one to check if the data is authentic.
However, I came across the problem that JSON.stringify is not really unique across the implementations:
In Node.js / V8, JSON.stringify returns a JSON string without unnecessary whitespace, such as '{"user_id":3}.
Python's simplejson.dumps leaves some whitespace, e.g. '{"user_id": 3}'
Probably other stringify implementations might deal differently with whitespace, the order of attributes, or whatever.
Is there a reliable cross-platform stringify method? Is there a "nomalised JSON"?
Would you recommend other ways to hash objects like this?
UPDATE:
This is what I use as a workaround:
normalised_json_data = JSON.stringify(object_to_sign)
{
signed_data: normalised_json_data,
signature: md5(normalised_json_data + secret_code)
}
So in this approach, not the object itself, but its JSON representation (which is specific to the sigining platform) is signed. This works well because what I sign now is an unambiguous string and I can easily JSON.parse the data after I have checked the signature hash.
The drawback here is that if I send the whole {signed_data, signature} object as JSON around as well, I have to call JSON.parse twice and it does not look as nice because the inner one gets escaped:
{"signature": "1c3763890298f5711c8b2ea4eb4c8833", "signed_data": "{\"user_id\":5}"}
You might be interested in npm package object-hash, which seems to have a rather good activity & reliability level.
var hash = require('object-hash');
var testobj1 = {a: 1, b: 2};
var testobj2 = {b: 2, a: 1};
var testobj3 = {b: 2, a: "1"};
console.log(hash(testobj1)); // 214e9967a58b9eb94f4348d001233ab1b8b67a17
console.log(hash(testobj2)); // 214e9967a58b9eb94f4348d001233ab1b8b67a17
console.log(hash(testobj3)); // 4a575d3a96675c37ddcebabd8a1fea40bc19e862
This is an old question, but I thought I'd add a current solution to this question for any google referees.
The best way to sign and hash JSON objects now is to use JSON Web Tokens. This allows for an object to be signed, hashed and then verified by others based on the signature. It's offered for a bunch of different technologies and has an active development group.
You're asking for an implementation of something across multiple languages to be the same... you're almost certainly out of luck. You have two options:
check www.json.org implementations to see if they might be more standardized
roll your own in each language (use json.org implementations as a base and there should be VERY little work to do)
You could normalise the result of stringify() by applying rules such as:
remove unnecessary whitespace
sort attribute names in hashes
well-defined consistent quoting style
normalise string contents (so "\u0041" and "A" become the same)
This would leave you with a canonical JSON representation of your object, which you can then reliably hash.
After trying some hash algorithms and JSON-to-string methods, I found this to work the best (Sorry, it is typescript, can of course be rewritten to javascript):
// From: https://stackoverflow.com/questions/5467129/sort-javascript-object-by-key
function sortObjectKeys(obj){
if(obj == null || obj == undefined){
return obj;
}
if(typeof obj != 'object'){ // it is a primitive: number/string (in an array)
return obj;
}
return Object.keys(obj).sort().reduce((acc,key)=>{
if (Array.isArray(obj[key])){
acc[key]=obj[key].map(sortObjectKeys);
}
else if (typeof obj[key] === 'object'){
acc[key]=sortObjectKeys(obj[key]);
}
else{
acc[key]=obj[key];
}
return acc;
},{});
}
let xxhash64_ObjectToUniqueStringNoWhiteSpace = function(Obj : any)
{
let SortedObject : any = sortObjectKeys(Obj);
let jsonstring = JSON.stringify(SortedObject, function(k, v) { return v === undefined ? "undef" : v; });
// Remove all whitespace
let jsonstringNoWhitespace :string = jsonstring.replace(/\s+/g, '');
let JSONBuffer: Buffer = Buffer.from(jsonstringNoWhitespace,'binary'); // encoding: encoding to use, optional. Default is 'utf8'
return xxhash.hash64(JSONBuffer, 0xCAFEBABE, "hex");
}
It used npm module: https://cyan4973.github.io/xxHash/ , https://www.npmjs.com/package/xxhash
The benefits:
This is deterministic
Ignores key order (preserves array order)
Cross platform (if you can find equivalents for JSON-stringify)
JSON-stringify will hopefully will not get a different implementation and the whitespace removal will hopefully make it JSON-formatting independent.
64-bit
Hexadecimal string a result
Fastest (0.021 ms for 2177 B JSON, 2.64 ms for 150 kB JSON)
You may find bencode suitable for your needs. It's cross-platform, and the encoding is guaranteed to be the same from every implementation.
The downside is it doesn't support nulls or booleans. But that may be okay for you if you do something like transforming e.g., bools -> 0|1 and nulls -> "null" before encoding.

Categories