[jsr-314-open] JSF 2.0/Facelets public APIs: ComponentHandler

[Andy Schwartz]

Ed -

Ed Burns wrote On 3/4/2009 11:24 AM ET:
> So, how big of a problem is my current approach of "because these
> features would be covered by VAST, and because we don't yet have VAST,
> let's not expose them now" going to be?
>
> Alaxander and Andy, can you *really* not live without the concepts
> suggested in points 3, 4, and 5 in Andy's original email to this thread?
>
> Ed
>

Sorry for not responding earlier... I wanted to take time to make sure
that my understanding of our (ADF Faces) requirements is accurate before
responding.  Also, thanks so much for moving ahead with the changes
needed to get ComponentHandler (and isNew(), applyNextHandler()) into
the public API.  I definitely appreciate this and I am sure that the
larger JSF/Facelets community will too.

So the predicament that I am facing is that without:

- Some way to find child handlers by type
- Some way specifically to find child text handlers
- Some way specifically to find facet/attribute handlers

I do not see an upgrade path for some of our more complex components
from Facelets 1.1.x to JSF 2.0.  Unfortunately several of these
components are used extensively throughout ADF Faces-based
applications.  For example, the af:pageTemplate component is used on
just about every page.

While I completely agree about the promise of VAST, and while I am also
excited about the prospects of a quick turnaround on a JSF 2.1, I need
to find some upgrade path to 2.0.  Without some solution to the
requirements that we have been discussing, I do not see that path.

In the hopes of finding some way to reduce our requirements, I took a
closer look at the findNextByType() implementation:


>     public final static Iterator findNextByType(FaceletHandler
> nextHandler,
>             Class type) {
>         List found = new ArrayList();
>         if (type.isAssignableFrom(nextHandler.getClass())) {
>             found.add(nextHandler);
>         } else if (nextHandler instanceof CompositeFaceletHandler) {
>             FaceletHandler[] h = ((CompositeFaceletHandler)
> nextHandler).getHandlers();
>             for (int i = 0; i < h.length; i++) {
>                 if (type.isAssignableFrom(h[i].getClass())) {
>                     found.add(h[i]);
>                 }
>             }
>         }
>         return found.iterator();
>
>     }


This is almost doable with the current public APIs, with one
exception.   CompositeFaceletHandler is currently in the RI (not API),
which means that here is no way for us iterate over the child handlers.
Instead of exposing a findNextByType() API, another approach to solving
our "some way to find child handlers by type" problem would be either to:

- Move CompositeFaceletHandler into the public API.  This class is tiny
- nothing especially controversial here.   Or...
- Alternatively, we could define a CompositeFaceletHandler interface in
the public API, if we do not want to move the implementation over.

So, assuming we do not want to support findNextType() in the public API,
I think that the minimal way to address the ADF Faces requirements would be:

- Define a CompositeFaceletHandler interface with a single method:
getHandlers().
- Move the existing (two method) TextHandler interface into the public API.
- Define a FacetHandler interface in the public API.  (This could either
be a marker interface, or, even better, define a single method -
getFacetName().)
- Define an AttributeHandler interface in the public API.  (This could
either be a marker interface, or, possibly with a single method -
getAttributeName().)

Adding these 4 very small contracts to the JSF 2.0 public API -
contracts that are already public in Facelets 1.1.x - would enable us
(ADF Faces) to port our Faclets 1.1.x TagHandler/ComponentHandler
implementations up to JSF 2.0, and thus allow Oracle/ADF Faces users to
adopt JSF 2.x more quickly.  While I appreciate the concerns about
getting too bogged down in Facelets-specific solutions ahead of VAST, I
don't think that adding these APIs should complicate the path to VAST in
any significant way.

Is there any chance that can reconsider our 2.0 plans - ie. any chance
that we can get these contracts in for 2.0?  This would greatly help
Oracle/ADF Faces and our ability to adopt JSF 2.0.  I am not sure
whether other frameworks/components have the same requirements, but
since these APIs are present in the currently available version of
Facelets, it is likely that others may benefit from this as well.

Of course, since I know that time is an issue, I would be more than
happy to help out in any way (eg. help with the spec or reference
implementation) if it would make it easier to get this in for 2.0.

And, again, sorry about the last minute nature of this request - I
realize that this would have been easier if I had caught these
requirements sooner.

Andy