Inconsistent Use of `{{answers-name}}`

[SybelBlue]

The documentation of its associated function claims it is used in namespacing, but it is not apropriately set up to do so - it is always empty string. It appears PL magic has prevented collisions from becoming an issue.

The {{uuid}} is the canonical PL way to do this, and it already is in use elsewhere in the code for namespacing.

Suggested fix: remove {{answers-name}} and use {{uuid}} or depend on PL for handling namespacing

[SybelBlue]

I misunderstood how this is used in PL. Oops!

The user of the element is supposed to provide answers-name as an html attribute (ie <pl-faded parsons answers-name="giftcard1" ... > to disambiguate between multiple instances of a problem on a page. This key is used in data['submitted_answers'][ <answers-name> ] to get that particular problem's answers in the client's server.py. As such, the proper UUID is not in scope for the client.

Because of its importance to the end user, most PL built-in elements have answers-name as a required attribute. Most PL built-ins have a single input field like <input name={{name}} ... > which exposes that input to the end user in data['raw_submitted_answers'][ <name> ] and the parsed version in data['submitted_answers'][ <name> ].

tl;dr: answers-name is used in end-user namespacing, and should not expose/rely on internal properties like UUID.

[SybelBlue]

This means that we have a pervasive bug! In pl-faded-parsons.py,parse uses or sets the attributes of data['submitted_answers'] without the answers_name prefix!

New Proposed Fix:

• [ ] Check all uses of data['submitted_answers'] and data['raw_submitted_answers'] use the answers_name property
• [ ] Expose data['submitted_answers'][ <answers_name> + 'student-parsons-solution'] as data['submitted_answers'][ <answers_name> ] in the parse function so its consistent with PL style

[SybelBlue]

Required for #39!