UI work

Last week I spent a huge amount of time getting the general interface of the relationship editor working: adding, removing, and changing relationships, along with the associated dialogs to do this.

Nothing can be submitted yet, but that's what I'm focusing on this week.

The UI in general took quite a bit longer than expected, because there were so many problems that occurred when an entity or relationship appeared more than once on the release. For example, some releases have duplicate recordings; even more have different recordings of the same work. When the user changes a relationship attached to one of these entities, it should change everywhere else it appears on the page.

These changes must also remain persistent if the user submits the form, but there are errors that they must correct. This is also something I'm working on this week. As it turns out, this isn't as difficult as I once thought: it's fairly trivial to embed the submitted CGI params in the page, and re-construct everything using JavaScript. I'm already halfway towards this goal.

The obvious missing features right now are batch relationship-adding/editing, batch work-creation, and release relationships.

The current progress is viewable at http://bitmap.mbsandbox.org/ - I try to keep this server running at all times, but keep in mind it's my development server, so it may not always work. The relationship editor is accesible from the the "Edit Relationships" tab on any release page.

More progress

At last week's meeting, we decided on a solution to MB's templating issues, but the design is yet to be finalized or implemented. At the moment my code still uses jQuery to clone hidden HTML fragments on the page, which is ugly and tedious.

My current challenge in implementing the relationship editor is the amount of information it needs access to on the page. To function properly, the JavaScript needs to know:

• What relationships the server has
• What relationships are pending (i.e. entered by the user), even if there's an error and the page refreshes
• A structure of link type data (including ids, allowed attributes, descriptions, link phrases, etc.).

These are partially solved by requesting this info from the database and embedding it into the template's JavaScript as JSON. If the new templating system were in place, it would be much nicer to be able request this data as it's needed (e.g. link type descriptions, attributes).

Some data we have to request as it's needed: for example, when a user searches for an entity, the rel editor needs to know all of its relationships. The XML web service is not sufficient for this, because it doesn't include database ids and other essential information. For this, last week I added an ?inc=rels argument to the /ws/js/entity web service: http://bitmap.mbsandbox.org/ws/js/entity/93889748-1092-3241-8b31-c648203415f3?inc=rels

With more of the backend in place, I've made a ton of progress. Although I missed the deadline for my first task ("Relate multiple recordings on a release to works"), I still feel that I'm ahead of schedule, because much of my code is portable to the other tasks, making them much easier to implement.

Small update

Some semi-exciting news is that I finally have a sandbox set up on mbsandbox.org, and I'll be pushing all of my changes so far to there within a few days, allowing people to test adding recording <-> work relationships. Once that's ready, I'll post a link here with instructions.

I'm at a bit of a roadblock with regards to templating. To display relationships on the page, both the client and server would ideally make use of the same templates. Otherwise, there's messy duplication that can lead to other issues. There's no existing solution for this in place on MB, so before I can write code that doesn't rely on such duplication, this issue will have to be discussed with the other MB server devs.