[
https://issues.apache.org/jira/browse/MYFACES-2629?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12851011#action_12851011
]
Leonardo Uribe commented on MYFACES-2629:
-----------------------------------------
I never thought see one case like this.
In theory, it is not expected to have a wrapper for FaceletContext. Probe of
this fact are:
- There is no FaceletContextFactory or something similar.
- There is no documentation about when and where instance of this class are
created.
- The reason why FaceletContext is on the spec is to expose some methods
required by FaceletHandler implementations.
The reason why AbstractFaceletContext exists is provide a class that exposes
some inner methods required by facelets implementation. This includes:
- Handle TemplateClient class (used by "ui" components).
- Composite component cases.
- Partial State Saving methods.
- Bean Validation cases.
All those methods depends in one way or another of the state stored in
DefaultFaceletContext. Obviously it is possible to move this to some place (an
object stored on FacesContext or something similar), but I'm not very sure
about that.
If gracelets needs some specific code per impl to work, why don't create a
wrapper there that extends from myfaces AbstractFaceletContext and delegate
correctly, or even better, why don't we update myfaces code to expose in some
way what gracelets needs. I think the right place to put that code is on that
integration module. Other option is create a CustomFaceletContextFactory and do
on myfaces what is missing on the spec (like in LifecycleProviderFactory to
allow integration with web containers). In that place we can do something to
wrap FaceletContext object in a "standard" way.
> 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
>
> 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.
