June 14, 2010

XPages: Default Value for Repeat Limit in Repeater Control Equals 30 ?

Last week, I stumbled upon a mysterious bug in XPages. I've created quite a few pages and custom controllers with repeater controls during the last months, but never seen this before:

When I didn't specify a repeat limit for the control, I would only get the first 30 entries from the data source!

I've developed the habit of not setting the repeat limit when I don't need it, believeing that it would provide me with all the entries from the data source. Checking the provided documentation in the Domino Designer comfirmed my thoughts:


Has anyone else experienced this bug? Or is there another way to limit the repeat control, that I might have done unintentionally?

For most cases, the work around is quite easy, just set the repeat limit field to some high value that you (probably?) will never exceed, but in some cases you might not know in what range the number of view entries will be when your application has been in use for a while...

5 comments:

  1. I think it is a bug in the documentation. All devs I talked to are telling about the 30 items default.

    ReplyDelete
  2. Thanks for confirming to me that others are seeing this as well. Couldn't really find any confirmation by googling.

    But isn't this 30 repeat limit kinda annoying, as I will surely just develop the (bad) habit of setting the limit to, let's say, 200, and then suddenly that limit is not large enough for one instance of the repeat control?

    ReplyDelete
  3. Rasmus, that's what the pager control is for: the "rows" attribute (which, as you mentioned, defaults to 30 if unspecified) is not the limit for how many total rows will display but rather how many will display per "page". If a pager control is bound to the repeat, users will be able to navigate through all instances of the repeated content, no matter how many total rows are available.

    This is both for performance and usability: if there are 1000 instances of the items you're repeating, you don't want all 1000 to be loaded at once; not only will the page be slow to load, but the amount of scrolling required to get to the end would be horrendous. Setting a low row limit and adding a pager solves both problems: it requires little or no scrolling from the user, and each set of rows loads comparatively rapidly. If the application's data structure is well-designed, the information the user is looking for will be in the first few rows anyway.

    Consider Google: a search for "XPages" returns 112,000 results. They could choose to display summary data for all 112,000 results at once, but the performance and usability would be horrendous... and they don't have to, because they've designed their application such that what I'm looking for will be within the first few "rows", as long as I've provided them enough information about what I'm trying to find. Too few Domino applications are designed this way... we just throw all the data at the users at once and (if they're lucky) give them different ways of sorting the data, instead of structuring the data and interface in such a way that what they most need to see floats right to the top.

    ReplyDelete
  4. @Tim:
    I totally agree with your comments regarding sorting by relevance and limiting how much is shown in one page, but in this case I was not in complete control of designing the solution.

    However, I was able to sell in that we should display the information categorized, with expandable sections, hopefully avoiding "information overload" for the users.

    Still an annoying mismatch between documentation and reality, though:-)

    ReplyDelete
  5. I have noticed a similar thing and the documentation in 8.5.1 clearly states: "If set to 0 all rows in the underlying data model will be displayed. (as of 8.5.0)".
    @Tim - I fully understand the "pager" argument and filtering the data shown to be more manageable - However, when we produce applications for clients they always want at least one view that "...just shows me everything".

    I think the pager design philosophy is hurt most by the fact that in the actual design client when you look at a views data the eclipse ide quite happily shows EVERY row in a scrollable view and thank god that it does! If it's good enough for the design client I fail to see why pagers have to be used in xpages applications - they are remarkably clunky.

    The analogy with say a google search doesn't quite fit - in most cases in a real world environment a database user will know pretty much that the record for Mr Upside is going to be pretty near the end of an alphabetically sorted view and would just scroll to the bottom 10%, home in and click it. With google you don't know what page the result you are looking for is on, and generally you don't go past 4 or 5 anyway - because by then you are bored with click, click, click - which is exactly why people pay so much to be on page 1.

    I guess the main point is that the documentation is 100% incorrect and there doesn't seem to be any form of addendum on the subject anywhere :-)

    ReplyDelete