Friday is (sometimes) my Research Day.
The day when I get to expand my knowledge into new areas where we will be working soon, or experiment with new stuff. Sometimes I choose what this is going to be myself, sometimes the subject is chosen for me by my colleagues.
Last Friday I did some work on Cocoon. A rare and pleasant job for me.
I am working on a project at the moment that will use the Cocoon Portal Engine. It was my job to get my head around this clever, but complicated framework. During that process, I made an adapted version of it, that better suits the way we build projects. After making a bunch of changes, I though it would be nice to contribute these back to Cocoon.
I contacted the Orixo-Tech list, explained my changes and their rationale and asked for suggestions, as I know other people in Orixo are using the Portal, and must be having to solve the same kind of problems as I.
Carsten, who is someone I respect highly for his skills, but TBH have always been a bit scared of, replied. He is not quite so scary one-on-one, and we had a pleasant conversation about my suggested changes, how they fitted in with the general direction that he wants to take the framework and how we could do more work like this in the future to improve the Portal. That was cool.
I was able to contribute a couple of fixes for issues like missing page titles in the generated HTML, lack of portability due to hard-coded references to the server’s local URI and assumptions about how the project would be built. Our aim is that soon you should be able to more realistically use the Portal without replicating the whole project into your own, but merely adjust the configuration files for it.
As part of the fix, I was able to contribute an InputModule I had developed for use in-house. The ProjectPathModule, automatically works out the path back to the root of your project, from the point of view of the web browser.
A week or so ago, one of my colleagues was bending my ear about how irrational the names of the parameters you pass from the sitemap to the handleForm function provided by Cocoon Forms were. I agreed, it was an itch I had been meaning to scratch for a while now. I proposed some changes to the Cocoon-Dev list. There was a mixed response, some saying that that stuff was obsolete, others saying they disagreed and would like to see it fixed. We came to a consensus and I got to do the work.
At first I realised I did not even know how to construct this form. Luckily, Sylvain was available on Instant Messaging, and even though he was “insanely busy” was able to give me to time to show me how to do it. Very Cool.
Later it turned out that the SiteMap is unable to call Static Functions, so having consulted with Sylvain again, we realised we had a whole new bug!!
This is one of my pet projects in Cocoon. It is intended to be a really easy to use way of adding searching of XML documents to projects made in Cocoon. It is work in progress and has been driven by work developed for our clients. It is based on Apache Lucene, it allows you to build search queries without having to use a special query language, you get a history of your searches and the ability to persist your favourite searches for later use.
I got to work with Gianugo (always a pleasure) a few weeks ago on a project for Pronetics, he needed a search facility added to a job quickly. I was able to use QueryBean for this, but as I had been a bit lazy and implemented the function for the indexer which looks through a set of nested folders for files to index, using java.io.File, and his repository was kept in WebDAV, I had to re-implement that to use Excalibur Source API. Luckily it did not take long to do.
So, I ended up with an Indexer that can index any Collection (any TraversableSource). Meaning I had another nice contribution to make back to Cocoon.
That was a pretty satisfying research day.