[MyFaces-dev] Merging Shale into MyFaces

A couple of notes embedded below.

A lot of the reason you need an API for this is the original target
platform pre servlet Filters, although filters tend to be a pretty
clumsy way to assemble chain of responsibility workflows. I like the
way Struts2/WW do this a lot better, but even that would be more
elegant if you could use managed beans to load the executing logic,
and bind it together with EL expressions.
That's the same conclusion about the future that I've been coming to.
Its a pretty small set of utility classes, but the important point is
it is *independent* of component libraries. Maybe it could be a
jumpstart for the long-rumored Myfaces shared library that could be
used by all the component libraries for the boring utility stuff?
The thing I like most about Shale Dialogs is that you really can
abstract a significant amount of detail behind a common dialog
interface, and then pick a back end implementation with varying sets
of capabilities (and dependencies). Early on in Orchestra's life, I
had suggested to Mario that it would be cool to have an adapter so you
could Orchestra as your dialog implementation :-).

Longer term, this territory is going to get addressed by Web Beans
(JSR-299), which is likely to include all the scope stuff (and more
than Dialog has), coupled with annotation based dependency injection.

But I've always felt that support for scopes other than
request/session/application *really* belongs in the servlet spec so
all Java web technologies can use it ...
The original sweet spot for Shale Remoting was where you do *not* want
to worry about the performance overhead of recreating and updating the
JSF component tree on every Ajax request. Examples would be an
autocomplete component itself, doing async callbacks simply to get the
data it needs to offer as suggestions, with no impact on the component
tree. If you do need to manipulate the component tree, do what
Trinidad or Tobago do with their own components, or use something like
Ajax4JSF or Dynamic Faces instead.

A secondary benefit is near-zero config for resource access,
particularly for resources provided in a jar file instead of as
exploded files in a WAR. Until JSF 2 comes along, that's pretty
useful all by itself.
If you had all your business logic beans configured via Spring, it was
easier on the developer to configure their managed beans there as
well, and this module let you do that with Spring 1. For Spring 2 it
is not relevant, because Spring did it's own integration to let you
create JSF managed beans in whatever scope you want.
IIRC, this is already being used in various parts of the MyFaces source tree.
Not having to put *anything* in a faces-config.xml file is pretty nice :-).
Likely relevant for historical Struts1 users who want to stick with
JSP as their view technology. Not relevant at all for Facelets or
Clay based views.
The current code primarily adapts Commons Validator to JSF components
for server side validation (with a little help for client side
validation as well). The latter is a big missing link in standard JSF
input components, and it would be nice to see a Commons Validator
evolution to provide client side validators too, and some library like
this to wrap them for the JSF use case.

Think ov View Controller as providing *four* possible callbacks per
request, instead of the one you normally get in action frameworks (and
even JSF out of the box). Without this, you're basically thrust into
assembling workflows with filters or Struts2/WW handlers to deal with
some very common use cases.

Craig