On 7/10/06, Chris Hostetter <[EMAIL PROTECTED]> wrote:
I'm confused ... it's always been very clear to me that a NamedList is
first and formost a "List" with ordering. it just so happens that it
allows for elements to be anotate with a name, and that items can be
looked up by their name (if they have one, and if they are the only
element in that list with that name).
I see it as either, depending on how it's used.
The problem is how we take existing NamedLists and map them to JSON.
If we have a NamedList [ "a"=1, "b"=2 ], we have a couple of options:
OPTION1, preserve names: {"a"=1, "b"=2}
OPTION2, preserve ordering: [1,2]
OPTION3, preserve both:[ {"a"=1}, {"b"=2} ]
The latter preserves both the names and the ordering by putting each
key in it's own map (yuck).
1) there is no reason why a JsonResponseWriter needs to treat
List/NamedList/Maps identically the way XmlResponseWriter does.
Agreed.
2) we should try to ensure that trivial parsing of the format of a
NamedList should preserve the order -- if we have to "lose information" in
the convertion, i would rather throw away the "name" for each item (and
treat the list as a JSON "array"
People will disagree on that one I am sure... NamedList is both like a
List and a Map, and some will want to use it either way.
Yonik: I'm curious how your current implementation deals with NamedLists
where no element has a name? .. or where some elements have no names, and
at least one element has "" as it's name?
Currnetly null is mapped to "", and then run through the normal
procedure to make sure that key hasn't been used before. So you could
end up with "" and " 1"
You don't get complete name preservation (but if that is what you
wanted, you wouldn't have been using NamedList without names)
Why not output NamedLists a JSON object?
??? I currently am... that's the problem. A JSON object is basically
a map, with no ordering semantics of it's keys.
Also, should we be at all concerned with the possibility that clients
might confuse a NamedList containing some names/values with a Document
containing fields/values ... should there be an "object type" member in
every object the JsonResponseWriter outputs?
I don't think so. JSON will have less type info... and that will be
fine for most uses since people know the semantics behind different
fields anyway.
: Other potential issues: would it be useful to be able to change the
: serialized format so that something like Ruby could do a direct eval()
: like JavaScript can? Might also want to have an option to use python
: unicode strings also ( u'my unicode string' )
those would be differnet ResponseWriters wouldn't they?
Yes, but the implementation could essentially be the same though
(change the separator in the JSON object, etc).
After going over this again, I think I'd be OK with option 3 for
NamedLists, because Maps and Documents can still use the cleaner
mapping to a single JSON object.
The remaining problem is that the top level of a QueryResponse is
modeled as a NamedList. Does order need to be preserved there?
Perhaps for the top level NamedList only, I should convert directly
into a JSON object (preserving the example mapping I gave), and all
other NamedLists could be the array-of-JSON objects?
-Yonik
