Engage 0.1: significant refactoring of Engage handlers

[Justin Obara]

I think all of those arguments are compelling enough to warrant its  
inclusion on the bug parade for engage.

I'll add it on now

- Justin
On 6-Oct-09, at 12:32 PM, Antranig Basman wrote:

> 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
> >
> _______________________________________________________
> fluid-work mailing list - fluid-work at fluidproject.org
> To unsubscribe, change settings or access archives,
> see http://fluidproject.org/mailman/listinfo/fluid-work