http://dablog.ulcc.ac.uk/2007/12/17/sneepcomment-update/
An alpha download for SNEEP.comment is available on the SNEEP test Eprints repository: http://sneep.ulcc.ac.uk/eprints/2/
This gives an idea of how the comments will work in conjunction with an EPrint abstract. It allows simple non threaded comments which can be displayed, added or updated within an abstract (or other page).
And now that’s out of the way I’ll give an idea of features that I would like to add. Some of these have arisen from the recent pow wow event and others were already stumbling around my mind. The existing interface is unlikely to change drastically most of the new features listed are tinkering under the hood.
- Comments as dataset – recode comments as an EPrint::Dataset and add the appropriate EPrint::DataObj::Comment
- Threading – implemented either by allowing comments on comments or by using some sort of stored threading data within each comment record.
- Better handling of markup – HTML Parsing is performed by default but failure is not well dealt with. Also would be good to offer a repo admins the opportunity to define an allowed subset using the sneep.xml config file.
- Comment on anything – Update the DB table structure so that the thing that is being commented on can be any other EPrint::DataObject. Also – with little or no work – allow for the possibility of commenting on external objects (might be useful where EPrints is running alongside other systems)
- Comment privacy (Notes) – Allow comments to be set as private so only the owner of the comment can view it (and re-badge as a note). Look into using EPrints security model for this as that will be neat and hopefully add some extra functionality.
- Object owner veto – Give the owners of various objects the ability to disallow comments being made on those objects (defaulting to permissive).
That’s the contents of my brains on this subject at the moment. If I have missed anything obvious or if anyone has any suggestions for the less obvious please feel free to add a comment.
One Comment
Sorry Rory, I think I broke it with bad markup.
I’d be interested to know what broad kinds of approaches there are to handling markup in this kind of application.
In the CERES catalogue entry forms for NDAD, I parse for well-formedness and send it back to the user if not. An alternative might be to escape all the markup if it’s not at least well-formed: if a user knows enough to be trying to use markup, they’ll soon get the message!
Or you could do what WordPress does – whatever that is!