Winston Prakash wrote:
>
>>>>> >If you VWP/Creator had fully implemented FacesContext like we had
>>>>> been asking over the years
>>>>> > then these design time tests would also not have to be necessary
>>>>> and again this issue would not have
>>>>> > arisen.
>>>>>
>>>>> We do. We use JSF RI 1.2 directly at designtime via JSF support
>>>>> module.
>>>>
>>>> Are you saying you are no longer creating a FacesContext wrapper ?
>>>
>>> We do. But it is a pure wrapper, in the sense it set the ClassLoader
>>> (Project Class Loader) and
>>> delegates everything to JSF RI 1.2
>>>
>>> But one thing I should mention, when we call the component rendering
>>> at design time, we directly
>>> call the encodeBegin(facesContext ) etc in the component, since we
>>> don't have a JSP container
>>> at designtime. So I don't see the possibility of creating
>>> ThemeContext at design time.
>>>
>>> Do I miss something about creating ThemeContext at designtime?
>>
>> If you create an implementation of ThemeContext like we implemented
>> JSFThemeContext, then VWP
>> can control all aspects of the Theme. For example it can choose which
>> class loader to use. It can
>> choose what the current theme is, i.e. switch themes when the
>> developer does, control the locale,
>> and in more detail choose the ThemeFactory implementation. It can
>> also provide design time
>> theme resources that could replace the "runtime" theme values in
>> cases where the runtime
>> value is not sufficient at designtime. This would have been ideal for
>> providing default values
>> in label's etc, but unfortunately we never got around to getting to
>> this level of "defaults".
>>
>> We have another hack in that we put the Theme name in the session,
>> which was for VWP/Creator
>> to switch themes. I don't know if this is still referenced by VWP.
>>
>> The instance of VWP's ThemeContext implementation ends up in the
>> "faux" VWP FacesContext's
>> servlet context.
>> When the components try to get a ThemeContext instance, they get the
>> one VWP created and
>> does not create an instance of JSFThemeContext.
>
> Ok I'll look at it, and see if we could use JSFThemeContext.
You should create your own specific implementation. Then you only have
to depend on "com.sun.webui.theme". If you reference "JSFThemeContext" then
you are dependedent on "com.sun.webui.jsf.theme" (a components package)
and JSF packages.
"com.sun.webui.theme" has no dependence on component classes or JSF.
You also may not want to inherit from "ServletThemeContext" which
"JSFThemeContext"
does, since you don't have a real servlet.
Remember the short term (or long term remedy depending on perspective ;)
is to just check
for "" in the "isDesignTime" block of JSFThemeContext.getResourcePath().
I'll try and also think of another way to get the context path that I
need in
call in JavasScriptUtilities.
-rick
> - Winston
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_woodstock.dev.java.net
> For additional commands, e-mail: dev-help_at_woodstock.dev.java.net
>