Ok, I'm assuming at this point that we are going to have a 1.1 AND a 1.2
branch for the commons. If this is not the case some of the following
may be impossible. But I would like people's input on this to see if
it's something they would be interested in.
1. org.apache.myfaces.jsfcommons.services - A set of utilities for
loading "service" files from the META-INF/services directory in the
class path. Service files are a recommendation from J2EE as a design
pattern for supporting extendable frameworks. Essentially a services
file contains the names of all classes which must be instantiated and
returned for a particular service. Many of these files can exist for
any given service. For example, let say we have the following files in
the classpath:
jar1.jar/META-INF/service/org.apache.MyService
org.apache.myservice.impl1
jar2.jar/META-INF/services/org.apache.MyService
org.apache.myservice.impl2
Loading these services would return a list of the impl1 and impl2
objects. The cool thing about this framework is that dropping in extra
functionality is as simple as dropping a new jar in the classpath.
While this is not a JSF specific piece of functionality, something like
it is needed by the Configurators (see item #2) and I thought it might
be handy to have as a public API rather then wrapping it up in the
Configurator mechanism itself. Trinidad makes extensive use out of
services and is the "key" component to allowing us to build the
RichClient Framework off of the Trinidad core. Simply copying the
RichClient jars into the classpath gives you the extra functionality.
This would give all renderkits the ability to have this type of
"extensible" behavior.
This package could be in both JSF 1.1 and 1.2 compatible branches. Only
the 1.2 compatible branch (using J2SE5) would be able to support
generics which would increase the performance and ease of use of this
package.
2. org.apache.myfaces.jsfcommons.config - These are, essentially, and
expanded version of the Trinidad "configurators". Essentially
"configurators" allow a renderkit to do most of the tasks that are
typically done in filter (like multi-part form handling and the like)
without using a filter. Much like Tobago's implementation, the
configurator system leverages a special "FacesContext" that someone
could enable in their own jars. The configurator provides hooks that
allow execution of initialization logic to happen at various points
during an application (and request) lifetime. It even provides a
mechanism (based off of ExternalContext Wrapping) that allows
modification of the Request and Response objects. There are two real
benefits to using Configurator's as opposed to filters. The first is
that the Configurators are "configuration free". This means that a
renderkit can enable the configurator framework by simply including the
appropriate FacesContext object in their jar's faces-config.xml. The
second is that this framework will work within a portlet environment
which does not support filters in all cases and it makes a great fit to
JSR-301. One of the cornerstones of Trinidad's portlet compatibility is
the Configurator system and other renderkits should find it easy to
provide container agnostic functionality on their own as well. How this
solution differs from the one in Tobago, I believe, is that it is
generic and services based. This means that multi-part form handling is
simply one configurator service while a renderkit (or multiple
renderkits) can feel free to define their own.
Although I am not yet proposing Multi-part form handling implementation
at this time, we could use this mechanism to leverage such a solution as
Trinidad has done. The solution works great on both local and remote
portals as well as servlet environments.
This package could be used in both JSF 1.1 and 1.2 compatible branches
with the appropriate modifications.
3. org.apache.myfaces.jsfcommons.utils.ExternalContextUtils - Back when
we first started taking seriously about this project, some people
expressed interest in having Trinidad's externalContextUtils in the
commons package. This class is very simple and self contained and
handles some issues that renderkit developers may have in dealing with a
portal environment. In JSF the ExternalContext abstracts users from
having to drop down to the native request/response objects. But there
are some functions missing on the ExternalContext which require you to
load and cast the underlying request and response objects. The problem
is that with 2 different portlet request and response objects and the
servlet request and response objects, this can be cumbersome. This
utility provides some of this missing functionality as well as has the
ability to determine whether an ExternalContext contains Portlet objects
or not. The real benifit to this class, however, is that it doesn't
require the portal objects or the bridge to be in the classpath at
runtime. This means that you can develop a portlet compatible renderkit
which uses these methods, but don't need to have the portlet-api or
bridge classes present during runtime. It currently works independantly
of any bridge implementation so it should also work in both JSF 1.1 and
1.2 and will work with in servlet containers as well portlet containers
using any bridge.
Please let me know what you guys think of these proposals and if the
"idea's" sound good I can try to flush some things out and post some of
the API's and post some more specifics to the list. If people are NOT
interrested, I won't waste the time. :)
Scott
