| 1 | Todo |
|---|
| 2 | ==== |
|---|
| 3 | |
|---|
| 4 | * Check that question codes are unique. |
|---|
| 5 | Are we going to create the node server for this? |
|---|
| 6 | This will allow auth, more rest-like search, server side validation |
|---|
| 7 | * Check that answers are saved correctly. |
|---|
| 8 | Answers to multi-item questions (like scales) are stored in an object |
|---|
| 9 | now with index as keys. This is not symmetrical with the fact that the |
|---|
| 10 | configuration is an array. |
|---|
| 11 | * Export answers for a survey run |
|---|
| 12 | * Revive json schema checks for our data. |
|---|
| 13 | Questions don't pass the schema at the moment. |
|---|
| 14 | * Fragile: widget creation relies on the names in Factory, but these |
|---|
| 15 | must match the types returned by the actual widgets. Fix this. |
|---|
| 16 | * Write a spec for the codes. |
|---|
| 17 | * Don't allow Save in Question unless all question items are done editing. |
|---|
| 18 | * Use node as a server, adopt the layout described in |
|---|
| 19 | http://dojotoolkit.org/documentation/tutorials/1.8/node/ |
|---|
| 20 | This will require quite a lot of moving and creating a rest interface |
|---|
| 21 | -> can be just a proxy to CouchDB in he beginning. |
|---|
| 22 | |
|---|
| 23 | Checklist |
|---|
| 24 | ========= |
|---|
| 25 | |
|---|
| 26 | * Form validation (use tooltips!) |
|---|
| 27 | * Input validation & escaping |
|---|
| 28 | - E.g. texts and labels of ScaleWidget are directly put in innerHTML, I don't think TextBox does any escaping. |
|---|
| 29 | * Output escaping |
|---|
| 30 | * Widget life-cycle |
|---|
| 31 | buildRendering -> widgets in code before set attributes |
|---|
| 32 | postCreate -> after all inits, but before in DOM |
|---|
| 33 | startup -> after insertion in DOM? |
|---|
| 34 | * Review current JSON formats, do they allow for extension or extra meta-data? |
|---|
| 35 | |
|---|
| 36 | Open issues |
|---|
| 37 | =========== |
|---|
| 38 | |
|---|
| 39 | * Do different inputs in one question get different codes? E.g. in |
|---|
| 40 | To ease exporting into other programs and easy communication, the codes |
|---|
| 41 | are important I think. It should be easy to pronounce, and easy to |
|---|
| 42 | find in the tool (people might get a dataset and not know where it |
|---|
| 43 | came from). |
|---|
| 44 | * What if a question is included in a survey multiple times. Use block |
|---|
| 45 | or allow a pre/post-fix on the code to differentiate it. |
|---|
| 46 | Should not be too much work, so if an scale with 5 items has 5 codes, |
|---|
| 47 | you should be able to set a prefix on all of them at once. |
|---|
