[
http://issues.apache.org/jira/browse/MYFACES-737?page=comments#action_12355632
]
Neal Haggard commented on MYFACES-737:
--------------------------------------
Also, adding the themeName to the javascript location for the theme specific
resources allows us to mirror the MyFaces setup for themes, we have the
following directory structure that we use:
/jscookmenu
|
+------ JSCookMenu.js
|
+------ MyFacesHack.js
|
+------+ ActionBar
| +----- theme.js
| +----- theme.css
| +----- other image files...
|
+------+ TableAction
+----- theme.js
+----- theme.css
+----- other image files...
This is due to the fact that if you specify a javascriptLocation, it uses that
for both the theme specific javascript location, and the overall javascript
location. We could move the JSCookMenu.js and MyFacesHack.js into the theme
specific folders, but then we end up with duplication of javascript, which
isn't good. It's bad enough we have to keep up with our own copy of those two
generic files. It'd be nice if the option was to specify a 'themeLocation'
instead, that was just used for our custom theme header resources, and it'd
still use the extension filter for the resources for the JSCookMenu.js and
MyFacesHack.js.
> JSCookMenu can't be used as a child of a form, and AddResources code for
> custom themes is incomplete
> ----------------------------------------------------------------------------------------------------
>
> Key: MYFACES-737
> URL: http://issues.apache.org/jira/browse/MYFACES-737
> Project: MyFaces
> Type: Bug
> Components: Tomahawk
> Versions: 1.1.1
> Reporter: Neal Haggard
> Attachments: jscookFormPatchV4.txt, jscookFormPatchV5.txt
>
> As is stated as a known todo in HtmlJSCookMenuRenderer, the menu can not be
> the child of a form because it currently hard-codes in the form name to
> change. To fix this, the renderer must examine it's parental chain to see if
> there is a form. If so, it needs to get the clientId of the form and use
> that instead of linkDummyForm.
> The second portion of this bug is that the AddResources code, specifically,
> the code in 'addThemeSpecificResources()' is incomplete/buggy. It checks to
> see if the theme name is set to determine if it is one of the pre-defined
> ones. However, even if you specify a javascriptlocation, you still must have
> a theme name set. To fix this, instead of seeing if theme name is set (which
> it always will, as it's a required tag attribute), the renderer should see if
> javascriptLocation is NOT set, before checking theme name for one of the
> pre-defined themes. This allows those of us with custom themes that want to
> use addResources to add them dynamically, to do so by specifying the
> javascriptLocation, styleLocation and imageLocation.
> Here's a sample usage of the javascriptLocation, styleLocation, imageLocation
> as I've fixed it:
> <h:form>
> <t:jscookMenu layout="hbr" theme="ActionBar"
> javascriptLocation="/jscookmenu/"
> imageLocation="/jscookmenu/"
> styleLocation="/jscookmenu/">
> <t:navigationMenuItem id="add_attachment"
> icon="/images/addAttachment.gif" itemLabel="Add Attachment"
> action="#{noteBean.addAttachment}" />
> <t:navigationMenuItem id="delete" icon="/images/delete.gif"
> itemLabel="Delete" action="#{noteBean.delete}" />
> </t:jscookMenu>
> </h:form>
> Note that I've made my own copy of the jscookmenu scripts in /jscookmenu/,
> and my theme, ActionBar, is also under the /jscookmenu/ folder.
> As an enhancement, it would be nice if the jscookmenu allowed a generic
> 'scriptLocation' element which would be used for all three,
> javascriptLocation, imageLocation, styleLocation.
> I will attach the patch that fixes these items.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
