I think we need to ticket this one.  very weird.

---

Actually, wait, isn't this the right behavior?

 

I'm thinking the per-page-limit and the total limit are 2 different things. If you limit the search to 10, then there can't be more than 10 results (so there wouldn't be anything to page to).

 

Sounds like what you're wanting is a separate setting for per-page limit, no? To me these seem like different concepts.

  --Ethan McCutchen.....Mon Feb 22 09:02:52 -0800 2010

---

OR, I guess another way to deal with this would be just to have limit, but to have views with no paging (or a setting or something)

  --Ethan McCutchen.....Mon Feb 22 10:13:35 -0800 2010

---

I'm thinking have limit in WQL, as you say, determine how many results are returned, period (WQL is about content, not presentation). (And update CQL Syntax, which says, "Limit takes a number, which determines how many cards will be shown at once. This gets passed directly into the SQL.") Note that the current behavior is flaky on this; see offer paging interface consistently. We could just rename that to stop offering paging interface based on limit.

 

Then implement a paging command for inclusions, which (as now) defaults to 20 (50 if you're looking at the card as _main). E.g.,

would show 10 Basic cards at a time. So if you wanted a long list of cards, instead of putting "limit": "1000" in the WQL (which is current practice), we'd use

 

Figure? Ticket?

  --John Abbe.....Sat May 01 16:42:18 -0700 2010

---

If we have a way to turn paging off (which we know we want) and if we fix bugs in limit (which won't get fixed by changing the name to paging, of course) then the only use case we won't be ready to solve is when we want to set a hard limit that is different from the paging number. I realize that may come up, but we don't actually have any real use cases pushing that.

 

A clarification: when you say "WQL is about content, not presentation", I largely agree, but should make several points.

 

1. The paging/offset numbers, however we represent them, MUST make it to SQL. That almost certainly means they're in ruby WQL. It doesn't necessarily mean they're in JSON wql (ie search card content), but if it's in ruby and not in json, we need a mechanism for that.
2. I had been thinking that we would be able to set paging defaults in WQL and override them in inclusion syntax, much as we do with views. If it's important to take the paging defaults out of WQL, should we do the same with views? (note that both will also likely become settings, with the override pattern being inclusion trumps WQL trumps setting)
3. It's not clear to me that we have definitions of content and presentation that make it clear that a constraint on the total number of matching records is one and a constraint on a current sublist is another.

To me, the priority should be as follows:

1. fix the current paging bugs
2. have a means of hiding paging (needs design)
3. nail down our mechanism of distinguishing between paging limits and total limits.  (Needs more design and migration path.)

 

  --Ethan McCutchen.....Mon May 03 10:57:10 -0700 2010

---

(just posted a fix to the main one that this support ticket was originally about)

  --Ethan McCutchen.....Mon May 03 12:24:56 -0700 2010

---

I have several active uses cases for paging being less than limit:

 

In the Group Pattern Language sidebar:

http://grouppatternlanguage.org/wagn/Patterns_Menu (not the first few lists, but the "Recently Added")

http://grouppatternlanguage.org/wagn/News

 

In the sidebar of PA wiki:

http://processarts.wagn.org/wagn/Table_of_Contents

http://processarts.wagn.org/wagn/name8%2B*right%2B*content

 

It would be great if we could have a way to preserve the current behavior of these cards, simultaneous with 1. or at least not long thereafter. Not sure if this is what you meant by 3., or if that's something else.

  --John Abbe.....Wed May 05 02:51:00 -0700 2010

---

So, in each of those, you want to cap the total limit of the search results or something?

 

Fixing the current paging bugs does preserve the current behavior (I've already done it but we haven't deployed those changes to pinz yet). It still uses "limit" to determine the results per page, whereas the total number of items comes from the total returned by the search (without a limit). It just works consistently now.

 

I don't think these use cases show a need for two settings - they achieve everything you want with one. I'm sure there *are* use cases where we want to set both, but I still don't know any.

  --Ethan McCutchen.....Wed May 05 10:17:37 -0700 2010