For the past couple of months I've been fairly interested in building up a certain CMS -- the so-called (SPINE CMS. I originally got interested in SPINE while trying to use it for some website. I was looking for a Perl/mod_perl/Apache-based CMS and there wasn't really much out there that didn't use somewhat larger and seemingly involved toolkits like Mason, etc. My rule of thumb is that if I have to read a book in order to make simple edits to the underlying code it may be a bloated project. This doesn't necessarily mean that I will always keep away. It does mean that I will take a more cautious view of the software. Sometimes simpler is better.
Immediately before getting into working on this CMS I got very interested in Foswiki, a wiki tool (also written in Perl) that is well developed, has an active developer following, and is freely available. I wanted to use Foswiki as a base for a LIMS. After some discussion with one of the Foswiki core developers who was also working on LIMS functionality I realized that in order to perform certain actions that we know and love in LIMS we would need to edit the core Foswiki system. So unless the Foswiki team was willing to start injecting LIMS-specific functionality into the core I would effectively have to fork Foswiki. Ouch. That was not something I was interested in doing.
So, rather than sit in silence or start reviewing yet another open source LIMS (I've downloaded a few since my last post) I got to work on something that interested me -- CMS.
In the next few articles I plan to 'brain-dump' what I've learned about CMS that are relevant to laboratory informatics. I'm not ready to jump on the Bika LIMS bandwagon (I'll explain why in a future article), but a solid foundation in what a CMS can and should do for a laboratory is in order. Expect this in the next few posts.Go Back
Citation: CMS versus Wikis versus LIMS. (2011). Retrieved Mon May 1 02:10:03 2017, from http://www.limsexpert.com/cgi-bin/bixchange/bixchange.cgi?pom=limsexpert3;iid=readMore;go=1321383045