Hey everyone,
Many of you have heard me talk about donating a "Configurator" system to
the commons project. To recap, this API will allow the various
renderkits to replace most (hopefully all) of their filter logic with a
J2EE Services based mechanism that is compatible with both Portlet and
Servlet environments. One of the many possible uses that I listed in
the intial proposal was to do cross-renderkit multi-part form handling
(file uploads) which I think at some point we might want to add to the
commons project so that multiple renderkits can be used at any given time.
If the configurator system is included in the commons util package, my
suggestion would be to turn it off by default and make it only available
if a renderkit or application enables it though the use of a
faces-config.xml entry (ie. you have to register a
FacesContextFactory). The alternative is that the configurators can
become their own package and the necessary faces-config.xml entry could
be built as part of the jar. The advantage of this is that any
renderkit or application needing the configurator functionality would
simply drop the jar into the classpath somewhere. The disadvantage is
that this would be yet another jar that would have to be added to
dependent projects and it's likely that this piece will become core
functionality for all renderkits ESPECIALLY if we add a common
multi-part form handler.
There is a third option and that is to have the "utils" mechanism always
set up the configurator subsystem. The performance impact of the
configurator system should be negligible, especially with no services,
but it might register an unneeded FacesContextFactory whenever the
commons utility package is used which might not be appealing to some.
It would solve both the configuration and extra-jar issues however and
if people think these configurators are likely to become a core piece of
the different render kits then it might not be terrible to have the
configurators enabled and ready to go.
Also, if we can keep the multi-part form handling or JSF 1.1 arguments
out of this discussion, it might help expedite things. If need be the
configurators can be ported back to 1.1 and multipart form handling can
be enabled/disabled regardless of whether configurators are turned on by
default. So both of those discussions can be talked about at a later time.
Let me know your thoughts and after I get some feedback I'll start up a
vote.
Scott
