fix paging on settings

Ticket

+commit
 

when looking at a set, the paging on "Cards in set" breaks.

 

Underneath the issue was that the search was being rendered as subcontent without its own slot.

 

For now, I used a very easy fix; just inclusion syntax of

.  This means by_update is now depended upon by code, however, which I don't love....

 

Also upped the search limits to 100.

 

Likely more complete fix: wagneer around it by making these actual searches built with *content. there are some challenges there, which is why Ethan hard-coded it in the first place. Another possibility would require we first implement WQL in URLs.

 

http://test.dwagn.org/*right - click to page, and there's no paging, but the content of the Settings section above disappears, to be replaced with "0 results".

 

note: not related to rescue search when item breaks



any idea what the underlying problem was/is?

  --John Abbe.....Tue Nov 16 19:08:16 -0800 2010


Still seeing this on wagn.org

 

Can't test these at the moment, will when fix searches on settings is addressed:

http://test.dwagn.org/*content

http://test.dwagn.org/*edit_help

  --John Abbe.....Fri Jan 07 22:51:10 -0800 2011


retag to Wagn 1.7?

  --John Abbe.....Thu Jan 20 00:43:10 -0800 2011


much better now. there were multiple issues. one had to do with the slot variable getting passed to the paging template (confused about why that didn't break more things). Other issue had to do with the way we store/convey the vaguely named "view" variable that stores the view to which cards return after various calls like paging and edits. This fixed problems in several places and tightened up the api.

  --Ethan McCutchen.....Thu Jan 27 12:38:24 -0800 2011


http://test.dwagn.org/*right gets an error ("error rendering *right+*right"). It's the fancy new hover-to-get-details error, but still an error.

  --John Abbe.....Thu Jan 27 17:00:12 -0800 2011


OK, it turns out, this is more involved than I thought, and I don't think it all fits in 1.5.2.

 

I did fix some of the brokenness (as with the "Cards in Set" list on Set cards) and flushed out / fixed some other minor things in the process. A lot of that had to do with correct wrappings and slot attributes. But there is a core issue with paging on sets and settings that has nothing to do with the new code.

 

These searches don't have real names.

 

Paging works by sending the server the card name and the paging params. The server then looks up the card (which can be virtual), gets the WQL, adds in the paging params, does the search.

 

These searches on the set and settings pages are created on the fly with hard-coded WQL. They don't have meaningful names that the server can use to complete the request.

 

As a quick workaround, I upped the limits on these searches to 100. That at least pushes the problem further out to the edge.

 

In the long term, I see two ways to solve it:

1. wagneer around it by making these actual searches built with *content. there are some challenges there, which is why I hard-coded it in the first place. But we could push in that direction.

2. make it possible/easy to send complete wql in urls. this has some obvious upsides and may eventually be needed anyway. But it's not necessarily super straightforward, and so long as this is the only problem it's causing, this will be pretty low pri. My hunch is that we might eventually find other benefits.

  --Ethan McCutchen.....Fri Jan 28 11:10:44 -0800 2011


there are actually hybrid solutions like real search cards called from code. and workarounds that more thoroughly avoid the error (like the "simple" paging-less search view we've discussed)

 

moving from "medium" to "low" pri

  --Ethan McCutchen.....Fri Jan 28 11:13:24 -0800 2011


Ethan: "As a quick workaround, I upped the limits on these searches to 100. That at least pushes the problem further out to the edge."

 

That's in code, right? Not something to change in English and migrate?

  --John Abbe.....Fri Jan 28 13:05:45 -0800 2011


right. it's in those weirdo no-name code cards.

  --Ethan McCutchen.....Fri Jan 28 13:07:15 -0800 2011


1 sounds right to me to solve this ticket. upgrade paging (will paginate) may or may not be relevant.

 

implement WQL in URLs

  --John Abbe.....Fri Jan 28 13:08:16 -0800 2011


not super relevant. at least, I don't think it solves this problem for us. wow, we've got some old tickets :)

 

I'm thinking we start with the hybrid approach, and then see if we're ready to do #1 completely. I'll spell it out in the solutions when I get a chance, and then we can start banging on en.dwagn.org after the release.

  --Ethan McCutchen.....Fri Jan 28 13:12:09 -0800 2011


I'm a little confused about this. The "cards in set" link must have been on Sets, not Settings. That stuff is gone in favor of the rule editor. As for Setting cards, there shouldn't be any paging. So I think this is ready to be closed.

  --Ethan McCutchen.....2013-04-03 16:28:08 +0000


What's a 'weirdo no-name code card'?

--Gerry Gleason.....2015-01-18 12:47:25 +0000

going to guess it's something we got rid of 4 years ago?

--Ethan McCutchen.....2015-01-20 23:37:56 +0000

Fun, something neither of us remember. Probably a wart that is best not remembered.

--Gerry Gleason.....2015-01-24 13:20:20 +0000

I suppose I have a guess. If you do something in the code like my_card = Card.search(:type=>:blah, :edited_by=>current_user), then my_card might be a weirdo no-name code card??

--Ethan McCutchen.....2015-01-24 15:42:58 +0000

That doesn't seem likely, or maybe, but isn't code probably a reference to having a codename?

--Gerry Gleason.....2015-01-24 23:39:04 +0000