For some time I've been hacking the results of callbacks when date values are returned. Today as I'm refactoring some early code I decided to step through the REST response.
The underlying problem, why is a date field being converted to a string in the resopnse thereby forcing me to hack the value back to a valid date object in JavaScript.
The hack...
o.myDateField = moment(o.myDateField).toDate();
More background on what I'm doing on the server...
FUNCTION Callback()
loVendor = CREATEOBJECT('myVendors')
loResult = CREATEOBJECT('Empty')
loVendor.Load(1)
ADDPROPERTY(loResult,'vendor',loVendor.oData)
RETURN loResult
Mind you this is a very simple example and actually loResult ends up containing several more oData members. The Vendors table includes several DATE fields. They are all converted to STRING on the output. Here is the code I found is causing the issue.
First wwJSONSerializer gets called to do a WriteValue.
Then it preforms the following:
Ok this functionally seems to be by design as I discovered when I opened the Class and found where OutputDateType is set to zero.
This leaves me wondering if OutputDateType was set to 1 or 2 would I be breaking some other rule or causing problems elsewhere later on in the system since this is an undocumented property in Help.
Any advice...?
If it is possible to change the OutputDateType value at runtime, I would need to understand how to get to that property. I can't seem to expose it just before the RETURN in my function.
There is no date literal in JavaScript/JSON, so dates are always represented as a string. If you're using a JSON client on the client the date will not be translated back to a date by default (angular's serializer doesn't do it for example). There are workarounds for this by explicitly overriding the JSON parser.
However, the better solution really is to send formatted dates from the server. Before you return your results format the dates to the proper values you want to display on the client.
Sending back is not a problem because Web Connection will convert the date strings back into dates.
+++ Rick ---
Thanks, after re-reading your paper on dates, I also noticed in Aug. 2015 I posted a reply on that paper. Guess I'm losing my memory... I really don't recall ever having read it before! And the simple short answer is stick with what wroks - moment.js
I still think the best answer is - don't do dates in the front end, send them from the back end. Unless you need to send dates from the back end, modify on the front end and send back, it's simply easier to skip date manipulation on the client. Much less overhead, much less effort and 90% of the time you do one or the other but not both.
+++ Rick ---
Not completely clear the date comes back as a formatted string which moment(myStringDate).toDate() converts to a javaScript date.
In angualrJS the model needs a date type value when using an HTML5 type=Date control... (Maybe noit hte best control but I like it 😉
So on the client, I convert the stringDate to a javaScript date in the promiss of the callback. Then on the save, WC handles the convert for me.
If there was a way around the client conversion process, that would make the handling of data with dates much cleaner. But that does not seem possible.
Did you read the link I sent you? You can take over the JSON parser by effectively replacing the JSON.parse() method with the library I posted. By replacing it'll do to the date conversions.
ww.jquery.js actually includes that code. Include the library and then at the start of your application in app.init you do:
<script src="ww.jquery.min.js"></script>
<script>
// use date parser for all JSON.parse() requests
// make sure to call before any JSON conversions
JSON.useDateParser();
</script>
Now when you do any JSON parsing including Angular's (I think), the JSON date strings return as dates.
+++ Rick ---
I read the link but you pointed out a third party conflect might be possible and since my app is using momentjs, I read it to understand there might be an issue. But I will go back and try this suggestion as soon as I have time to also re-test my app in several locations where I work with dates.
As I said I haven't tried this with Angular so I'm not sure if it works with that because they may already be doing their own customization of the JSON parser. But I think it should work. It's pretty universal to use the JSON parser as is and then add additional handlers on top.
Moment is nice, but it's a beast - it's very large for the amount of functionality it provides. And again - unless you are editing previously entered dates I think you're almost always better off pre-formatting dates on the server and displaying the formatted dates in your UI.
+++ Rick ---