[Poetry] Support example solutions

[maddiedierker]

This creates support for example solutions in two ways:

1. Renders the "Example Solutions" partial on the levelbuilder edit page for Poetry levels
2. Adds support for Poetry levels in ScriptLevel#get_example_solutions so that the generated URLs for Poetry example solutions are correct. (By default, they were generating /projects/spritelab URLs.)

Relevant parts of the levelbuilder edit page:

There is a necessary dependency between a Poetry level's standalone_app_name (called "Level Type" in the levelbuilder UI) and its examples. This is because the two standalone apps have different standalone project URLs (/projects/poetry and /projects/poetry_hoc) and examples are an array of channel tokens. This means if you change the standalone_app_name without updating that level's examples, all example solutions will be in a weird state because the project will load as a 'poetry' project rather than a 'poetry_hoc' project, and vice versa.

Javalab is a special case where examples are an array of URLs, which I think is the ideal setup for all level examples and would prevent broken URLs (although the examples would point to a different flavor of Poetry level). However, it seemed confusing to have Poetry levels match this special case since no other GamelabJr levels have that behavior.

Links

• STAR-1926

[mikeharv]

Could we clarify this warning when we say "depends on level type"? I want it to be clear that we're just talking about "Poetry" vs "Poetry HOC" and not about somehow changing from Poetry to a level type with a different lab.

Ugh, I think the issue is that we suddenly have two meanings for "level type". I think most writers interpret "level type" as things like Poetry/Spritelab/Applab/Video/etc, but in Poetry levels, it also means one of the two modes, "Poetry" (module) and "Poetry HOC". I think I'd go so far as to say that "level type" is the wrong description for changing between these two modes. I'd like for us to look at renaming this setting later, but also clarify the warning for writers now.

[maddiedierker]

yeah, agreed that that's really unclear. in the code we refer to this field as standalone_app_name -- it's only labeled as "Level Type" in this UI. would some formulation of the actual field be clearer? something like "poetry standalone app type" or "poetry app type"?

this won't affect any code so i think we can go with whatever is clearest for the UI here

[ajpal]

poetry level subtype?

[mikeharv]

"Poetry App Type" or "Poetry Level Subtype" work for me. Could we update the warning to include the two possible options like this?

For Poetry levels, the project URL for example solutions depends on the level subtype (Poetry or Poetry HOC).

I think this clarification would help for levelbuilders who are unfamiliar with this new term.

[maddiedierker]

updated in this commit! (screenshot in PR description is updated too so you can see how it all looks together)

[mikeharv]

thanks - lgtm!

[mikeharv]

Pulled and tested. Approved on the condition that we clarify the warning text.

[dmcavoy]

Would there be a way on save to check that the example solutions match the level type and raise an error if they do not?

[mikeharv]

@dmcavoy

Would there be a way on save to check that the example solutions match the level type and raise an error if they do not?

I don't think so. The solution provided is just the token that can be used with either type. It doesn't break, it's just that it displays in the wrong mode. I don't think this is a major issue. Any curriculum writer would logically want to make sure they're using the right type and would hopefully already be checking that solutions are still accurate after making major changes to the level. Speaking from experience, setting this type is also one of the first things I do when designing a new Poetry level.