Engage 0.1: significant refactoring of Engage handlers

Colin Clark colinbdclark at gmail.com
Tue Oct 6 00:50:05 UTC 2009

Hey all,

Over the past few days I've been delving more into Kettle's current  
implementation, chatting about it with Antranig and Michelle, and  
learning more about URL routing and application structure in  
particular. As it becomes clearer, I've been refactoring Engage's code  
and architecture to better suit Kettle-based deployment.

Here's a JIRA ticket with some details:

In short, Kettle is design to have a single "front controller" servlet  
registered in web.xml, and a single Application per webapp. As we've  
got it set up currently, there's a separate Application and servlet  
registration for each service within the system. So we've got apps and  
servlets for Artifact View, Browse, and their respective data feeds.

This causes a fair bit of extra duplication within the code, and has  
caused problems with mounting these services at sane URLs. As a  
result, I've modified the current code so that there is a single  
Application (located in EngageApp.js) and a single associated servlet  
registration in web.xml.

Then, I wrote some very simple pseudo-framework code to initialize  
services by invoking registered init functions from the Engage app's  
configuration file. The EngageApp is also responsible for loading  
shared resources once.

I've written a couple of low-level utility functions, mountHandler()  
and mountAcceptor() to make URL routing a little bit easier. I expect  
all of these to be removed from end-user code as we start to build up  
a more resource-oriented abstraction for carving up the URL space and  
registering handlers for particular resources and representations of  
them. But this will do the trick for Engage 0.1.

This particular issue isn't on the Engage 0.1 Bug Parade, but it  
addresses the root cause of many of the issues that are on bug parade.  
Since I can't commit against non-parade issues, I've attached a couple  
of patches that show my progress. I've got Artifact View and its  
associated data feed working nicely, and Browse is close.


I'd love feedback and suggestions on this work. Given that it's so  
fundamental and coming along so well, do you think it's worth  
considering for inclusion on the Engage 0.1 bug parade?


Colin Clark
Technical Lead, Fluid Project

More information about the fluid-work mailing list