[
https://issues.apache.org/jira/browse/MYFACES-2629?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12851872#action_12851872
]
Lewis Gass commented on MYFACES-2629:
-------------------------------------
I sent the following message to the jsr-314 expert group according to Jakob's
recommendation:
JSF 2.0 Expert Group,
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.
Respectfully,
Lewis Gass
Gracelets Coder
[email protected]
> Accept abstract FaceletContext, do not force AbstractFaceletContext
> -------------------------------------------------------------------
>
> Key: MYFACES-2629
> URL: https://issues.apache.org/jira/browse/MYFACES-2629
> Project: MyFaces Core
> Issue Type: Improvement
> Components: General, JSR-314
> Affects Versions: 2.0.0-beta-3
> Environment: Tomcat 6.0+, MyFaces 2.0.0-beta3 API/Impl.
> Reporter: Lewis Gass
> Assignee: Leonardo Uribe
> Attachments: MYFACES-2629-1.patch
>
>
> I am the main coder on the Gracelets project
> (http://gracelets.sourceforge.net/) and have recently began integration of
> Groovy with JSF 2.0. In order for Gracelets to harness the already existing
> Facelets libraries it needs access to the TagLibrary class and the actual
> libraries loaded by the JSF 2.0 implementation. Since that library is not
> part of the JSF 2.0 public API, I have to write an extension for each
> different JSF 2.0 implementation in order to load them. I have been able to
> successfully integrate with the SUN RI with minimal code. However, in MyFaces
> Core implementation this code appears on line 135 of the
> org.apache.myfaces.view.facelets.tag.jsf.ComponentTagHandlerDelegate:
> AbstractFaceletContext actx = (AbstractFaceletContext) ctx;
> Gracelets has its own FaceletContext (which is part of the public API) in
> order to mimimize integration between different JSF 2.0 implementations.
> Since in MyFaces this is forced to be a particular sub class here, it breaks
> portability. Is there anyway this can be avoided?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
