Mailing-List: contact dev-help@myfaces.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "MyFaces Development" <dev@myfaces.apache.org>
Message-ID: <351897195.554501269881607843.JavaMail.jira@brutus.apache.org>
Date: Mon, 29 Mar 2010 16:53:27 +0000 (UTC)
From: "Lewis Gass (JIRA)" <dev@myfaces.apache.org>
To: dev@myfaces.apache.org
Subject: [jira] Issue Comment Edited: (MYFACES-2629) Accept abstract
 FaceletContext, do not force AbstractFaceletContext
In-Reply-To: <268129494.540561269831267206.JavaMail.jira@brutus.apache.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

Lewis Gass edited comment on MYFACES-2629 at 3/29/10 4:51 PM:
--------------------------------------------------------------

I imagined that you probably have "additional" functionality via the Abstract implementation, but could you use the wrapper pattern instead of casting?

AbstractFaceletContext actx = new SomeASFFaceletContext(ctx);

or

AbstractFaceletContext actx = ctx instanceof AbstractFaceletContext ? (AbstractFaceletContext) ctx : new WrapperContext(ctx);

And then pass on the calls to the original where possible and also allowing more functionality?

      was (Author: elponderador):
    I imagined that you probably have "additional" functionality via the Abstract implementation, but could you use the wrapper pattern instead of casting?

AbstractFaceletContext actx = new SomeASFFaceletContext(ctx);

And then pass on the calls to the original where possible and also allowing more functionality?
  
> 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.