[JAVASERVERFACES_SPEC_PUBLIC-781] Expose TemplateClient api to make gracelets work with jsf 2.0 Created: 31/Mar/10  Updated: 01/Aug/14  Resolved: 19/Dec/13

Status: Closed
Project: javaserverfaces-spec-public
Component/s: Facelets/VDL
Affects Version/s: 2.0
Fix Version/s: 2.2

Type: Improvement Priority: Major
Reporter: lu4242 Assignee: Unassigned
Resolution: Won't Fix Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Operating System: All
Platform: All

Issuezilla Id: 781
Status Whiteboard:

size_large importance_medium


This message is on behalf of Lewis Gass.

I am writing in relation to a particular use case which reveals that the
current JSF 2.0 public API is defficient. This is in relation the open
source project Gracelets (http://gracelets.sourceforge.net/) and the new
effort to integrate JSF 2.0 with Groovy. In order for people to use Groovy
as an alternative View Langauge they need
to have access to the all the Facelets tag libraries and participate in the
Templating framework that Facelets provides. Much of this is tied to the
TagLibrary and
TemplateClient API's. Before, with JSF 1.2, there was a single Facelets
"API" and/or implementation. So integrating with it was much simpler, as is
shown by previous Gracelets
versions. With JSF 2.0, part of the Facelets library was divided into public
API and another as JSF 2.0 specific implementation.

However, basic concepts such as Templating (TemplateClient and
TemplateManager) are not considered public API, which means that a
technology such as Gracelets
must rely on a per JSF implementation integration library which is volatile
in nature. The FaceletContext class is public API, but implementations are
not required to support
third party implementations of such, and there is no standard way to access
the TagLibrary used by facelets so that third part View Languages can
harness them.

Thus this message has the purpose of requesting such parts of the old
Facelets library, namely, the TagLibrary, TemplateClient and the related
FaceletContext methods (popClient(),
pushClient(), extendClient() and applyDefinition()) to be part of the public
JSF 2.0 API, while at the same time requiring JSF 2.0 implementors to
support third party implementations
of the same classes/API's.

Lewis Gass
Gracelets Coder

Comment by lu4242 [ 13/May/10 ]

Comments from this discussion: [jsr-314-open]
javax.faces.view.facelets.ResourceResolver cannot be fully overriden

Checking this issue on myfaces:


It was notice there is a way to override the default ResourceResolver, used to
load facelets templates, but the algorithm related to ViewHandler (spec pdf
section 7.5.2) says that if the physical resource exists with the name
requestViewId let that value be viewId, otherwise return null. So, if some user
try to load templates from other sources, the ViewHandler just will not work.

The problem is there is no standard way to retrieve the current ResourceResolver
object, so the ViewHandler just can't find them. In myfaces, this one is
instantiated on facelets vdl object, when it is initialized.

One idea to solve this one could be expose this object through vdl interface
(maybe a public method called getResourceResolver()?).

Since this issue is related to other ones that requires expose facelets api
objects, I'll not create an issue on the spec jira, but if it is necessary I can
create it.

Comment by Ed Burns [ 19/May/10 ]

Move to 2.1

Comment by Ed Burns [ 08/Jun/10 ]


Comment by Ed Burns [ 22/Jun/10 ]


Comment by Ed Burns [ 24/Jun/10 ]

Change target milestone.

Comment by rogerk [ 27/Oct/10 ]


Comment by Ed Burns [ 19/Dec/13 ]

We are considering extracting Facelets out of JSF for use outside of JSF as well as inside. This would have to be addressed in that case.

Comment by Manfred Riem [ 01/Aug/14 ]

Closing resolved issue out

Generated at Fri Feb 27 12:02:28 UTC 2015 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.