Engage 0.1: significant refactoring of Engage handlers

[Antranig Basman]

Hi there - yes, I also strongly support the comission of these files 
under ENGAGE-107. The original designer of Kettle left the framework in 
rather an incomplete state - in particular, no clear model was 
established for modularity of applications - since only one application 
was written :)
Without these changes it will be impossible to host more than one 
application at a time without falling back to non-portable infrastructure.

Cheers,
A.

Yura Zenevich wrote:
 > Hey Colin,
 >
 > I looked at the patches and the utility functions look great, this is 
exactly the commonality that the javascript webapps were lacking.
 >
 > Yura
 >
 > On Mon, Oct 5, 2009 at 8:50 PM, Colin Clark <colinbdclark at gmail.com> 
wrote:
 >
 >     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:
 >     http://issues.fluidproject.org/browse/ENGAGE-107
 >
 >     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.
 >
 >     http://issues.fluidproject.org/secure/ManageAttachments.jspa?id=13582
 >
 >     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
 >