release 1.1.1RC2 : incompatible change to jscookMenu

[Simon Kitching <sk...@obsidium.com>]

Hi,

I've just tried the 1.1.1RC2 release with my current code, and found 
that the jscookMenu tag now throws an exception, with message:
   "You provided a wrong themeName.".

I see that new features have been added to support custom themes. This 
is fine, but please restore the original behaviour of accepting an 
unknown themeName value. A bump in the "patch-level" release number 
(1.1.0 -> 1.1.1) should not have changes that break valid existing user 
code.

I currently implement a custom theme by passing my own theme name to the 
jscookMenu class and then ensuring that references to the appropriate 
.js and .css files are inserted into the page too. The old jscookMenu 
code simply accepted the unknown theme name, included that name in its 
generated inline javascript, and skipped output of any references to the 
.js/.css for a built-in theme.


The problem change is to class
   org.apache.myfaces.custom.navmenu.jscookmenu.HtmlJSCookMenuRenderer


Possibly a *warning* (logged or even output as a js comment) could be 
generated by the jscookMenu code to recommend to people that they modify 
their pages to use the new custom-theming attributes, but throwing an 
exception isn't nice.

Thanks,

Simon

Re: release 1.1.1RC2 : incompatible change to jscookMenu

[Martin Marinschek <ma...@gmail.com>]

You are absolutely right - this should be addressed.

The thing is that we should also stay compatible to the other
components, and we haven't had a straight-forward way of implementing
this for the other components so far.

we need to bring the attributes:

-theme
-javascriptLocation
-styleLocation
-imageLocation
-addResources

to a consistent behaviour.

I would suggest saying that the theme can also be used as
themeLocation and it takes precedence before the others - addResources
should be dropped at all, it is only used in inputCalendar anyways.

What do you say?

regards,

Martin


On 10/7/05, Simon Kitching <sk...@obsidium.com> wrote:
> Simon Kitching wrote:
> > Hi,
> >
> > I've just tried the 1.1.1RC2 release with my current code, and found
> > that the jscookMenu tag now throws an exception, with message:
> >   "You provided a wrong themeName.".
> >
> > I see that new features have been added to support custom themes. This
> > is fine, but please restore the original behaviour of accepting an
> > unknown themeName value. A bump in the "patch-level" release number
> > (1.1.0 -> 1.1.1) should not have changes that break valid existing user
> > code.
> >
> > I currently implement a custom theme by passing my own theme name to the
> > jscookMenu class and then ensuring that references to the appropriate
> > .js and .css files are inserted into the page too. The old jscookMenu
> > code simply accepted the unknown theme name, included that name in its
> > generated inline javascript, and skipped output of any references to the
> > .js/.css for a built-in theme.
> >
> >
> > The problem change is to class
> >   org.apache.myfaces.custom.navmenu.jscookmenu.HtmlJSCookMenuRenderer
> >
> >
> > Possibly a *warning* (logged or even output as a js comment) could be
> > generated by the jscookMenu code to recommend to people that they modify
> > their pages to use the new custom-theming attributes, but throwing an
> > exception isn't nice.
> >
> > Thanks,
> >
> > Simon
> >
>
> On a related subject, it would appear that the "javascriptLocation"
> attribute is used to locate the JSCookMenu.js and MyFacesHack.js files
> *as well as* the custom theme's theme.js file.
>
> Can this be separated into two different attributes? I would like to be
> able to specify a theme.js file *without* having to extract the core
> files "JSCookMenu.js" and "MyFacesHack.js" from the tomahawk jar and put
> them in the same directory.
>
> I think introducing a new attribute whose value is the URL of the custom
> theme file is possible without causing any incompatibilities with prior
> releases.
>
> I'm happy to provide a patch to implement this...
>
> Regards,
>
> Simon
>


--

http://www.irian.at
Your JSF powerhouse -
JSF Trainings in English and German

Re: release 1.1.1RC2 : incompatible change to jscookMenu

[Simon Kitching <sk...@obsidium.com>]

Simon Kitching wrote:
> Hi,
> 
> I've just tried the 1.1.1RC2 release with my current code, and found 
> that the jscookMenu tag now throws an exception, with message:
>   "You provided a wrong themeName.".
> 
> I see that new features have been added to support custom themes. This 
> is fine, but please restore the original behaviour of accepting an 
> unknown themeName value. A bump in the "patch-level" release number 
> (1.1.0 -> 1.1.1) should not have changes that break valid existing user 
> code.
> 
> I currently implement a custom theme by passing my own theme name to the 
> jscookMenu class and then ensuring that references to the appropriate 
> .js and .css files are inserted into the page too. The old jscookMenu 
> code simply accepted the unknown theme name, included that name in its 
> generated inline javascript, and skipped output of any references to the 
> .js/.css for a built-in theme.
> 
> 
> The problem change is to class
>   org.apache.myfaces.custom.navmenu.jscookmenu.HtmlJSCookMenuRenderer
> 
> 
> Possibly a *warning* (logged or even output as a js comment) could be 
> generated by the jscookMenu code to recommend to people that they modify 
> their pages to use the new custom-theming attributes, but throwing an 
> exception isn't nice.
> 
> Thanks,
> 
> Simon
> 

On a related subject, it would appear that the "javascriptLocation" 
attribute is used to locate the JSCookMenu.js and MyFacesHack.js files 
*as well as* the custom theme's theme.js file.

Can this be separated into two different attributes? I would like to be 
able to specify a theme.js file *without* having to extract the core 
files "JSCookMenu.js" and "MyFacesHack.js" from the tomahawk jar and put 
them in the same directory.

I think introducing a new attribute whose value is the URL of the custom 
theme file is possible without causing any incompatibilities with prior 
releases.

I'm happy to provide a patch to implement this...

Regards,

Simon