-
Notifications
You must be signed in to change notification settings - Fork 23
Tournament description improvements #3074
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
Changes from all commits
d3d1682
01432cd
b7bb417
8f62080
9978a37
60d3f54
3439818
cd5400b
b2961af
e0418c0
183f1b6
2eb6199
9f8a14b
015971c
06d97f8
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1 @@ | ||
| ALTER TABLE game MODIFY description VARCHAR(305) NOT NULL; |
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -443,9 +443,11 @@ Overview.addScoreCol = function(gameRow, gameInfo) { | |
|
|
||
| Overview.addDescCol = function(gameRow, description) { | ||
| var descText = ''; | ||
| if (typeof(description) == 'string') { | ||
| descText = description.substring(0, 30) + | ||
| ((description.length > 30) ? '...' : ''); | ||
| if (typeof(description) === 'string') { | ||
| var descriptionNoMarkup = Env.removeBbCodeFromHtml(description); | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. My understanding is that this diff is changing the behavior of the GAME table on the Overview page. Is my understanding correct, or does this diff have something to do with tournament behavior?
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Your understanding is correct, we would be stripping all BBCode from descriptions of games on the Overview page.
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. The stripping is to avoid the problem where the Overview shows something like this: instead of
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Okay. I have two points here, which are basically about documenting the behavior changes in PRs to make them easier to review:
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Re 1.: I had thought that by doing things the way I am, I was attempting to preserve the status quo, namely that the Overview page shows the description of the game, instead of showing a whole pile of BBCode that is obscuring the description of the game. I had not considered the fact that the change would be player-visible in the case when there was BBCode in the game title because I have never seen a game description with BBCode in any of my games. Re 2.: I would argue that this pull request without this adaptation to the Overview page is actually creating a new player-visible problem because I have never seen a game description with BBCode before this pull request, but I am likely to see one after this pull request.
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Very belatedly: i buy that, and i'm fine with this approach. |
||
|
|
||
| descText = descriptionNoMarkup.substring(0, 30) + | ||
| ((descriptionNoMarkup.length > 30) ? '...' : ''); | ||
| } | ||
| gameRow.append($('<td>', { | ||
| 'class': 'gameDescDisplay', | ||
|
|
||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -1511,6 +1511,33 @@ protected function verify_api_setChatVisibility($expMessage, $gameId, $private) | |
| $this->cache_json_api_output('setChatVisibility', $fakeGameNumber, $retval); | ||
| } | ||
|
|
||
|
|
||
| protected function verify_api_loadTournaments($expData) { | ||
| $args = array( | ||
| 'type' => 'loadTournaments', | ||
| ); | ||
| $retval = $this->verify_api_success($args); | ||
|
|
||
| $fullData = $retval['data']; | ||
|
|
||
| // Now restrict the data to include only the information for Tournament 1, | ||
| // since this is the tournament that will be generated with an empty database. | ||
| // | ||
| // This slicing makes the test code less fragile when testing with an AMP stack | ||
| // since the database need not be deleted each time the tests run. | ||
| $tournamentIdx = array_search(1, $fullData['tournamentIdArray'], TRUE); | ||
| $this->assertEquals(FALSE, is_bool($tournamentIdx), 'Tournament 1 should exist'); | ||
|
Comment on lines
+1523
to
+1529
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Is this a pattern we use in the existing responder tests? I'm worried about making tests brittle in a new way, but if you can point to where we're already doing this for some other test type, then i obviously don't have a problem with it here.
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I'm guessing that we probably do not do this elsewhere in the responder tests. This is very much a hack to get things working on repeated testing with an already extant database where each run creates a new tournament. I'm open to suggestions on how to do this better, I couldn't find anything easy when I was trying to get the tests passing.
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Gotcha. I can take a more informed look at some point - mind adding a checklist item for it? Anyway, i'm not going to block this PR over it if we get to the point where it's mergeable, i don't think. But i want to at least think about it a little more, if not enough to make a suggestion.
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I've added a point to the checklist for this. |
||
|
|
||
| $slicedData = array(); | ||
| foreach ($fullData as $key => $value) { | ||
| $slicedData[$key] = array($value[$tournamentIdx]); | ||
| } | ||
|
|
||
| $this->assertEquals($expData, $slicedData); | ||
|
|
||
| $this->cache_json_api_output('loadTournaments', 'noargs', $retval); | ||
| } | ||
|
|
||
| /* | ||
| * verify_api_loadTournamentData() - helper routine which calls the API | ||
| * loadTournamentData method, makes standard assertions about its | ||
|
|
||
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Okay, now that i think about this with slightly fresh eyes:
Env.removeBbCodeFromHtmlvar replacements, and if someone adds a new type of markup toEnv.applyBbCodeToHtmlwithout adding it toEnv.removeBbCodeFromHtml, it'll make a mess.It seems like the least intrusive fix would be to move this
replacementsconfig outside of each function to one place in Env, and have it be one dict that defines anapplyRulesbehavior and aremoveRulesbehavior (i'm not wedded to those names at all), for each piece of markup syntax.What do you think?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's very reasonable, I'll refactor out 'replacements' into its own entity.