Details
-
Type:
Bug
-
Status: Closed
-
Priority:
Major
-
Resolution: Fixed
-
Affects Version/s: 2.0-Alpha2
-
Fix Version/s: 2.0-Alpha3, 2.0.0
-
Component/s: Documentation, Bridge, Framework
-
Labels:None
-
Environment:JSF 2 ICEfaces 2
-
Workaround Exists:Yes
-
Workaround Description:Ensure that h:head and h:body tags are present in all pages that use ICEfaces.
Description
There is a basic assumption with JSF 2 that when resources (typically references to JavaScript files) are targetted at areas like "head" and "body" that the page contains the actual "h:head" and "h:body" tags respectively. Without these tags, the basic ICEfaces bridge code cannot be made available. However, we have other areas of the code (e.g. ice.captureSubmit, deltaSubmit) that can add inline scripts that rely on these core resource files being available. The end result is that the scripts can get added to the page but the main files are never loaded and the browser complains that some JavaScript references (e.g. "ice") are undefined and no ICEfaces functionality is available.
For portlets, the same basic logic holds true. Although portlets don't typically allow rendering directly to the head or body, it's the responsibility of the portlet bridge to override the standard JSF behaviour and use other means (potentially vendor specific means) to ensure that calls to render code to the head or body are handled appropriately.
It is possible to have ICEfaces available but not want to use it on certain pages - in other words, it should be possible to mix ICEfaces and non-ICEfaces pages together within one application or portlet .war file so we need to ensure that in cases where h:head and h:body tags are not available, we don't render out any scripts that rely on resources targetted to those areas.
For portlets, the same basic logic holds true. Although portlets don't typically allow rendering directly to the head or body, it's the responsibility of the portlet bridge to override the standard JSF behaviour and use other means (potentially vendor specific means) to ensure that calls to render code to the head or body are handled appropriately.
It is possible to have ICEfaces available but not want to use it on certain pages - in other words, it should be possible to mix ICEfaces and non-ICEfaces pages together within one application or portlet .war file so we need to ensure that in cases where h:head and h:body tags are not available, we don't render out any scripts that rely on resources targetted to those areas.
Issue Links
- blocks
-
ICE-5543
ICEfaces2.0 htmlunit tests cause javascript error reading property "deltaSubmit"
-
- Closed
-
-
ICE-5565
ReferenceError: "ice" is not defined ICEfaces 2 with jsf2.0 htmlunit tests
-
- Closed
-
-
ICE-5568
jsfUnit tests fail when using <head> tags as BridgeSetup requires <h:head> tags to insert configuration into head
-
- Closed
-
Activity
- All
- Comments
- History
- Activity
- Remote Attachments
- Subversion
Added detection for the h:head and h:body components and disables all ICEfaces script insertions if they are not both there. It uses the HeadBodyListener class as a SystemEvent listener and modifies the EnvUtils.isICEfacesView() method to use this information.
JSF 2.0 requires the h:head tag for the jsf.js resource if Ajax is enabled manually in an non-ICEfaces page so requiring the h:head tag seems reasonable. It's also required for the portlet bridge to be able to override the rendering of the h:head component so that resources that are required for all portlets only need to be added once and they can be properly inserted into the head of the portal page.
We currently have some script snippets that get inserted into the body and so require the h:body tag as well (using root.addComponentResource(context, icefacesSetup, "body")
. They contain information like the viewID which, in a portal page, will be different for each portlet so it's not currently possible to put it into the head only once. If we'd like to remove the h:body requirement we can discuss other options. For now, in order to pass the tests and to operate in the client properly when the bridge is not available, you need the h:head and h:body tags in the page and, if they are not there, then there is no ICEfaces support.
There are still some kinks to work out around how to best do the detection of these components (there may be a JSF bug involved) and how to log/notify developers as to why ICEfaces has been disabled. I have some WARN level logging in there now but the EnvUtils.isICEfacesView method is called several times during processing of a single view so the logging is potentially dumped out several times.