MODS Editor Using Cocoon Forms « Quædam cuiusdam
MODS Editor Using Cocoon Forms
Friday 1 April 2005 @ 10:32 pm

I’ve been working on a web-based editor for MODS records, to replace our current metadata management systems for our digitization project. As Art Rhyno has pointed out, Cocoon Forms (formerly known as “Woody”) provides a wonderful platform for developing complex web forms.

Try it out

Here’s an online demo which allows you to edit some sample MODS records. It currently doesn’t save the edited record, it just displays it back to you in XML. If you’d like to look under the hood, you can download it. To run it, install Cocoon, unpack the MODS editor into a convenient directory, and add it to the mount table something like this:

<mount src="/Docume~1/Peter/MyDocu~1/projects/mods/" uri-prefix="mods"/>

You can then access it at http://localhost:8888/mods/index.html (adjusting the port and such as needed).

Reasons to love Cocoon Forms

  • continuations. The management of the flow of the process (perhaps including several forms in sequence) is managed in a snippet of server-side javascript, in which the display of a particular form to the user is done by a function call. The javascript then snoozes until the user submits the form, upon which the javascript figures out what to do next.
  • a model-view-controller-style structure. You define the abstract data structure (model) in one place, the appearance of the HTML form (view) in another, and the binding of data from the source XML to the model (controller) in yet another.
  • Cocoon’s system of pipelines is available throughout the process. In a simple case, you can define the model, binding, and template each in its own XML file; but you can also have them defined by an XML stream issuing from a pipeline, having been customized as needed by all the tools available in that context. Perhaps selection lists need to be populated by database queries, or perhaps the list of elements to be displayed in this form needs to be filtered by an XSLT transformation so that it shows only the fields needed for describing maps.

How it works

As a simple example, here’s the publication date in a MODS record:

<mods:dateIssued>1994</mods:dateIssued>

The model defines this field thus:

<fd:field id="dateissued">
   <fd:label>Issued</fd:label>
   <fd:datatype base="string"/>
</fd:field>

(We’re treating this field as a string for now, but we can write validation rules to make sure we get a valid date). The binding from the XML source to the model looks like this:

<fb:value id="dateissued" path="mods:dateIssued" direction="both"/>

The id links to the field definition in the model, the path is the xpath to find the data within the source XML file, and direction specifies that the binding should be done both when loading and saving. (Again, we’re keeping this simple: we actually need to allow for multiple dateIssued fields, so we ought to use a repeater, which gives the user easy control over repeated fields.) Finally, the template looks like this:

<ft:widget-label id="dateissued"/>:
<ft:widget id="dateissued">
   <fi:styling size="15"/>
</ft:widget>

We put the label (as defined in the model), a colon, and a 15-character text box containing the value. It can all get much more complex than that, of course, but the building blocks are not difficult to master.

To-do list

  • draw the model, binding and templates through pipelines that filter them according to the type of resource. This will allow me to have one master definition of all MODS elements, and a set of stylesheets that filter out the elements you don’t need when e.g. describing a map.
  • make more use of CForms’ ability to make parts of the form depend on other parts; so when you select a “type” from a dropdown, the other fields rearrange themselves to present what’s appropriate for that type
  • write validation rules. These are included in the model on an field-by-field basis, and can be quite sophisticated (looking at values in other fields to determine what’s allowed in this one, etc.)

Final Questions

Will we get a truly usable editing interface this way, suitable for managing full MODS records? Will all the server-side work that Cocoon does slow things down too much? Could we work in more AJAX to make the workflow more smooth? Should I drop this and do it with XForms? Or Ruby on Rails? There’s plenty of room for optimization of what I’ve got so far; but whether it will be enough remains to be seen.

Comments (12) - Posted in XML by  



 12 responses to “MODS Editor Using Cocoon Forms”

  •   Kevin wrote:

    Very cool stuff!

    Have you given much thought to how to arrange the content to make it easy to edit? For instance, should it all be on one page (where scrolling down in necessary) or should it be in tabbed form (with a menu for each part of the record), should it all be in text boxes or should some text areas contain more than one chunk of data, or ??

    I know that is for a later stage of development, but I’m curious as to your thoughts on it. Anyway, this looks great to me (I’m also curious about the AJAX idea though).

  •   Bruce D'Arcus wrote:

    I don’t have any definitive answers for you. However, you might be interested in to know that eXist XML DB author Wolfgang Meier has been working on something similar using the Chiba XForms engine. He’s been quite happy with it, and plans to add it to the MODS example bundled with recent snapshots, which now make use of Ajax actually.

    For my non-library interests, I prefer MODS be hidden a bit from end users. So perhaps there are templates for different types. User chooses one, and the interface is populated with fields and metadata specific to that type.

    It’d be interesting to see a Rails example hooked up to BDB XML too though!

  •   art wrote:

    Awesome, Peter, this is a great showcase to be able to point to. I haven’t looked much at the demo, but there is a Chiba/Cocoon toolkit called Chicoon that brings XForms and Cocoon together, though Cocoon Forms is close enough to XForms that I think the knowledgebase is re-usable even if Cocoon Forms is discontinued at some point. Cocoon 2.1.7 has an AJAX demo in the forms block, though it’s sluggish.

  •   Peter wrote:

    Thanks to everyone for the comments. Kevin, I haven’t given much thought yet to how to break the form down over a series of transactions, beyond a general sense that vertical space should be economized at any price: the most annoying aspect of Cocoon Forms is the vertical scrolling when you add a new element (it always takes you to the top of the page and you have to scroll down to find your place). A tabbed arrangement would be great. Bruce, that’s great news that eXist will have a MODS editor – that might blow away my tinkering. Currently I’m using Xindice since it’s bundled in Cocoon but I do get the sense that eXist is where it’s at. And I agree, ultimately it would be good to wrap this is a less cataloguer-oriented template, and to make subsets of the MODS elements available for particular record types. And Art, I’ve been meaning to look at Chicoon but haven’t had a chance – have you tried it? Ajax support I think will be what makes the difference between a merely functional interface and a usable one. I started playing with Ruby on Rails on the weekend, and I can see myself falling in love with it…

  •   Bruce D'Arcus wrote:

    Yes, eXist is definitely way ahead of xindice. It’s also bundled with Cocoon.

    BTW, the two places the eXist MODS demo uses Ajax is for the “detail” display that is displayed when you disclose the row, and a auto-completing search field that’s based on the db index. There’s a bug or two still though.

  •   Peter wrote:

    Auto-completion from the db index?!? That would be amazing! I’ve been wondering how to bring in authority control (for subject terms etc.); this would allow some pretty sophisticated stuff. I can’t wait to try it.

  •   art wrote:

    Whoops, I wasn’t clear. I haven’t looked much at the Chicoon demo, my note makes it sounds like I was saying I hadn’t looked closely at yours. I would say, for now, that Cocoon Forms is the preferred direction because it has the deepest support within the Cocoon community, and it’s very easy to tie Cocoon Forms together with flow. Ruby is an amazing language, and Ruby on Rails makes a lot of sense for object modeling where the models don’t get too complicated. There’s a pretty good comparison on TheServerSide.com by Patrick Peak, not an unbiased source (Peak wrote a book on Hibernate), but I think his sense of where each fits rings true: that Hibernate is a good solution for complex models and Ruby on Rails is a good fit where the models don’t have as many layers. And this is sort of where I see Cocoon versus Ruby on Rails and other environments, Cocoon may be over-engineered for many solutions and unbeatable for others. I think the two latest Cocoon promotion projects use Drupal and this makes probably makes perfect sense for the problem set being addressed in each case.

  •   gavin wrote:

    i am not quite sure wat does cocoon do. can someone kindly explain to me?? can it be use to convert xml format files into html format file?

  •   Peter wrote:

    There’s a quick intro to Cocoon here (a little out of date, though). Cocoon is a publishing framework: it lets you take XML content and serve it in a variety of formats (HTML, PDF, other XML, etc. etc.) There’s an awful lot under the hood, so it’s worth exploring the examples that come with it.

  •   Derek wrote:

    Could you make a ZIP version of the demo available; the .gz one seems to be problematic under Windows…

  •   Jakob wrote:

    online demo does not work.

  •   Winona wrote:

    Hi Peter,
    Sorry to comment on such an old post, but I didn’t see an e-mail address. I’m very interested in taking a look at your MODS forms. I’m working on creating XForms for MODS and would love to see what you have done, as far as implementing elements/attribute data entry.
    Thanks!
    -Winona

Leave a comment