I have used Cocoon to publish TEI encoded XML files processed with XSLT (using Saxon), but I have never tried any other method of processing/publishing files. What alternatives are there? For many sites we generally use only a very small subsets of the features in cocoon - some basic redirecting and post processing.
Alternatives to Cocoon?
(14 posts) (8 voices)-
Posted 7 years ago Permalink
-
I haven't deployed a site with Cocoon in a while, but it always felt heavy (though very useful and flexible). Have you tried XTF? http://sourceforge.net/apps/trac/xtf/wiki
Posted 7 years ago Permalink -
Replying to @Stéfan Sinclair's post:
We are using XTF for a couple of projects, but someone else is doing the development on those. I should try to do an XTF site of my own so I can compare. I have a perception that XTF is rather inflexible, but I need to dig into it to see if that's true.
Thanks!
Posted 7 years ago Permalink -
Wayne Graham
MemberBest AnswerSpeaking from some experience with Cocoon and XTF, I try to advise people to actually find alternatives to these solutions. However, there are only a small number of ways to get around this, do mainly to the fact that the only XSLT 2 processor is the Saxon library implemented in Java.
After some pains with the limitations of XTF, a talented developer actually tackled the problem to see if one could build a "better" system. He came up with Raven (http://github.com/mwmitchell/raven) which is a pretty cool project that builds on Solr to build the site.
Another approach we've used is to pre-compile HTML views of XML (mainly TEI) using Rake tasks (see http://github.com/scholarslab/Faulkner-Audio-Collection). Mainly the pre-compilation of the view was for performance, since the XML does not change much, which makes things a bit easier to cache.
Both of these are capable of utilizing the Saxon library through jruby. With a little bit of planning (and rvm http://rvm.beginrescueend.com/), we can use XSLT 2.0 transformations, serialize them to file locations (and generate our Solr indexes), and then deploy them to production servers that are running MRI Ruby (default package manager install).
Anyway, check these examples out; they may solve some issues you will run in to with both Cocoon (current install uses maven to build) and XTF, let alone attempting to tune the JVM for the server running the application.
Posted 7 years ago Permalink -
Replying to @Wayne Graham's post:
Thanks! I have been pondering pre-generating the HTML. It might make the workflow annoying during the production of a site, when the XML sometimes changes and there's back and forth between the encoder and the designer. One idea would be to do development in cocoon and then deploy as a static HTML site.
Have you had any experience running saxon through PHP using javabridge? Is jruby a lot better in terms of server resources or ease of use? We have not yet used Ruby here.
Posted 7 years ago Permalink -
In the rails stuff, I've built rake tasks that I can call through the capistrano deployment (e.g. cap production deploy calls rake render:pre-render and rake render:gen_navigation). Essentially I just didn't have to even think of it, I let the system do the heavy lifting.
Javabridge was a complete disaster. This was a few years ago, and the project has progressed, but at least on the RHEL 5 boxes I was using, it was unstable enough that I completely abandoned it. In the Zend Framework, there are some bridge-ish things (e.g. the Lucene indexer), but after some discussions with the Omeka developers, this was a bit of a disaster for them as there seemed to be a hard limit of items you could have in a collection before seeing significant performance degredation.
I will say that the Faulkner-Audio-Collection could/should be patched to do the on-the-fly transforms to improve the workflow, then, at deploy time, use an appropriate caching mechanism to minimize the CPU load on big XSLT transforms.
Posted 7 years ago Permalink -
I can't believe I forgot this, but there's also a plugin for Omeka (see http://omeka.org/codex/Plugins/TeiDisplay) which can substitute for some of these other systems with TEI documents. Definitely another project to check out (and give us feedback). Particularly useful with the Omeka SolrSearch plugin (http://omeka.org/codex/Plugins/SolrSearch).
Posted 7 years ago Permalink -
James Smith
MemberIf you're feeling adventurous and want to integrate the TEI documents into a Radiant CMS, then you might want to look at http://github.com/jgsmith/radiant-tei-tools as an example of how to create a filter or Radiant tag that will transform the TEI document into HTML. This approach lets you treat the TEI documents as pages in the CMS.
If there's any interest in the Radiant extension, I'll try to update it with what I have working in production right now -- I've been focused on a lot of other stuff lately.
Posted 7 years ago Permalink -
It depends on a developer's needs really. I have used Cocoon extensively, eXist, various CMSes, etc. If what you really need is just quite simple dynamic transformation from XML to HTML and not all the bells and whistles of a CMS there are much simpler routes one can take. I have a need for a basic virtual URL remapper with dynamic transformations. None of this needs the complexity of any of the above methods.
For example:
http://blogs.oucs.ox.ac.uk/jamesc/2010/08/19/simple-dynamic-transformation-of-xml-with-htaccess-php-and-xslt/
shows one method of doing basic (sadly limited to XSLT1) dynamic transformations using just .htaccess and a really short php file that just says "transform this XML with this XSLT". The control of which XML/XSLT combination a particular URL gets is done entirely in the .htaccess file.What this can't do... well it could be not very prettily... is a long series of pipelined transformations.
However, one benefit of this kind of approach is that basic php and .htaccess are available on almost all shared hosting platforms where you might not have the ability or access to install other solutions.
Just my two pence,
-James Cummings
Posted 7 years ago Permalink -
Some of our old, XSLT 1.0 sites have been transformed using a simple PHP transformation (I believe that is how The Journals of Lewis and Clark Expedition - http://lewisandclarkjournals.unl.edu/ - is currently being handled) but our newer sites use XSLT 2.0 features.
I may just make an effort to restrict myself to XSLT 1.0 for our simple projects in the future.
Thanks everyone for your wonderful responses! I have a lot to look into.
Posted 7 years ago Permalink -
knickum.unl@gmail.com
MemberBeen meaning to respond to this also, co-worker of Karin's. Has anyone looked into any methods using python? I'm interested in changing some of the tools we use (for example, instead of using PHP --ugh -- I'd like it if we used Python/Ruby by default), so I'm trying to figure out some issues related to how we currently do things that may come up if we do that.
I'm curious (entirely ignoring the previous paragraph), it would be useful for some things we've done to be able to run xslt 2.0 functions in php. I've seen and heard JavaBridge is an option (though my experience so far has been the same as Wayne's), does anyone know of any other options? I can think of a few ways that might work, but nothing as elegant as JavaBridge at least purports to be (not that it even comes close!).
Posted 7 years ago Permalink -
The big problem with most of the functional language implementations for XSL is at some point they all rely on the underlying C libraries (libxml, libxslt). You'll see this limitation for XSLT 2.0 transforms, you're limited to using Saxon and it's supported libraries (Java and .Net). Really you're really left with two options if you want to use a functional language in your app, you're kind of limited to either jRuby (or something funky like LIFT or Clojure) or pre-processing the partial views.
That said, there is a partial C library for the XSLT 2 spec called libX (http://www.explain.com.au/libx/). If this project takes off, you could very easily write a wrapper in PECL, Ruby, or Swig to expose this functionality to the different languages. But it's not there yet.
What I would encourage you to also look at is some automated workflows. There are some heavy-weight options (e.g. BPEL), but also some pretty light options (see http://github.com/jmettraux/ruote) that go a long way in helping you establish a sane, sustainable, and ultimately transferable method of ingesting and disseminating content, independent of what front-end technology is chosen.
Posted 7 years ago Permalink -
Joe Wicentowski
MemberA bit late here, but let me echo James in suggesting eXist - it supports XSLT, XQuery, XProc, etc. (the major ways of querying and transforming documents), has powerful full text search of your XML, flexible URL rewriting and comes with the lightweight Jetty webserver (no Cocoon necessary). The site I work on, history.state.gov, is pure eXist + XQuery + TEI.
Posted 7 years ago Permalink -
Conal Tuohy
MemberFurther to @Joe Wicentowski's post mentioning XProc, you could use a batch-mode XProc processor such as XML Calabash to pre-build the HTML website. If you're familiar with Cocoon and writing pipelines, you'll find XProc is similar and easy to pick up.
Posted 7 years ago Permalink
Reply
You must log in to post.
