Hmm now we are on the activities side and I noticed the way to getTotalSize is somehow obscure. Raymond, the working way to extract the info out from the returned data is to use .getData().activities.size() .getData().activities.getTotalSize(); //of course, the same that above, because there is not paging. .getData().activities.each(...)
And so on. Now, I am not very sure about if other containers in real life (hi, hi5!) do it in this way. Note that the API says that midataresponse.get(id) is a ResponseItem miresponseitem.getData() is an Object, "the requested value calculated by the server; the type of this value is defined by the type of request that was made" The problem is how to build this Object back to a Collection, and then the undocumented answer in shindig javascript is that you get the Collection as a property: miresponseitem.getData().activities is a ApiCollection of Activities Now, are we sure this is the standard? Or is it a bug? 2008/4/6 Alejandro Rivero <[EMAIL PROTECTED]>: > Probably he wants to know the value of MAX in order to present the > user a complete pagination bar, not just a "more>>" tag. > The blame is on "ResponseItem", whose documentation does not specify > any way to know how many objects has it found, and one must to go to > the Api entry for Collection in order to discover the use of > .getTotalSize() versus .size() > > Actually, the hint comes from looking at BasicPeopleService > > int totalSize = people.size(); > int last = first + max; > people = people.subList(first, Math.min(last, totalSize)); > ApiCollection<Person> collection = new ApiCollection<Person>(people, > first, totalSize); > > whose Collection returns totalSize, as Raymon asks. > > > > > > BTW, the Filter HasApp seems very useful for interaction between > users. I hope real containers will implement it! > > 2008/4/6 Cassie <[EMAIL PROTECTED]>: > > > > The js api supports paging, sorting and filtering. See this page: > > > http://code.google.com/apis/opensocial/docs/0.7/reference/opensocial.DataRequest.PeopleRequestFields.html > > > > The java api supports pagination for the PeopleService for this function: > > > > public ResponseItem<ApiCollection<Person>> getPeople(List<String> ids, > > SortOrder sortOrder, FilterType filter, int first, int max, > > Set<String> profileDetails, GadgetToken token); > > > > It just doesn't support pagination for the getIds function. We could > > add pagination to the getIds function but then that function would > > need to know how to sort. But if it needs to know how to sort then it > > has to have activity, profile and data info. That doesn't seem like a > > really good pattern though. > > > > One possible way to do things would be to get rid of the getIds > > function and to have each getPeople, getActivities, getData call > > translate the idSpec into a list of ids itself. That eliminates some > > of the nice separation that we currently have though. > > > > So, I'm not sure how we want to handle this. Feel free to propose a > solution. > > Thanks. > > > > - Cassie > > > > > > On Sat, Apr 5, 2008 at 5:41 AM, Raymond Auge <[EMAIL PROTECTED]> wrote: > > > > > > There should be some way if providing an integer total from the > backend to > > > the front end... returning a list of 10,000,000 ids is simply not > > > acceptable... > > > > > > Now, I'm fairly certain that no one will ever have 10,000,000 > friends... (I > > > certainly don't :) ). BUT... it's more an issue of scalability... It is > > > certainly conceivable that I have thousands of events... and it'd be > nice to > > > be able to get that number without ever having to get them all... > > > > > > These services need methods to return the total for a given userId. > > > > > > org.apache.shindig.social.opensocial.ActivitiesService > > > org.apache.shindig.social.opensocial.PeopleService > > > > > > This method needs paging support... > > > > > > List<String> > > > org.apache.shindig.social.opensocial.PeopleService.getIds(IdSpec idSpec, > > > GadgetToken token) throws JSONException > > > > > > This method needs paging support: > > > > > > ResponseItem<List<Activity>> > > > > org.apache.shindig.social.opensocial.ActivitiesService.getActivities(List<String> > > > userIds, GadgetToken token) > > > > > > I think this missing functionality extends all the way to the front > end JS > > > API. > > > > > > AGAIN... maybe I'm just not understanding it all correctly. If so, can > > > someone explain it to me? > > > > > > Ray > > > > > > > > > > > > > > > > On Fri, 2008-04-04 at 23:22 -0400, Raymond Auge wrote: > > > Suppose for example I have 10,000,000 Friends... I certainly don't want > > > to ever present them all in the UI... secondly, thought I can specify > > > that I want one page from "first" to "first + max", but that does not > > > provide me with any way to tell the UI that there are 10,000,000, so > > > that I can display the total and/or produce a page list... > > > > > > So, like I said, I might just be missing something and/or not > > > understanding the usage of the API (at least from the backend > > > perspective)??? > > > > > > It's simply wrong to have to produce the total based on returning the > > > total result set and then pruning out the desired page. > > > > > > i.e. How can I get the total number of "friends" WITHOUT returning them > > > all from the DB? This doesn't seem possible through any of the methods > > > in the backend service tier. > > > > > > > > > Ray > > > > > > On Fri, 2008-04-04 at 10:13 +0200, Cassie wrote: > > > > > > > Which entities are you talking about? > > > > > > > > - Cassie > > > > > > > > > > > > On Fri, Apr 4, 2008 at 2:05 AM, Raymond Auge <[EMAIL PROTECTED]> > wrote: > > > > > Hello All, > > > > > > > > > > There does not appear to be a way to return the total number of some > > > > > entity through any of the APIs. > > > > > > > > > > I only see a way of returning a list of entities. Not the total > count > > > > > (which I'd need in order to build some pagination). > > > > > > > > > > Perhaps I missed something? > > > > > > > > > > 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. > > >
