[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [equinox-dev] modularized non-Java web content
- From: "Jochen Hiller" <jo.hiller@xxxxxxxxxxxxxx>
- Date: Mon, 6 Nov 2006 12:58:47 +0100
- Delivered-to: email@example.com
- Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=googlemail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=MJg4MlGSKuKs4fMr7U78Uy5iesKZ9eSmlk3/mfPNCsm5l3rn+G1W9wxEHrxxloyOeS3ccH6eswY9ZulEGGI/HOqVGea9G27hYOWQf7IVCDv3spA/iSwhBverthH9XQqFyKMY/rx4dNAEAgbGgG0QCL9O5s/D2bE/1SE0xiLa5+8=
On 11/6/06, Jeff McAffer <Jeff_McAffer@xxxxxxxxxx> wrote:
Recently there was a bug report about
some dojo stuff not working well with our http service. That prompted
me to try it out and indeed there is a problem. In any event, in
the process of trying this I got dojo and started to play. I was
not happy with the idea that I would put the dojo libs in my actual application
bundle since many different apps deployed to the same server might use
dojo. Furthermore, I assume that browsers are not smart enough to
handle the same libs at many different URLs in any sort of optimal way.
So I make a dojo bundle that included
Now an dojo-based bundle can contribute
content wherever it wants and include something like
This seems to work fine.
I agree: This should be the target scenario, to support building reusable components, in respect to restricted resources.
This got me to thinking about modularized,
non-Java web content. For example, what if there are multiple versions
of dojo on the server and different apps that need the different dojo versions.
We could have declared the dojo alias to be /dojo-0.4.0 and have
apps reference it but then the app would be tightly bound to that version
Then I though of having some sort of
variable that would be bound to the right version of dojo. for example,
and then dojo_base is set to the appropriate
URL fragment. This is better but in and of itself feels quite brittle
and would require quite a bit of maintenance.
You are completely right.
So then I thought, is there some way
we can use the OSGi dependency mechanism to handle this? For example,
I have a dojo bundle (called "dojo" with version 0.4.0 that surfaces
the dojo function at a particular (set of) URL. My application bundle
could spec a dependency
dojo; version=[0.4.0,0.5.0) (whatever)
and then if we could manage to have
the dojo references in my app's content replaced with the appropriate references
as surfaced by the dojo bundle, we'd be rockin.
In a certain light this is like having
Is there any precedence for this? Other
systems that do such things? mechanisms that we could leverage? Is
this just a goofy idea?
We are using a component based platform including UI resources. We achieve this behaviour this way: the service provider is registering its resources (in this case: a tupel of an unique ID and the corresponding URL,
e.g. in your case "url.dojo.base" to "/dojo", or "/dojo-0.4.0-ajax"). The services which refers to this resources will look up the unique ID to the registered URL.
We do it in a proprietary way. In OSGi context, this could be done via some kind of registry. Lets assume the
http.registry component will provide an additional extension point, where the service provider can register its "public resources", e.g.
<url id="url.dojo" url="">
Note: The <resource alias="/dojo"
base-name="/dojo-0.4.0-ajax"/> should not be used, as alias is the public URL seen by browser, but should not be used as identifier. It is also possible, that only specific parts of the resources should be made public viewable.
The "http.registry" bundle could provide a service (like "NamedHttpContextService) e.g. "URLResolverService", which can look up the ID to the corresponding URL (or provide a static helper method, for simple access).
For your scenario regarding script variables: typically a web application can store some values within its web container, e.g. referring attributes in ServletContext. The bundle "http.service" is just supporting this (but not yet used, or ?). If the "
http.registry" bundle would propagate these URL's in some way (e.g. key is uniqueID, value is the URL) to the servlet context, a JSP could refer to it using standard language features:
String dojo_base =
This can be made configurable via extension point:
<url id="url.dojo" url="" addToServletContext="true" />
This would need additional implementation in Eclipse based HTTP service, as navigation from HttpSession to HttpServletContext is not yet supported (due to Servlet-API 2.1 only support).
From my point of view, such a "plugin" concept for UI resources would be a necessary mechanism to build UI components. I strongly support your idea !