Yeah, I would agree. I'll submit a JIRA ticket and then a patch as soon
as I can do the refactoring. Any other comments?
Simon Lessard wrote:
Hello Scott,
I'm fine with it as well since ExternalContext is part of JSF
standard, that class has no internal API dependency and 6 more utility
methods won't pollute the base API too much.
Also, if MyFaces ever get divided a bit more to include an
implementation independent module to be shared by Tomahawk, Tobago and
Trinidad, I think that class should be placed in there, so making it a
public API is a start.
~ Simon
On 8/30/07, *Matthias Wessendorf* <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> wrote:
I am fine w/ it.
On 8/29/07, Scott O'Bryan <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> wrote:
> Hello everyone,
>
> Trinidad has an internal class
> (org.apache.myfaces.trinidadinternal.util.ExternalContextUtils )
which
> contains some convenience methods used throughout Trinidad in
order to
> handle ExternalContext objects which may be backed by a
portal. It is
> used especially inside Trinidad's own Configurator framework
which is a
> public API.
>
> When making my own configurators for the upcoming RichClient
incubator
> project, and indeed throughout the Richclient code itself, I
have found
> myself using this internal API because it handles a number of
usecases
> that are not EASILY handled including working even when the
Portal API
> is not in the classpath.
>
> As a result, I'm wondering what people would think about
promoting this
> internal class to our public API?
>
> Scott
>
--
Matthias Wessendorf
further stuff:
blog: http://matthiaswessendorf.wordpress.com/
mail: matzew-at-apache-dot-org
