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

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

The most difficult part here is move this methods:

    public abstract void pushClient(TemplateClient client);

    public abstract void popClient(TemplateClient client);

    public abstract void extendClient(TemplateClient client);

    public abstract boolean includeDefinition(UIComponent parent, String name)
            throws IOException, FaceletException, FacesException, ELException;

    public abstract void applyCompositeComponent(UIComponent parent, Resource 
resource)
            throws IOException, FaceletException, FacesException, ELException;

Really this is only "the tip of the iceberg". During the integration of 
facelets, I tried to do not change facelets code without a good reason, to 
prevent introduce bugs, after all, that code was not developed into our 
codebase, so we needed some time to understand how it works.

I'll assign this issue to myself. I think the need to create a MyFaceletContext 
instance and a MyFacesContext instance is clear (I want to do something similar 
to RequestContext and RenderingContext on trinidad), and also it is necessary 
to organize better facelets code, keeping in mind preserve performance of the 
code. I thought I could continue with tomahawk for jsf 2.0 but all myfaces core 
issues has more priority.

> 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.

Reply via email to