[ICE-8758] ice:outputStyle - Does not always work to deliver browser specific css files - ICEsoft JIRA Issue Tracker

Details

Type: Bug
Status: Closed
Priority: Major
Resolution: Fixed
Affects Version/s: EE-1.8.2.GA_P04, EE-3.0.0.GA_P01, 3.2
Fix Version/s: EE-3.3.0.GA, EE-1.8.2.GA_P07
Component/s: ICE-Components
Labels:
None
Environment:
All

Assignee Priority:
P3
Salesforce Case Reference:

Description

In the "ice:outputStyle" taglib documentation it indicates that the filename contained
in the 'href="file.css"' parameter will also attempt to deliver a browser-specific version of the CSS file
if the browser-specific file is found, and the "file.css" if not.

Icefaces uses the User-Agent header in the request to determine what browser-specific CSS file to deliver.

Browser-specific CSS files look like "file_ie7.css" or "file_ie8.css".

The way this delivery is accomplished in the original code is by appending a new "link" tag to the existing one, so there are then
two links seen in the source, one for the original file and one for the new browser-specific (e.g. "..._ie8.css") one.

In the example application we have two CSS files, and each of their browser-specific counterparts existing in the "css" directory:

css/test1.css
css/test1_ie7.css
css/test1_ie8.css
css/test2.css
css/test2_ie7.css
css/test2_ie8.css

When "ice:outputStyle" tags are provided for both css/test1.css and css/test2.css, we should see four <link> tags like this:

<link href="css/test1.css" rel="stylesheet" type="text/css" />
<link href="css/test1_ie8.css" rel="stylesheet" title="_ie8" type="text/css" />
<link href="css/test2.css" rel="stylesheet" type="text/css" />
<link href="css/test2_ie8.css" rel="stylesheet" title="_ie8" type="text/css" />

Unfortunately, sometimes this doesn't work.

In particular, if an absolute path starting with "/" is used in the "href" attribute, or if a relative path starting with ".."
is used, IceFaces OutputStyleRenderer code looks in the wrong place to determine if the browser-specific version of
the file exists.

Options
- Sort By Name
- Sort By Date
- Ascending
- Descending
- Download All

Attachments

Hide
Case11759Example.zip

30/Nov/12 11:57 PM

36 kB

Migration
Case11759Example/build.xml 3 kB

Case11759Example/.../ant-deploy.xml 3 kB

Case11759Example/.../build-impl.xml 58 kB

Case11759Example/.../genfiles.properties 0.5 kB

Case11759Example/.../private.properties 0.5 kB

Case11759Example/nbproject/.../private.xml 0.2 kB

Case11759Example/.../project.properties 3 kB

Case11759Example/nbproject/project.xml 0.9 kB

Case11759Example/src/conf/MANIFEST.MF 0.0 kB

Case11759Example/.../MediceComponentHandler.java 2 kB

Case11759Example/src/.../MedOutputStyle.java 0.6 kB

Case11759Example/.../OutputStyleRenderer.java 13 kB

Case11759Example/web/absolute.xhtml 0.7 kB

Case11759Example/web/.../absolute.xhtml 0.7 kB

Case11759Example/web/.../relative.xhtml 0.7 kB

Case11759Example/web/css/test1.css 0.3 kB

Case11759Example/web/css/test1_ie7.css 7 kB

Case11759Example/web/css/test1_ie8.css 0.3 kB

Case11759Example/web/css/test2.css 0.3 kB

Case11759Example/web/css/test2_ie7.css 7 kB

Case11759Example/web/css/test2_ie8.css 0.3 kB

Case11759Example/web/main.xhtml 2 kB

Case11759Example/web/.../context.xml 0.1 kB

Case11759Example/web/readme.txt 4 kB

Case11759Example/web/relative.xhtml 0.7 kB

Case11759Example/web/.../medice.taglib.xml 4 kB

Case11759Example/.../medice-faces-config.xml 0.9 kB

Case11759Example/web/WEB-INF/web.xml 3 kB

Download Zip
Show

Case11759Example.zip

30/Nov/12 11:57 PM

36 kB

Migration
Hide
Case11759ExampleWAR.zip

28/Mar/13 9:43 AM

9.35 MB

Arran Mccullough
Case11759Example.war 10.24 MB

Download Zip
Show

Case11759ExampleWAR.zip

28/Mar/13 9:43 AM

9.35 MB

Arran Mccullough
Document6.txt

28/Mar/13 2:01 PM

5 kB

yip.ng
Hide
ICE-8758-1.8.2_P07.war

16/Jul/13 10:41 AM

5.40 MB

Cruz Miraback
META-INF/MANIFEST.MF 0.1 kB

WEB-INF/lib/FastInfoset.jar 285 kB

WEB-INF/lib/backport-util-concurrent.jar 319 kB

WEB-INF/lib/commons-beanutils.jar 226 kB

WEB-INF/lib/commons-collections.jar 558 kB

WEB-INF/lib/commons-digester.jar 140 kB

WEB-INF/lib/commons-discovery.jar 75 kB

WEB-INF/lib/commons-el.jar 110 kB

WEB-INF/lib/commons-fileupload.jar 56 kB

WEB-INF/lib/commons-logging.jar 52 kB

WEB-INF/lib/icefaces-comps.jar 1.77 MB

WEB-INF/lib/icefaces.jar 1.24 MB

WEB-INF/lib/jsf-api-1.2.jar 355 kB

WEB-INF/lib/jsf-impl-1.2.jar 837 kB

WEB-INF/lib/jstl.jar 20 kB

absolute.jspx 0.4 kB

child/absolute.jspx 0.4 kB

child/relative.jspx 0.4 kB

css/test1.css 0.3 kB

css/test1_ie7.css 7 kB

css/test1_ie8.css 0.3 kB

css/test2.css 0.3 kB

css/test2_ie7.css 7 kB

css/test2_ie8.css 0.3 kB

main.jspx 1 kB

readme.txt 4 kB

relative.jspx 0.4 kB

WEB-INF/web.xml 2 kB

Download Zip
Show

ICE-8758-1.8.2_P07.war

16/Jul/13 10:41 AM

5.40 MB

Cruz Miraback
OutputStyleRenderer.java

01/Apr/13 11:14 AM

13 kB

yip.ng

screenshot-01.png

218 kB

27/Mar/13 5:04 PM
screenshot-02.png

120 kB

27/Mar/13 5:04 PM
screenshot-03.png

88 kB

27/Mar/13 5:35 PM
screenshot-04.png

96 kB

27/Mar/13 5:53 PM
screenshot-05.png

117 kB

01/Apr/13 11:05 AM
screenshot-06.png

126 kB

01/Apr/13 11:07 AM
screenshot-07.png

119 kB

01/Apr/13 11:09 AM
screenshot-08.png

278 kB

01/Apr/13 11:48 AM
screenshot-09.png

137 kB

01/Apr/13 2:00 PM
screenshot-10.png

151 kB

03/Apr/13 3:16 PM

Activity

Ascending order - Click to sort in descending order

Hide

Permalink

Arran Mccullough added a comment - 09/Nov/12 4:06 PM - edited

Comment from the customer on their fix:
To that end, we have created our own "medice:outputStyle" tag, which does provide the correct link tag in all valid circumstances.
This tag is back by code that extends the original icefaces tag code.
In the example application, we have four basic use cases:
Absolute path, top directory
Absolute path, child directory
Relative path, top directory
Relative path, child directory
Each of these uses cases are covered in a separate page. Each one of the pages has one invokation of the "ice:outputStyle" and
one invokation of our version of the "ice:outputStyle" tag - "medice:outputStyle".
All through the examples, the "ice" version of the tag tries to deliver test1.css, and the "medice" version tries to deliver test2.css.
In this back-to-back scenario, we can easily see that all valid paths work for the "medice" version, but some do not work for the
original "ice" version of the tag. For example in the "relative/child" scenario for IE8, we should see:
<link href="../css/test1.css" rel="stylesheet" type="text/css" />
<link href="../css/test1_ie8.css" rel="stylesheet" title="_ie8" type="text/css" />
<link href="../css/test2.css" rel="stylesheet" type="text/css" />
<link href="../css/test2_ie8.css" rel="stylesheet" title="_ie8" type="text/css" />
Instead, viewing the source, we see:
<link href="../css/test1.css" rel="stylesheet" type="text/css" />
<link href="../css/test2.css" rel="stylesheet" type="text/css" />
<link href="../css/test2_ie8.css" rel="stylesheet" title="_ie8" type="text/css" />
The "test1" css that is generated by the "ice" version of the tag, doesn't have the browser-specific link appended. That link tag is missing.
This is incorrect. The "medice" version correctly delivers both in this case.
The only use-case that works correctly is "relative/top".
You want to look at our com.med.icefaces.style.OutputStyleRenderer.encodeEnd(...) method in the sample app.
In it you will find that for the various use-cases, our custom extension of the Icefaces OutputStyleRenderer class searches
for the real browser-specific file on the filesystem in the proper places based on the input "href" path supplied. In some cases,
it will need to detect if the href starts with the context-root, and strip it off, so that the getRealPath can get the real path
of the file, to determine if it really does exist.
(Restricted to icesoft-internal-developers group)

Show

Arran Mccullough added a comment - 09/Nov/12 4:06 PM - edited Comment from the customer on their fix: To that end, we have created our own "medice:outputStyle" tag, which does provide the correct link tag in all valid circumstances. This tag is back by code that extends the original icefaces tag code. In the example application, we have four basic use cases: Absolute path, top directory Absolute path, child directory Relative path, top directory Relative path, child directory Each of these uses cases are covered in a separate page. Each one of the pages has one invokation of the "ice:outputStyle" and one invokation of our version of the "ice:outputStyle" tag - "medice:outputStyle". All through the examples, the "ice" version of the tag tries to deliver test1.css, and the "medice" version tries to deliver test2.css. In this back-to-back scenario, we can easily see that all valid paths work for the "medice" version, but some do not work for the original "ice" version of the tag. For example in the "relative/child" scenario for IE8, we should see: <link href="../css/test1.css" rel="stylesheet" type="text/css" /> <link href="../css/test1_ie8.css" rel="stylesheet" title="_ie8" type="text/css" /> <link href="../css/test2.css" rel="stylesheet" type="text/css" /> <link href="../css/test2_ie8.css" rel="stylesheet" title="_ie8" type="text/css" /> Instead, viewing the source, we see: <link href="../css/test1.css" rel="stylesheet" type="text/css" /> <link href="../css/test2.css" rel="stylesheet" type="text/css" /> <link href="../css/test2_ie8.css" rel="stylesheet" title="_ie8" type="text/css" /> The "test1" css that is generated by the "ice" version of the tag, doesn't have the browser-specific link appended. That link tag is missing. This is incorrect. The "medice" version correctly delivers both in this case. The only use-case that works correctly is "relative/top". You want to look at our com.med.icefaces.style.OutputStyleRenderer.encodeEnd(...) method in the sample app. In it you will find that for the various use-cases, our custom extension of the Icefaces OutputStyleRenderer class searches for the real browser-specific file on the filesystem in the proper places based on the input "href" path supplied. In some cases, it will need to detect if the href starts with the context-root, and strip it off, so that the getRealPath can get the real path of the file, to determine if it really does exist. (Restricted to icesoft-internal-developers group)

5 older comments

Hide

Permalink

yip.ng added a comment - 01/Apr/13 2:22 PM - edited

Done for 3.3: screenshot-05.png, screenshot-06.png, screenshot-07.png. Can't be done for 1.8 because getRealPath() is only available in JSF 2. We never used to check for existence of extra CSS file in 1.8: screenshot-09.png.

User-contributed code is in OutputStyleRenderer.java. Bulk of essential code slightly refactored into method instead of coded inline, so that it is more readable and maintainable. Just minimal refactoring to avoid introducing bugs. By the same token, non-essential code changes were not adopted even though they look cleaner: e.g. screenshot-08.png.

M: C:\svn\ossrepo\icefaces3\trunk\icefaces\compat\components\src\main\java\com\icesoft\faces\component\style\OutputStyleRenderer.java#34165

Show

yip.ng added a comment - 01/Apr/13 2:22 PM - edited Done for 3.3: screenshot-05.png , screenshot-06.png , screenshot-07.png . Can't be done for 1.8 because getRealPath() is only available in JSF 2. We never used to check for existence of extra CSS file in 1.8: screenshot-09.png . User-contributed code is in OutputStyleRenderer.java . Bulk of essential code slightly refactored into method instead of coded inline, so that it is more readable and maintainable. Just minimal refactoring to avoid introducing bugs. By the same token, non-essential code changes were not adopted even though they look cleaner: e.g. screenshot-08.png . M: C:\svn\ossrepo\icefaces3\trunk\icefaces\compat\components\src\main\java\com\icesoft\faces\component\style\OutputStyleRenderer.java#34165

Hide

Permalink

yip.ng added a comment - 02/Apr/13 2:10 PM - edited

[12:22:31 PM] Mark Collette: Yip: Ask Deryk about 1.8 ICEfaces utility method that might be equivalent to JSF 2 getRealPath

Show

yip.ng added a comment - 02/Apr/13 2:10 PM - edited [12:22:31 PM] Mark Collette: Yip: Ask Deryk about 1.8 ICEfaces utility method that might be equivalent to JSF 2 getRealPath

Hide

Permalink

yip.ng added a comment - 03/Apr/13 12:16 PM - edited

I believe com.icesoft.faces.util.CoreUtils has a couple of getRealPath methods that use reflection to call getRealPath safely in both portlet and servlet environments.

Deryk

Show

yip.ng added a comment - 03/Apr/13 12:16 PM - edited I believe com.icesoft.faces.util.CoreUtils has a couple of getRealPath methods that use reflection to call getRealPath safely in both portlet and servlet environments. Deryk

Hide

Permalink

yip.ng added a comment - 03/Apr/13 3:21 PM - edited

Done for 1.8 as well using CoreUtils.getRealPath(): screenshot-10.png.

M: C:\svn\ossrepo\icefaces\trunk\icefaces\component\src\com\icesoft\faces\component\style\OutputStyleRenderer.java#34220

Show

yip.ng added a comment - 03/Apr/13 3:21 PM - edited Done for 1.8 as well using CoreUtils.getRealPath(): screenshot-10.png . M: C:\svn\ossrepo\icefaces\trunk\icefaces\component\src\com\icesoft\faces\component\style\OutputStyleRenderer.java#34220

Hide

Permalink

Cruz Miraback added a comment - 16/Jul/13 10:41 AM

Confirmed fixed using ICEfaces EE 1.8.2.GA_P07 build2 in IE7/8. Attaching modified war file used for testing.

Show

Cruz Miraback added a comment - 16/Jul/13 10:41 AM Confirmed fixed using ICEfaces EE 1.8.2.GA_P07 build2 in IE7/8. Attaching modified war file used for testing.

People

Assignee:

yip.ng

Reporter:

Arran Mccullough

Votes:

0 Vote for this issue

Watchers:

3 Start watching this issue

Dates

Created:

09/Nov/12 4:04 PM

Updated:

14/Nov/14 5:42 PM

Resolved:

03/Apr/13 3:21 PM