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