Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Date Serialisation #15

Open
olly opened this issue Nov 3, 2010 · 6 comments
Open

Date Serialisation #15

olly opened this issue Nov 3, 2010 · 6 comments

Comments

@olly
Copy link
Contributor

olly commented Nov 3, 2010

I was playing with js-model over the weekend and dates in models don't work as I expected they would. Objects with properties set as dates get serialised to strings and the when the object is parsed from localstorage it returns a string.

I had a quick look into the problem and it seems like a custom replacer callback for the JSON.parse and JSON.stringify is needed to fix this.

@benpickles
Copy link
Owner

i was wondering when this would come up :)

it could be as simple as enabling the encode/decode methods on the various persistence adapters to be configurable and defaulting them to JSON.stringify and JSON.parse - i could be wrong but from a brief search there don't appear to be many people actually using this technique?

in the meantime you could define an initialize instance method on the model to manually convert the string (should be ISO 8601) attribute back into a javascript date object - http://benpickles.github.com/js-model/#initialize. i don't have a function for that right now but if you get a good one could you post it here?

thanks :p

ben

@olly
Copy link
Contributor Author

olly commented Nov 4, 2010

I did a quick spike: https://gist.github.com/663286 It seems like there are two easy-ish ways to do it.

The string matching way is to look at each string value and work out whether it looks like a ISO8601 date. If so turn it into a date. This seems like (no benchmarks, just guessing) it would be expensive as we match against all string values.

The second way, key matching, is to define a list of keys for a model that are dates and then we just compare the keys and for any key that should be a date we try and convert it to one.

Any preference? Should this be part of js-model or should we leave it to each individual app to make a choice and just provide the appropriate hooks into the JSON methods.

@benpickles
Copy link
Owner

ooo that looks nasty. would be nice if it was part of js-model. that reminds me, i have an attribute type coercion branch that i did ages ago. i'll have to dig it out and give it a push.

@benpickles
Copy link
Owner

actually it doesn't look that bad but would still be nice to be part of js-model.

@olly
Copy link
Contributor Author

olly commented Nov 5, 2010

This library looks like it might be good to pull in and do the date parsing. Seems a little better structured than that code I just pulled off Google https://github.com/tardate/rfc3339date.js

If you give me some idea of an ideal API, I'll try and have a stab at it over the weekend.

@benpickles
Copy link
Owner

i've pushed a branch with the attribute coercion - https://github.com/benpickles/js-model/compare/attribute-coercion. however, don't think of it as an example of an ideal api just something that works (hence i hadn't pushed it until now).

it might be nice to separate the coercion methods into another module with some default types and which you could add your own to:

// default integer coercion
Model.Coerce.integer = function(value) {
  return parseInt(value)
}

// custom
Model.Coerce.zeroPaddedInteger = function(value) {
  ...
}

they could then be called without too much knowledge like:

Model.Coerce[attribute_type](attribute_value)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants