polygene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kent Sølvsten <kent.soelvs...@gmail.com>
Subject Re: ZEST-23
Date Thu, 21 May 2015 09:47:20 GMT
Nope - iterating should not be a problem.

2 solutions are

for (var key in Object.keys(response)) {
  alert(key + '=' + response(key);
}

or

for (var key in response) {
  // excluding inherited properties
  if (response.hasOwnProperty(key)) {
    alert(key + '=' + response(key);
  }
}

(by the way I am not a browser guy, but has done some node.js work).

Is Paul's comment about preserving order relevant for other impls than
LinkedHashMap ?

/kent


Den 21-05-2015 kl. 11:28 skrev Niclas Hedhman:
> Kent,
> good to know someone has JS experience... ;-)
>
> So, iterating response in
>
> $.getJSON( "abc.json", null, function ( response )
> {
>
> } );
>
> without knowing the structure, is not an issue?
>
>
> For data preservation, I think the existing Migration mechanism can be
> used. I need to refresh my memory...
>
> // Niclas
>
> On Thu, May 21, 2015 at 5:15 PM, Kent Sølvsten <kent.soelvsten@gmail.com>
> wrote:
>
>> In javascript a map is simply a different way of accessing the r/w the
>> properties of an object.
>>
>> var map = {};
>> map["FirstName"] = ''Niclas";
>> map["LastName"] = "Hedhman";
>> var keys = Object.keys(map);  // ['Firstname', 'LastName']
>>
>> ending up as
>>
>> map : {
>>     "FirstName" : "Niclas",
>>     "LastName" : "Hedhman"
>> }
>> when serialized as JSon.
>>
>> So i would say that the second form is definitely the "natural" one.
>>
>> Could the implementation of migrations for stored data, possibly
>> combined with specifying some sort of "protocol version" be of some use?
>>
>> /Kent
>>
>>
>>
>> Den 21-05-2015 kl. 10:37 skrev Niclas Hedhman:
>>> I have been looking at this issue and I wonder if there are any notes
>> from
>>> the original implementation...
>>>
>>> For instance, a regular Map is serialized to
>>> map: [
>>>     { "key" : "FirstName", "value" : "Niclas" },
>>>     { "key" : "LastName", "value" : "Hedhman" }
>>> ]
>>> but it could have been made;
>>>
>>> map : {
>>>     "FirstName" : "Niclas",
>>>     "LastName" : "Hedhman"
>>> }
>>>
>>> My guess is that there is "schema" reasons for this. Also, it is not
>>> something that can now be changed, at least not without adding built-in
>>> handing of old format (which is a possibility).
>>>
>>> One of the usecases of this outside of the storage, would be using this
>>> serialization SPI for the toValue() and toEntity() methods, in which case
>>> the serialization would end up being processable in JavaScript.
>>>
>>> So, in that case, would it makes more sense to have "key"/"value", or to
>>> have Maps showing up as objects?? I am not that fluent in JavaScript to
>>> have an opinion. I can imagine that having the second/object form, is
>> neat
>>> when one knows what is coming over the wire, but could messy to iterate
>> as
>>> built-in attributes need to be filtered out. Or?
>>>
>>>
>>> // Niclas
>>>
>>> On Thu, May 21, 2015 at 7:55 AM, Niclas Hedhman <niclas@hedhman.org>
>> wrote:
>>>> Jiri,
>>>> thanks for your analysis of why it breaks.
>>>>
>>>> I assume that a JSON Object for NamedAssociation is the correct path
>>>> forward,
>>>>
>>>> {
>>>>     "left" : "723470239476",
>>>>     "right" : "109874275692"
>>>> }
>>>>
>>>> instead of the JSON Array which needs inner objects in that case,
>>>>
>>>> [
>>>>     { "left" : "723470239476" },
>>>>     { "right" : "109874275692" }
>>>> ]
>>>>
>>>> Paul, your thoughts?
>>>>
>>>> Cheers
>>>> --
>>>> Niclas Hedhman, Software Developer
>>>> http://zest.apache.org - New Energy for Java
>>>>
>>>
>>
>


Mime
View raw message