[jira] Commented: (MYFACES-2629) Accept abstract FaceletContext, do not force AbstractFaceletContext

["Leonardo Uribe (JIRA)" <de...@myfaces.apache.org>]

    [ https://issues.apache.org/jira/browse/MYFACES-2629?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12867920#action_12867920 ] 

Leonardo Uribe commented on MYFACES-2629:
-----------------------------------------

I have attached another patch (MYFACES-2629-2.patch) with some changes.

After study the code I changed my mind about apply this patch for the following reasons:

- FaceletContext implementation works as a "page" context. Each time a call to include, or a template is applied, a DefaultFaceletContext instance is used to isolate the facelet id generation (see _prefix var).

- We have 6 stacks used for different objectives (composite components, ajax, bean validation ....) and all stacks are stored on facesContext attribute map. Each time we access one of this stacks we need to do a lookup on facesContext attribute map. If we have a FaceletCompositionContext, we could store all six stacks there and prevent the lookup on facesContext attribute map (just sharing an instance of FaceletCompositionContext on DefaultFaceletContext).

- All related code moved to FaceletCompositionContext comes from jsf 2.0, so if we move it, we'll keep the code close with the original facelets code.

I'll do some other enhancements to the previous code and commit it. Anyway, this issue will be let open, because this patch does not solve the main problem, but help us organize the code.


> 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, MYFACES-2629-2.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.