-
Notifications
You must be signed in to change notification settings - Fork 27
Update 7.08.2017
Stian Håklev edited this page Aug 7, 2017
·
5 revisions
Since a lot of work has happened while Louis was away, and also some while Romain was away, I thought I’d look over the changes, and do a quick recap of what has changed, status of various projects, unresolved questions etc.
- createActivity became createPackage, and can create activities and operators (needs a bit more testing)
- removed autopublish. However, we're still publishing all collections to all users (only distinguishing between teacher and others), should restrict this further.
- ac/op packages can now export multiple ac/ops in an array
- all ac/op have shortDesc and description added to packages. When choosing new ac/op, shortDesc is shown, and can be expanded. Search is also provided (full-text for title/shortDesc/description).
- Activities can have exampleData, an array of title + config + activityData, which is used for preview. Activities can be previewed from the selector. ActivityData is run through the mergeFunction. You can also see exactly what the data structure is like (including the reactive data after the merge function, or after interacting with the activity)
- When configuring an activity, you can preview the activity with that exact config, if the activity is “green” (no problems, mainly to ensure that the config is correct). This let’s you merge the config with the activityData from the exampleData
- Currently the exampleData mix config and activity data. This makes it messy when we try to provide different example data in activity-specific preview... One option is to disentangle, provide one list of activityData, and one list of config... Makes preview UI a bit more complex, and also - do all configs go with all example data? So far, I think so?
- There are a bunch of different functions that validate graphs, these work on pure data. Some simple ones check that all activity types actually exist in the current FROG instance, etc. Others, like types and social structure are described below.
- Currently the graph validator is called anytime refreshUpdate() or addHistory() is called in the graph (refreshUpdate() is used from the sidepanel, to avoid adding to the undo history of the graph), and the result is stored in the store
- The result is a list of issues, with id: of component involved, severity (error | warning), error text, and error type. The error text does not include the type (operator | activity) and name of the node. This data is reflected in multiple places:
- a central indicator showing red (errors) or yellow (only warnings). Mousing-over shows a list of all errors/warnings (errors first), with node type and name appended.
- a similar indicator (same component) is shown in the side panel for operators/activities, showing only warnings/errors relevant to that node
- nodes (ac / op) have a red border color if there are any warnings/errors associated.
- The code for the UI (Validator.js etc) is getting quite convoluted, and should be refactored, although not urgent. Not sure it makes sense to use SVG instead of a simple div.
- We're adding a lot of color coding to nodes, and we might add more in the future - should probably rethink a bit at some point. Previously the border color changed to show whether an activity was selected, currently the border color reflects error status, and there's an additional border, a few pixels out, added when selected. Works, but maybe not perfect.
- I am planning to add some highlighting of which nodes are valid drag-targets, when dragging a connection line, once I have the type checking of activityData finalized.
- Graph validation happens in two places. One is during the editing of the graph. Whenever the status changes (broken: true/false), it updates the graph object in the database. The teacher view only lists graphs that have status broken: false. However, once you choose to generate a session from a graph, it runs validateGraph again. This is as an extra security, in case you've imported something without touching the graph editor, or the system configuration has changed since you edited a graph etc. We want to make absolutely sure that no graph can be run without being valid.
- Operators now specify which social structures they produce (doc).
- Config forms can specify that a given field is a social structure, and this is shown as a pull-down with available social structures
- All flow of social structures is verified:
- Any op / ac specifying incoming social attributes (through groupingKey or in config) should actually have those social attributes incoming
- The attribute used in groupingKey cannot be used in config
- If more than one social operators is incoming, social attributes are not allowed to overlap
- This seems to work pretty well, however more practical testing is needed. The UI of warnings in sidepanel etc might be improved.
- Currently all the social structure checks assume that all social structures are interchangeable... for groupingKey this makes sense - there is no semantic difference between groups: [1,2,3], and roles: ['chef', 'waiter']... However, for an activity which uses roles to distinguish between different roles during the activity, in the same instance (for example, only one person can edit, but everyone can see), it actually requires an activityStructure with specific attributeValues... Not sure how we would type-check that... (both on the incoming and outgoing side)
- We have a wrapper around react-jsonschema-form called EnhancedForm (in frog-utils), which for now is able to deal with conditional fields, conditions can be static on a boolean, or a function that takes formData as input. This is used for ac/op config
- There are a lot of properties in the ac/op package definition, and some confusion about what should be in meta, etc. We should rethink this a bit, and nail it down (and document it)
- The config of an ac/op is now checked in two ways. First using a jsonschema validator - this basically checks that required fields are there, type (integer/number) etc. The second is an optional function that is given formData and can return errors. Data is checked continuously and displayed in the sidepanel while editing config, but also on whole-form validation, to ensure that old graphs are still compatible with updated activities, for example.
- This was a major challenge, but I've made a lot of progress I think. I came up with a format, and a checker (all on branch supertest). I've documented it here
- I'm happy to hear your feedback, but there are some major issues before we finalize this work
- Do we allow multiple incoming activityData to a product operator? I think the answer must be yes, because I can see many cases where we would need this - but how does this happen in practice, how do we type check this? Do we have multiple type definitions for different slots, etc.
- All my type checking effort was focused on making sure dataUnits were compatible, but I didn't think at all about social structure of activityData... For activities this is fine, since a single activity instance will always receive and produce a single dataUnit. For operators this is more complex. One idea was to have specific subtypes of operators (aggregation/distribution/transformation). Needs discussion!
- Right now we have two use-cases. One is the reactive doc, to enable an activity to implement their own collaborative editing form. The other is photo upload - which could also be enabled through the enhanced form... however it needs access to specific APIs to enable uploading the photo to the server, and placing a URL to the photo in the form data. We could pass all of these things down to the activity, but as we keep adding more APIs, it gets messy. Not sure if there are any nicer ways or abstractions.
- Romain is working on this, I will help with verifying the LTI signature.