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

Leonardo Uribe edited comment on MYFACES-2629 at 3/31/10 5:31 AM:
------------------------------------------------------------------

I have attached a patch with the possible refactoring we can do in this case 
(just a first attempt). 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:

    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; 

There is a strong coupling between DefaultFacelet and DefaultFaceletContext. 
The constructor of DefaultFaceletContext expects a DefaultFacelet, 
TemplateManager only handle instances of DefaultFacelet ..... too bad, but 
that's the core of Facelets template mechanism. 

Jakob is right about this should be solved from the spec. I'm afraid if we 
refactor myfaces code more than the point proposed, it will cause more problems 
to gracelets, because in the future the code could change without previous 
warning. At this point I prefer let myfaces code as is without the patch, 
because if the patch does not solve anything why apply it?

Ok, so what could we do? In this moment it is unknown what classes or which 
code api is required to be exposed by the spec and why. From my point of view I 
can't see it cleary, because I don't know what requires gracelets to work. 
Maybe you can make clear those points and send them to jsr-314-open mailing 
list.

      was (Author: lu4242):
    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.

Reply via email to