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