The second commit is where I need to start thinking about the app a bit more. We're going to establish a few basic data model classes. They'll change as the rest of the code is written, but this commit will make a start on it.
Our situation gives us a slightly unusual need:
- The students are all in groups already
- The software hasn't been written yet, so the students are not in the database
- We can't use their UQ logins (institutional policy reasons)
- But we have all the students' GitHub usernames in a spreadsheet
When students log in, they need to be able to get their groups — which means the groups need to be entered before the students have created their accounts in the database.
That means we're going to need a concept of a "pre-enrol", so that when a student has logged in, they can automatically find both the course and their group, in this case using their GitHub username.
Although I'm writing this initially for our course, I'll try to make the data model reasonably general.
Things you'll notice about the data model
There are lots of
Refs. This is part of my
handylibrary. A ref is a reference to a data object. It might be the object itself; it might be a
Futurethat will return the object when a database fetch has completed. It might be a
LazyIdif all we have so far is the ID of the object. There are quite a few possibilities for what a
Refis a monad, which means that it has
mapmethods that I'm going to use extensively, and ensures that at the end of an algorithm I'll still have something that meets Ref's contract.
It's what I call an "ad-hoc" monad, however, because we haven't predetermined the specific kind of Ref we're going to end up with.
More information will go up on handy's documentation site (And there's a paper I want to write on this style of app development soon.)
Each of the data classes extends
This means a little more than just that it has a string id.
Ref.getIdlooks for an "implicit argument" that can produce a canonical id for an object. (For instance, so that if you use Integer ids,
Ref(classOf[Foo], "10")resolve to the same item.)
Within the handy library, there's an appropriate object
GetsStringIdfor handling this for objects whose canonical IDs are Strings.
(In the database layer, however, we're going to be converting to and from MongoDB's
BSONObjectIDclass. I just don't want to expose object IDs in the API.)
So, in this commit we have some incomplete data classes:
A user in the system. This inherits from one in handy-appbase-core, and includes types for Identity and PasswordLogin (though we won't be using the PasswordLogin for now)
A social login identity, such as a GitHub account. (Or, in time, LTI for logging in directly from Blackboard, but university policy prevents us from doing that yet.)
Well, if we're asking them to do a peer critique, maybe we'll have other tasks for students in time.
A course (we'll try to open this up for others too)
A way of pre-registering students for courses if all you have is a social identity
A group, for the group critique
Sometimes, in courses, students are in more than one group. For instance, they may have a tutorial group as well as a project group. Or their group may change every so often, but you'd like to preserve the historical groups they've been in in the past so you can look back on their previous work.
GroupSetwill support this
Preenrol for groups
The critique is going to need a survey form of some sort, which will be made up of questions. We'll establish the different kinds of question in a later commit.
(Likewise, there's an
The task of doing a critique