I am astonished (only a bit; "legacy code" was to be expected in the jump from 0.5). And I am sorry I missed that line in the specification; so it is true, the javascript is doing the right thing.
I have raised issues 140 and 141 in http://code.google.com/p/opensocial-resources/issues/list as suggested. The report of the bug in JIRA could be closed, but instead I'd suggest the patch var activityCollection = new opensocial.Collection(activities); activityCollection.activities = activityCollection; return activityCollection; or whatever the javascript code is, to add a new property to an object. In this way, we keep with the specification and we return too a full featured Collection<activitity>. Alejandro 2008/4/9 Cassie <[EMAIL PROTECTED]>: > Ah, I see. Actually, if you look carefully, Shindig is doing the right > thing in javascript. The spec specifically says "When processed, > returns an object whose "activities" property is a > Collection<Activity> object." so is you do getData.activities, that > should be a collection. > > This is a relic from the 0.5 apis where there was also a "stream" > property. So.. the spec is sorta weird, and should be fixed. But > Shindig is doing the right thing in javascript. > > - Cassie > > > > > On Wed, Apr 9, 2008 at 4:44 PM, Alejandro Rivero <[EMAIL PROTECTED]> wrote: > > just to clarify; the problem is not that there is not paging, the real > > problem is that neither .getData().each() nor .getData().size work > > when the answer is a collection of activities, while they do work when > > the request is for a collection of persons. > > > > 2008/4/9 Alejandro Rivero <[EMAIL PROTECTED]>: > > > > > > > 2008/4/9 Cassie <[EMAIL PROTECTED]>: > > > > > > > > > > So the Shindig java code is doing the right thing. > > > > If we think activities should have paging, then someone should just > > > > bring it up on the spec mailing list. > > > > > > > > - Cassie > > > > > > > > > > Yep, it is doing the right thing. The bug is in the javascript side, I > > > just sent a report. > > > > > >
