This makes sense because the loading Facelet Composite Components already go through the ResourceHandler mechanism. It would make things more consistent to have Facelet View resources resolve/load the same way.
However this would have small impact to the Portlet Bridge spec. It has a feature where the developer can pass a path-mapped view path with a request parameter, and the bridge is supposed to check all the servlet mappings and then verify the existence of the resource by calling ExternalContext.getResource(String). I suppose it could call the ResourceHandler instead.
On Feb 29, 2012, at 5:39 PM, Edward Burns wrote:
> I had a 1:1 call with Kito today about this and the idea emerged to
> expand the charter of ResourceHandler so that it can take over what we
> have now as the Facelets ResourceResolver. The existing pluggability of
> the ResourceHandler would satisfy the core requirement of
> JAVASERVERFACES_SPEC_PUBLIC-719 as well as the resource-handling
> requirements articulated by Kito in his 20110419 post to
> JAVASERVERFACES_SPEC_PUBLIC-809.
>
> I need to prototype this and see how it would work but I like the
> ability to kill several birds with one stone from our existing API
> rather than inventing new API.
>
> Ed
>
> --
> | edward.burns_at_oracle.com | office: +1 407 458 0017
> | homepage: | http://ridingthecrest.com/