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.

Reply via email to