5 Replies Latest reply on Jul 26, 2014 5:28 AM by it2000

    Add an optional TOTAL parameter to APIs

    noelwhite

      We would like to change the theme in our community to make the content pages a bit more intuitive and useful.  We have a significant community that has been using Jive for several years, so many of the content lists can span MANY pages.  Unfortunately, the pages simply show ...

      until you go to page 2, then you see... then then then ...etc

       

      For users that need to go to the ending pages (it happens a lot in our instance) this navigation is an...inconvenience.

       

      So we are looking at theming changes to show and allow easy nav to the ends of the content chain.  We are not finding this easy with the current return packets of the API calls.  It would be pretty easy to change this if the APIs that returned result sets allowed for an optional parameter like TOTAL that could be requested when needed.  This could run an additional query that used the same query as the current result set, except it would just do a select count(*), and then include the return as a new parameter in the JSON.  This would enable a lot of useful functionality that is extremely difficult to do right now.

        • Re: Add an optional TOTAL parameter to APIs
          whoiskevin

          Noel,

           

          I won't disagree with you that it would be useful in some situations.  What I will add is that from a design and performance perspective it is difficult to achieve.  There is a reason that Google does the same thing with results.  Finding the entire result and calculating that total is extremely resource intensive and does not scale well.  Adding in the per community list and you have a scalability issue.

           

          So I cannot answer for whether Jive will try to implement something like this in the future.  Just wanted to point out that the current behavior is not an accident.

            • Re: Add an optional TOTAL parameter to APIs

              Kevin's comments about the performance impact of calculating the totals ahead of time is pretty much the reason that this functionality doesn't exist -- consider that the server would be required to calculate and apply entitlements (can this viewer see that content object) on the entire set of matches, and that could get extremely costly if there was lots of content.

               

              There are a couple of places where counts are provided (such as the unread count of inbox items), but that only happens because the server does a bunch of work at write time to maintain the counter.  It's not computed on the fly.

            • Re: Add an optional TOTAL parameter to APIs
              it2000

              One can simply change the order and the last doc will be the 1st one.

               

              Google shows the estimated number of results - Jive could do the same with a count(*) without permission check. Anyhow most times it does not help to see that there are 2000 results as users look only at the first 3 results.

              Searching instead of browsing a lot of content pages is much faster.

               

              I assume that you have a completely different business case.