Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • Please ignore if you've already moved on past this issue. If you've still got this one on the table, maybe the following notes will be of some use...

    If CVS (or whatever) is an option, you can check for conflicts and do a blind merge if no conflicts arrise. If conflicts would occur, you can echo them back to the user and let them resolve before commit.

    That approach may not work for one or more reasons. CVS (or whatever) may not be a prerequisite you want to have for Kontent installation. Merge skills may not be a prerequisite you want to have for content authors using Kontent-driven sites. Even if you could do the above, blind merges may not be appropriate for certain types of content. If Alice adds a parenthetical reference to "marsupial reproduction" early on in the content of the "about Australia" document, and commits that change just prior to Bob committing the change to remove that section in the interests of brevity, then the blind merge will result in an orphaned reference.

    In the past I'd had to deal with a simliar circumstance. Multiple medical staff were expected to be editing one on-line form. Certain nurses tended to edit these areas, the pharmacy tended to edit those areas, the attending physician tended to edit other areas, but everyone needed to read and edit all parts of the form. Usage was generally expected to be concurrent, and concurrent edits needed to never result in blind changes to the form.

    Each field was saved with field content, date of last modification, and user who last modified the field. Clients got the field content and a token which represented the last modification date, user who modified, and content (hashed with a server-side key to prevent tampering).

    When the server got an edit request, it would first verify that the user is requesting to edit the content that is currently in the database. If that was true, then it would apply the edit. If that was not true, it would send a note back to the user showing their (unapplied) revised content next to the current content in the database along with a note about who made the most recent change and when.

    The user could then edit the text again to incorporate their changes into the updated copy from the database (using the copy of their failed update for reference and/or copy/paste). If they had questions about conflicting intentions, then they knew who to talk to and could have them paged if they weren't nearby to ask.

    This approach seemed to work for that application. In this case, every field on the form was small. The largest fields were perhaps a small paragraph in length. For larger data, it might be akward to get your whole failed edit right next to the updated original, but perhaps a diff-like representation of their change could be shown instead.

    -matt