[cpeel]

We use both OCR and [OCR] as a special string to select the OCR page text for things like generating post files. Standardize on the former -- which is used in the API -- by using the pseudo-OCR Round object.

No functional changes to the user besides remove the [] around OCR on the project page when downloading the CTF.

Sandbox: https://www.pgdp.org/~cpeel/c.branch/standardize-ocr-special-string

[bpfoley]

This looks good to me.

I like the way we're narrowing the types of some of the params to generate_interim_file() & generate_post_files(). They now have to be valid Projects/Rounds/pretend-OCR-rounds rather than just any old string. And we're following the pattern of "parse, don't validate" in the callers.

Of course this comes at a small cost: an extra DB query for the new Project($id), which I assume is more than acceptable in the bigger picture.

Also, I assume it's OK that we're changing the format of the HTML requests. Nobody should be relying on these anyway.

And, as far as I can see, none of the [OCR] are in anything that might be persisted in the DB, so we shouldn't have any problems there either.

[cpeel]

I like the way we're narrowing the types of some of the params to generate_interim_file() & generate_post_files(). They now have to be valid Projects/Rounds/pretend-OCR-rounds rather than just any old string. And we're following the pattern of "parse, don't validate" in the callers.

Yes, I like this better too -- more accurate/specific args to those functions.

Of course this comes at a small cost: an extra DB query for the new Project($id), which I assume is more than acceptable in the bigger picture.

For the WordCheck-related pages it's fine (those DB queries should be fully-serviced in the bufferpool too).

Also, I assume it's OK that we're changing the format of the HTML requests. Nobody should be relying on these anyway.

In the project page HTML? Yes, we've not promised that the HTML will stay the same. If we break anyone we should usher them to the API 😁