Skip to content
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

Improve using .target_number in Story Table #706

Closed
4 tasks done
plocket opened this issue May 23, 2023 · 2 comments
Closed
4 tasks done

Improve using .target_number in Story Table #706

plocket opened this issue May 23, 2023 · 2 comments
Assignees
Labels
enhancement New feature or request

Comments

@plocket
Copy link
Collaborator

plocket commented May 23, 2023

  • Allow .target_number of 0 to set .there_are_any to False.
  • Allow .target_number to set .there_are_any in general so the author doesn't need to set .there_are_any separately.
  • Fix .target_number using one fewer loop than it should.
  • Create feature tests for those items.
@plocket plocket self-assigned this May 24, 2023
@plocket plocket changed the title Allow .target_number of 0 to set there_are_any to False Improve using .target_number in Story Table May 24, 2023
@plocket
Copy link
Collaborator Author

plocket commented May 30, 2023

This is a wilder ride than I anticipated. Adding some record of the digging so far. This is how the story table flow currently works for the relevant code:

Notes: Each 'row' is an object representing a row.

  • for each page
    • for each target_number row

      • keep the target_number row (don't do anything to it)
      • create the there_are_any row with a reference to the original target_number as its source property
        • get the there_are_any value
      • create there_is_another row with a reference to the original target_number as its source property
        • get the there_is_another value depending on the accumulated times_used value in the original target_number row
    • for each field

      • find which table row matches the field's variable name
      • set the answer of the field using the table row value
      • increment times_used of the row and also of the source object in the row. Mutating the source is what allows target_number to persistently accumulate the times it's used and later tell there_is_another which value it should for that particular page.

Problem: Take the following row

| children.target_number | 2 |  |

If there_are_any needs to be set by the user, it adds to the number of times target_number is used (times_used). That counts 1 use for there_are_any and 1 use for there_is_another, coming out to the correct 2 uses. But if the author sets there_are_any themselves, that first accumulation doesn't happen. The test only counts 1 use for there_is_another since there_are_any never gets asked. In that case, the test thinks it hasn't added enough children and tries to add another child.

My solution: We need to track there_are_any separately from there_is_another for target_number rows. Then we use only the there_is_another accumulator to get a consistent number. We can't use that number to determine (for the report) which rows were used through the whole test. Example:

| children.target_number | 0 |  |

That should correctly set .there_are_any to False and will be a legitimate use of the target_number row, but will not show up in the there_is_another accumulator.

In order to write a correct report of what rows were used, we can either keep times_used as it is or add up the two separate accumulators and get rid of times_used.

@plocket
Copy link
Collaborator Author

plocket commented Aug 11, 2023

Closed by #709

@plocket plocket closed this as completed Aug 11, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

1 participant