[jira] [Commented] (WICKET-6156) tags substitute wrong value in CSS header contributor

["Gert-Jan Schouten (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/WICKET-6156?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15266878#comment-15266878 ] 

Gert-Jan Schouten commented on WICKET-6156:
-------------------------------------------

Also, the correct CSS property values are specified in a properties.xml file that is accessible by all Panels and Pages. It is called CSS.properties.xml and is added as follows, along with a lot of other properties.xml files that are accessible by all Panels and Pages (please forgive JIRA's bad code layout):

First, we created an implementation of IStringResourceLoader:

public class CommonPropertiesResourceLoader implements IStringResourceLoader {
	/** Please don't put the file extension in the list below, because Wicket will resolve that automatically, taking into account the current locale. */
	private static final String[] FILES = {
		"properties/CommonWords",
		"properties/css/CSS",
     		... more files
	};

	@Override
	public String loadStringResource(Class<?> clazz, String key, Locale locale, String style, String variation) {
		return this.loadStringResource(key, locale);
	}

	@Override
	public String loadStringResource(Component component, String key, Locale locale, String style, String variation) {
		return this.loadStringResource(key, locale);
	}

	public String loadStringResource(String key, Locale locale) {
		IPropertiesFactory propertiesFactory = Application.get() .getResourceSettings() .getPropertiesFactory();
		for (String file : FILES) {
			IResourceNameIterator iterator = Application.get()
				.getResourceSettings()
				.getResourceStreamLocator()
				.newResourceNameIterator(file, locale, null, null, null, false);

			while (iterator.hasNext()) {
				String path = iterator.next();
				Properties props = propertiesFactory.load(CommonPropertiesResourceLoader.class, path);
				if (props != null) {
					String value = props.getString(key);
					if (value != null) {
						return value;
					}
				}
			}
		}
		return null;
	}
}

Then, we added it as follows: this.getResourceSettings().getStringResourceLoaders().add(0, new CommonPropertiesResourceLoader());



> <wicket:message> tags substitute wrong value in CSS header contributor
> ----------------------------------------------------------------------
>
>                 Key: WICKET-6156
>                 URL: https://issues.apache.org/jira/browse/WICKET-6156
>             Project: Wicket
>          Issue Type: Bug
>          Components: wicket
>    Affects Versions: 7.2.0
>         Environment: Linux Mint, Tomcat 8, Java 8
>            Reporter: Gert-Jan Schouten
>
> In our project, we have CSS code in our <wicket:head> section. In that CSS code, we use the <wicket:message> tags to substitute often used values, for example:
> <wicket:head>
>   <style>
>     .b-SomeComponent {
>       line-height: <wicket:message key="CSS.lineHeight1" />;
>     }
>   </style>
> </wicket:head>
>  After upgrading from 7.1.0 to 7.2.0, some of the wicket:message substitutions in the CSS are wrong. Instead of the proper value, they get another, seemingly random value that is also used on the page. The value that they get is not necessarily another CSS property, but sometimes also a text value used in the HTML. For example, the above example could lead to:
> line-height: Hello World;
> if "Hello World" was used somewhere on the page.
> Due to the random nature of this, I have been unable to replicate this in a quickstart. However, the errors always occur on the same elements and are always substituted with the same wrong value.
> There is one ticket in the 7.2.0 release that also relates to CSS header contributions: https://issues.apache.org/jira/browse/WICKET-6052.
> Could you perhaps tell me which changes could be related to this issue and how I could use those specific changes to replicate this behaviour?
> Currently, we had to revert back to 7.1.0, as this bug makes 7.2.0 unusable to us.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)