User develops a widget in DevMateria, it works. It uses a mostly but not 100% standard qset. For example, the answers provide a foo property.
User installs widget into a working actual Materia install. When installing Materia calls upon Widget_Instance which uses its find_questions function. This guesses that the questions in the demo.yaml are actual "Materia Questions" (this happens regardless of the existence of the materiaType property.
This function creates new Widget_Question objects which strictly only allow these properties, as defined in the code:
As a result, the widget demo fails in actual Materia since the qset unexpectedly doesn't contain some properties, such as the foo property in our example.
In the end, this is working as intended, but IMO it's unclear - especially since it works in DevMateria. I argue it's impossible for the developer to know why it's not working in actual Materia without digging through the code.
Different proposed ideas to fix this:
We have a materiaType property. Perhaps only attempt to find questions on qset objects that contain this materiaType property. If it's missing then we bypass the find_questions algorithm. I feel that this is best since you essentially have to opt-in to conforming to a schema. And if we update our documentation we can make it clear that by opting-in to this you are only allowed to use the properties that match the schema. Ideally, an error would be thrown if the qSet doesn't conform to this schema instead of silently throwing away non-conforming properties.
Or, simply don't remove fields that don't conform to the schema
Optionally, implement these restrictions in DevMateria
Case study:
foo
property.find_questions
function. This guesses that the questions in the demo.yaml are actual "Materia Questions" (this happens regardless of the existence of themateriaType
property.foo
property in our example.In the end, this is working as intended, but IMO it's unclear - especially since it works in DevMateria. I argue it's impossible for the developer to know why it's not working in actual Materia without digging through the code.
Different proposed ideas to fix this:
materiaType
property. Perhaps only attempt to find questions on qset objects that contain thismateriaType
property. If it's missing then we bypass the find_questions algorithm. I feel that this is best since you essentially have to opt-in to conforming to a schema. And if we update our documentation we can make it clear that by opting-in to this you are only allowed to use the properties that match the schema. Ideally, an error would be thrown if the qSet doesn't conform to this schema instead of silently throwing away non-conforming properties.