Maybe it would be good to submit that to the opensocial spec list? I
bet there will be hundreds of developers who will follow suit here :)
(i guess a opensocial-0.7 compatibility wrapper could map single form
to the plural form?)
On Apr 16, 2008, at 3:24 PM, Cassie wrote:
lol. that's hilarious. it's really a typo in the spec itself, but
alas, the spec is what we follow.
thanks for the patch i submitted it to the opensocial-resources svn
just now.
On Wed, Apr 16, 2008 at 2:59 PM, Raymond Auge <[EMAIL PROTECTED]>
wrote:
As it turns out, after much scouring of the shindig codebase, I
realized to
my chagrin that the problem is that the compliancetests.xml (from
code.google.com) is NOT compliant. In fact it has a small bug which
caused
the problem.
See Patch attached.
Ray
On Wed, 2008-04-16 at 11:12 +0200, Cassie wrote:
Okay, best bet is to file a jira issue and we can look into it.
I'll see if I can find it now...
On Tue, Apr 15, 2008 at 11:22 PM, Raymond Auge <[EMAIL PROTECTED]>
wrote:
The problem is even if I specify the fields to return:
personOpts
[opensocial.DataRequest.PeopleRequestFields.PROFILE_DETAILS] =
[opensocial.Person.Field.AGE,
opensocial.Person.Field.NAME,
opensocial.Person.Field.GENDER,
opensocial.Person.Field.PROFILE_URL,
opensocial.Person.Field.THUMBNAIL_URL,
opensocial.Person.Field.STATUS];
I only ever get a Set<String> profileDetails which contains:
["id","name","thumbnailUrl"]
Ray
On Tue, 2008-04-15 at 17:12 -0400, Raymond Auge wrote:
This is not using the sample backend... it's using a custom
implementation... the problem is that
["id","name","thumbnailUrl"]
are the only fields ever requested.
Set<String> profileDetails only ever contains those three
items... of
course if I add the fields explicitly they are available, but
that isn't
really what the problem is...
Ray
On Tue, 2008-04-15 at 23:07 +0200, Chris Chabot wrote:
The basic samplecontainer xml file has no data in those fields,
and if
the field is empty (null) it's not included in the json thats
returned.
If you'd open the xml file & added those fields, the warning
would go
away :)
-- Chris
On Apr 15, 2008, at 10:59 PM, Raymond Auge wrote:
If I add more supported fields to syndicators.js
e.g.
"person" : ["id", "name", "profileUrl", "thumbnailUrl",
"nickname", "emails", "gender", "phoneNumbers", "timeZone"],
when I run the compliancetest.xml (which seems to pass all the
supported
Fields in the request) I get:
Your object did not have a result for the nickname field. This
may be
confusing for users.
...
even though the backend does support it... seems that the fields
never
are passed in the request:
e.g.
[{"type":"FETCH_PEOPLE","idSpec":"OWNER","profileDetail":
["id
","name
","thumbnailUrl
"],"sortOrder":"topFriends","filter":"all","first":
0,"max":20},
{"type":"FETCH_PEOPLE","idSpec":"VIEWER","profileDetail":
["id
","name
","thumbnailUrl
"],"sortOrder":"topFriends","filter":"all","first":
0,"max":20}]
[{"type":"FETCH_PEOPLE","idSpec":"VIEWER","profileDetail":
["id
","name
","thumbnailUrl
"],"sortOrder":"topFriends","filter":"all","first":
0,"max":20},
{"type":"FETCH_PERSON_APP_DATA","idSpec":"VIEWER","keys":
["goodKey"]}]
I take it this is known?
Raymond Augé
Software Engineer
Liferay, Inc.
Enterprise. Open Source. For Life.
Raymond Augé
Software Engineer
Liferay, Inc.
Enterprise. Open Source. For Life.
Raymond Augé
Software Engineer
Liferay, Inc.
Enterprise. Open Source. For Life.
Raymond Augé
Software Engineer
Liferay, Inc.
Enterprise. Open Source. For Life.