Engage 0.1: significant refactoring of Engage handlers

[Yura Zenevich]

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
>
> ---
> Colin Clark
> Technical Lead, Fluid Project
> http://fluidproject.org
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.idrc.ocad.ca/pipermail/fluid-work/attachments/20091006/fd7bbaa3/attachment.htm>