kogmbh/WebODF — pull request #189 by adityab (2013-11-18 18:11:50+00:00)
Title: Op-ify Member Data

This PR discards the old way of keeping track of member information, and introduces 3 new operations:

1. `OpAddMember`
2. `OpUpdateMember`
3. `OpRemoveMember`

A list of all members is stored in a `MemberManager` instance within `OdtDocument`.
This PR stops allowing arbitrary member models, so MemberModel.js and TrivialMemberModel.js are now gone,
and the aforementioned instance is the default.

In the local editor, when a document is opened, `Editor.openDocument` runs an `OpAddMember` operation, adding the `"localuser"` member we all know and love. `Editor.closeDocument` removes it before closing the session.

In the collaborative editing mode, it is the server's responsibility to add/remove members this way, for tighter control over who can get inside a document and do what, etc. For example, it could enqueue an `OpAddMember` but not allow any subsequent operations other than `OpRemoveMember` or `OpUpdateMember`, for a 'read-only' mode.

In the editor, any member who has been added to a session but whose cursor has still not been added, will now show up as a thumbnail in the sidebar.

Instances of the newly introduced class `ops.Member` can hold various properties about a member. Three properties are enforced as mandatory in WebODF, namely `fullName`, `imageUrl`, and `color`. Users of WebODF can add their own custom properties into a member object too.

Previously, due to API limitations, the `dc:creator` element in annotations was filled by a very nasty hack: SessionView would style the `:before` pseudo-element of a `dc:creator` having a given `editinfo:memberid` attribute with `content: "Member Name"` whenever new member data would arrive. Then, the `renderAnnotation` function would do a `window.getComputedStyle(creatorNode)`, retrieve the member's name from the styling of the pseudo-element, and use it to set the `textContent` of the creator element to achieve the desired result.
Now, `dc:creator` elements are directly accessed whenever a member is updated, and if they belong to the matching member ID, are immediately updated.

Further, currently the only way to see the 'effect' of member data operations is via annotations; therefore, tests are added that combine `OpAddAnnotation`, `OpAddMember`, and `OpUpdateMember`. Existing annotation tests are also improved because now we have a way to use author information in 'view-less' mode.