struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Craig McClanahan <>
Subject Re: Rép : [shale] Overall requirements for "remoting" feature
Date Sat, 31 Dec 2005 00:42:09 GMT
On 12/30/05, David Geary <> wrote:
> This proposal is almost exactly what I envisioned when I filed the RFE.
> Only
> one thing gives me pause:
> In addition, the configuration information mapping incoming URL patterns
> to
> > corresponding processing logic modules will be made available in a
> simple
> > JavaBean stored in application scope, so that dynamic code (such as the
> > renderer for a JSF component wanting to utilize these facilities) will
> > know
> > what kind of context relative URL is required).
> Given these capabilities, and assuming some default mappings, one could
> have
> > all of the following facilities with *zero* application level
> > configuration,
> > other than including the appropriate Shale library into /WEB-INF/lib:
> Zero-config is great, but IMO, this sort of business--mapping incoming URL
> patterns
> to code--should be configurable outside application code. The mapping bean
> is fine,
> and some developers will undoubtedly find that method of configuration
> indispensable,
> but I think it's too much to ask for simple cases.
> Of course, the best case is when developers can use Shale Ajax without
> even
> knowing
> that there's an API (or configuration) for mapping URLs. If we provide
> reasonable defaults for
> Ajax calls we can partially realize that goal.

I should have made it clearer -- this facility would be for the use of
widget creators (including JSF components and renderers), not applications.

Let's assume that Shale lets you map classloader resources to either
"/foo/*" or "/bar/*" (with some appropriate default that doesn't matter for
the point of this illustration).  Now, lets say I'm creating a JSF component
that wants to render a script reference to a resource (/baz/bop.js") that is
inside the JAR containing my components.  The renderer needs a way to know
whether to generate a reference to "/foo/baz/bop.js" or "/bar/baz/bop.js",
which in turn depends on how Shale is configured.

Applications will care more about mapping URLs to method bindings.  If the
application pages have direct references to static resources, they'll just
use the normal servlet container facilities for serving static resources
from the webapp, and not need to pay attention to this stuff.


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message