Defining the date pattern via a properties file in XPages - xpages

Question

I want to define the date pattern in my application on a global level. Therefor I would like to use a properties file. Since I am already using one e.g. to set the default number of rows for a repeat control I added a ne wkey-value pair:
date_format_date_only=yyyy-MM-dd
In my application I have set the date format via convertors e.g.:
<xp:this.converter>
<xp:convertDateTime pattern="yyyy-MM-dd" type="date" />
</xp:this.converter>
But when I set it to
<xp:this.converter>
<xp:convertDateTime pattern="${application.date_format_date_only}" />
</xp:this.converter>
It is not working. The date is displayed as Feb 26, 2018. Application is the variable I have set via a Theme design element:
<resources>
<bundle src="/application.properties" var="application" />
</resources>
Am I overlooking something?
I notice that when I add the bundle directly to the XPage the pattern works but what is the use of a Theme design element then?

Answer 1

I do certain things through theme definition but not all. There are some restrictions that apply - read timing on theme properties evaluations.
I think your need would be the one of avoiding declaring the resource bundle in every page you use. Am I right?
In that case my advice is to tap into JSF mechanics more.
I personally set up a request scoped bean that I call MessageBean:
public class MessageBean implements Serializable {
private static final long serialVersionUID = 1L;
private ApplicationEx application;
private Locale locale;
private ResourceBundle app;
private ResourceBundle error;
private ResourceBundle log;
public void setApplication(Application application) {
this.application = (ApplicationEx) application;
}
public void setLanguage(String language) {
locale = new Locale(language);
}
public ResourceBundle getApp() {
if (app == null) {
app = getResourceBundle("app");
}
return app;
}
public ResourceBundle getError() {
if (error == null) {
error = getResourceBundle("error");
}
return error;
}
public ResourceBundle getLog() {
if (log == null) {
log = getResourceBundle("log");
}
return log;
}
private ResourceBundle getResourceBundle(String name) {
try {
return application.getResourceBundle("/WEB-INF/i18n/" + name + ".properties", locale);
} catch (IOException e) {
throw new FacesException(e);
}
}
}
In the faces-config.xml:
<managed-bean>
<managed-bean-name>msg</managed-bean-name>
<managed-bean-class>mypackage.MessageBean
</managed-bean-class>
<managed-bean-scope>request</managed-bean-scope>
<managed-property>
<property-name>application</property-name>
<value>#{facesContext.application}</value>
</managed-property>
<managed-property>
<property-name>language</property-name>
<value>#{facesContext.viewRoot.locale.language}</value>
</managed-property>
</managed-bean>
What this bean does for me is to wire up different property files - these are located under /WEB-INF/i18n/ - (which I split according to their domain of competence 'app' = general app messages, 'error' = error messages etc), and arrange them nicely under one single root: msg.
In other words I can declare anywhere in the page ${msg.app.hello} for the app resource bundle or ${msg.error.sorry} for the error resource bundle.
I don't have to declare any resource on the page, that's the magic of the beans. You don't use them, they are not created. You want to use them, the framework creates them and gives them to you automatically.

Answer 2

I notice that when I add the bundle directly to the XPage the pattern works but what is the use of a Theme design element then?
I believe the intention behind themes was to "define the look and feel of an application" (source) and I think this is reflected in the fact that resource bundles defined on a theme file only become available to an XPage during the beforeRenderResponse phase. So, as you've discovered, any properties that you want to access using a bundle declared on a theme can only be accessed via run time bindings and not on Page Load - and as Converters can't use run time bindings...
A couple of quick and simple SSJS workarounds to avoid adding the bundle directly to each XPage you build are:
Put the property in xsp.properties and access it using context.getProperty('foo') or, if you fall on the side of the debate that prefers not to add your own key-value pairs to xsp.properties
use context.bundle("application.properties").getString("foo") instead.
#shillem's answer about writing it all in Java and using a bean is probably more elegant and better practice - especially if you're using a controller framework in your applications - but the above will work.