myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Lewis Gass (JIRA)" <...@myfaces.apache.org>
Subject [jira] Issue Comment Edited: (MYFACES-2629) Accept abstract FaceletContext, do not force AbstractFaceletContext
Date Tue, 30 Mar 2010 19:48:27 GMT

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

Lewis Gass edited comment on MYFACES-2629 at 3/30/10 7:47 PM:
--------------------------------------------------------------

After more investigation, it turns out this problem also comes up in the SUN RI. I sincerely
believe this should have been part of the public API in some way, but its probably too late
for that. In any case, this just means that each integration library I write for each respective
JSF implementation will be more involved. I have already did preliminary integration with
the SUN RI FaceletContextImplBase class and its working now with the TemplateClient internal
API, which seems to be replicated between both the SUN RI and MyFaces implementations. TemplateClient,
or at least the basic concept of the insert() and define() UI tags seem to belong really in
the public API. 

However, for the moment, unless you all just want to make the above proposed changes for other
reasons, I will have to integrate by all means with your FaceletContext implementation. In
fact if you put the TemplateClient methods (pushClient(), popClient() and extendClient(),
includeDefinition()) somewhere else it will break the ability of Gracelets to get involved
in that process, since Gracelets views can be used as TemplateClient's.

One thing I would ask is if you made the DefaultFaceletContext public, and not package private,
so that I do not have to reinvent the AJAX based extensions you have added to the AbstractFaceletContext.

      was (Author: elponderador):
    After more investigation, it turns out this problem also comes up in the SUN RI. I sincerely
believe this should have been part of the public API in some way, but its probably too late
for that. In any case, this just means that each integration library I write for each respective
JSF implementation will be more involved. I have already did preliminary integration with
the SUN RI FaceletContextImplBase class and its working now with the TemplateClient internal
API, which seems to be replicated between both the SUN RI and MyFaces implementations. TemplateClient,
or at least the basic concept of the insert() and define() UI tags seem to belong really in
the public API. 

However, for the moment, unless you all just want to make the above proposed changes for other
reasons, I will have to integrate by all means with your FaceletContext implementation. In
fact if you put the TemplateClient methods (pushClient(), popClient() and extendClient(),
includeDefinition()) somewhere else it will break the ability of Gracelets to get involved
in that process, since Gracelets views can be used as TemplateClient's.
  
> 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
>
> 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.


Mime
View raw message