Thanks Mic. Sorry I wasn't around earlier - schedule has gone massively late
again (and I'm probably offline thurs).
I'm not an LSL expert, but I think the classic 'LSL' way to do this would be to
return a strided list [1].
Maybe something like
JsonGetValues(key storeID, string path):list
JsonGetValuesJson(key storeID, string path):list
So
list stridedVals = JsonGetValues(storeID, "foo[*].bar");
to get something like
["foo[0].bar", "hello", "foo[1].bar", "world", ... ]
Then one can use functions like llList2ListStrided to get just the values as
desired, e.g.
list result_a = llList2ListStrided(stridedVals, 0, -1, 2);
// result_a == [ "hello", "world" ]
In this way, maybe one could even return the deeper structure by listing the full key for each value rather than the
return serialized approach of the *Json() functions. Maybe this could be signalled as via an optional constant int
flags field (in the same LSL way that things like osNpcCreate() take options).
Strided lists are pretty horrible but at least people are familiar with them and there are various functions to help
with handling them. I guess it's the only way to get any semblance of nested data structures in LSL.
Also, a couple of other questions, which might just be due to my ignorance of not having looked at the code deeply
enough yet.
* I see there are many parallel *Json methods such as JsonGetValueJson(). I presume the natural way to parse serialized
json returned from those (if one wanted) would be to temporarily create a store and then remove it?
* Is the 'JPath' implementation the one at [2] or perhaps the one at [3] or something else entirely? How much of these
'specifications' is currently implemented?
[1] http://wiki.secondlife.com/wiki/Category:LSL_List#Strided_lists
[2] http://goessner.net/articles/JsonPath/
[3] http://projects.plural.cc/projects/jsonij/wiki/JPath
On 30/01/13 22:48, Mic Bowman wrote:
Done.
On Wed, Jan 30, 2013 at 8:57 AM, Mic Bowman <[email protected]
<mailto:[email protected]>> wrote:
I think that would be very useful. I can add it this afternoon, if you
don't beat me to it.
When I wrote the interface to the Json store, I modeled the path expansion
after JQuery interface. However, I'm
finding that really challenging to use for iterating through an array of
values. Right now, I use osFormatString to
create the path dynamically. For example:
integer i = 0;
while (i < 10)
{
string p = osFormatString("foo[{0}].bar",[i]); // create path
"foo[0].bar"
string v = JsonGetValue(storeID,p);
}
If you have any suggestions for a construct that would make the iteration
cleaner, I would be very interested. I've
bounced around (and written some test code) for taking a list (the
components of the path) as an argument, but
constructing the list is no easier than constructing the string. I've also
poked around with creating store handles
that point into an existing store (so you resolve the path "foo" into a
store handle then iterate at the top level).
Again, the code to walk through the structure is still excessively complex.
--mic
On Tue, Jan 29, 2013 at 10:03 PM, Justin Clark-Casey <[email protected]
<mailto:[email protected]>> wrote:
Hi Mic. Whilst looking through these functions tonight, it struck me
that there doesn't appear to be a way to
tell if a certain JSON store still exists, as identified by its key.
Do you think it would be appropriate to add a function for that?
Perhaps JsonTestStore(), which is in keeping
with JsonTestPath()?
--
Justin Clark-Casey (justincc)
OSVW Consulting
http://justincc.org
http://twitter.com/justincc
_________________________________________________
Opensim-dev mailing list
[email protected] <mailto:[email protected]>
https://lists.berlios.de/__mailman/listinfo/opensim-dev
<https://lists.berlios.de/mailman/listinfo/opensim-dev>
_______________________________________________
Opensim-dev mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/opensim-dev
--
Justin Clark-Casey (justincc)
OSVW Consulting
http://justincc.org
http://twitter.com/justincc
_______________________________________________
Opensim-dev mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/opensim-dev
