[
https://issues.apache.org/jira/browse/MYFACES-2629?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12851731#action_12851731
]
Leonardo Uribe commented on MYFACES-2629:
-----------------------------------------
I have attached a patch with the possible refactoring we can do in this case.
The idea is create a class called FaceletCompositionContext, that works as a
context for all Facelet instances. Actually, FaceletContext instances are
created per each Facelet is traversed. This context is shared by all Facelet
instances.
The big problem is TemplateClient/TemplateManager code, in other words all code
related to this methods:
> 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.
