You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
On one hand, you could argue that the actual string parsing should usually be handled outside of the cfjson package. Sometimes that's actually required, for example when dealing with paged output like the observations API currently provides (list of cfjson objects vs. a single cfjson object). But on the other hand, there's probably many cases where it would be convenient to have everything handled by a single call. Off the top of my head I'm not sure whether the "standard" cfjson packages have all the functionality we need?
Could we just check for str / unicode (buffer? file? anything else?) in all the import functions / methods, and otherwise assume the input is alread a dictionary?
The text was updated successfully, but these errors were encountered:
On one hand, you could argue that the actual string parsing should usually be handled outside of the cfjson package. Sometimes that's actually required, for example when dealing with paged output like the observations API currently provides (list of cfjson objects vs. a single cfjson object). But on the other hand, there's probably many cases where it would be convenient to have everything handled by a single call. Off the top of my head I'm not sure whether the "standard" cfjson packages have all the functionality we need?
Could we just check for str / unicode (buffer? file? anything else?) in all the import functions / methods, and otherwise assume the input is alread a dictionary?
The text was updated successfully, but these errors were encountered: