Xpages, faces-config, managed beans, and scoped variables - xpages

Question

I have some properties in my database that will rarely if ever change, but are used pervasively throughout. It seems that this might be something I could do with a managed bean?
<managed-bean>
<managed-bean-name>bu</managed-bean-name>
<managed-bean-class> </managed-bean-class>
<managed-bean-scope>application</managed-bean-scope> </managed-bean>
I want to end up with a list of values in applicationScope.bu.
Do I just write a simple java implementation? Is there an easier or better way?

Answer 1

Your faces-config, to properly implement a managed bean, should include a block like you've put in, but you are missing the <managed-bean-class> value. This is what class will be created in memory (in your case, applicationScope). If your bean class has methods to return the values you're looking for, you're good. I'm a fan of beans (managed or POJO) and use this approach for a few applications.
[Edit]
As Steve points out in his answer, your need for accessibility, and quantity, of your configuration may drive how you store those values. How you interface with them may be different, and I lean heavily towards managed bean use.
For small amounts of values that need to be store for a given application, I like to set those in XSP Properties, then I can reference those via XSPContext.getProperty('xsp.property.name');.
For more complex things, I tend to create a config document, which I use as analogous to a profile document, which I then load from / store to the values.
[/Edit]
If you're looking for a good place to start with managed beans, or a quick reference for sanity checking, I'd recommend checking out Per Henrik Lausten's blog post on the subject.
The short version is, to have a managed bean, you must have:
a Java class
built with private properties (values)
which are exposed by public getter/setter methods
implements Serializable (java.io.Serializable)
contains an argument-less constructor (must take no parameters to be built the first time; not to mean that it can't go find values elsewhere)
an entry in faces-config (much like you've outlined)
binding via
EL with #{beanName.propertyName} (EL uses camel cased property names, converting, so the getter method of getPropertyName() is notated in EL as first shown
SSJS with #{javascript:return beanName.getPropertyName()} (full method invocation
You can then use your managed bean's name (in your case "bu") in either Expression Language or SSJS blocks. In the EL binding, note that the properties use camel casing to be accessed; so a property of myProperty is exposed by getMyProperty but looks like #{bu.myProperty}. You can also use it in SSJS, by the full method name, such as #{javascript:return bu.getMyProperty();}
Example
Here's one I have in my demo app is for a data object. It's in viewScope so it lives with the life cycle of a given XPage.
faces-config.xml
<?xml version="1.0" encoding="UTF-8"?>
<faces-config>
<managed-bean>
<managed-bean-name>gotHouse</managed-bean-name>
<managed-bean-scope>view</managed-bean-scope>
<managed-bean-class>com.westeros.model.HouseModel</managed-bean-class>
</managed-bean>
<!--AUTOGEN-START-BUILDER: Automatically generated by IBM Domino Designer. Do not modify.-->
<!--AUTOGEN-END-BUILDER: End of automatically generated section-->
</faces-config>
HouseModel.java
*I've modified this here for brevity as an example.
package com.westeros.model;
//...
public class HouseModel implements Serializable {
private static final long serialVersionUID = 1L;
private String name;
//...
public HouseModel(){}
public void load(String unid){
// do some load things from the doc's UNID
}
public void setName(String name){
this.name = name;
}
public String getName(){
return this.name;
}
//...
}
house.xsp (House XPage) *excerpted for brevity of example
<?xml version="1.0" encoding="UTF-8"?>
<xp:view
xmlns:xp="http://www.ibm.com/xsp/core">
<!-- truncating -->
<div
class="form-group">
<xp:label
for="name"
value="Name" />
<xp:inputText
id="name"
value="#{gotHouse.name}" />
</div>
<!-- truncating -->
</xp:view>

Answer 2

You can use managed properties of managed beans.
For example this little bean...
package ch.hasselba.xpages;
import java.io.Serializable;
#SuppressWarnings("serial")
public class MyBean implements Serializable {
private String dbName;
public void setDbName(String dbName) {
this.dbName = dbName;
}
public String getDbName() {
return dbName;
}
}
... can be initialized in the faces-config.xml
<?xml version="1.0" encoding="UTF-8"?>
<faces-config>
<managed-bean>
<managed-bean-name>myBean</managed-bean-name>
<managed-bean-class>ch.hasselba.xpages.MyBean</managed-bean-class>
<managed-bean-scope>application</managed-bean-scope>
<managed-property>
<property-name>dbName</property-name>
<value>MyName</value>
<property-class>java.lang.String</property-class>
</managed-property>
</managed-bean>
</faces-config>
As soon you acccess the bean, the value is "there". F.e. a label on your XPage...
<xp:label
value="#{myBean.dbName}"
id="label1">
</xp:label>
... will be then displaying MyName.
Managed properties can contain other beans, and access runtime properties (f.e. request parameters) which makes them extremly powerful.

Answer 3

If I understand your question correctly, I don't think the properties of a managed bean would be where you would want to store application properties.
I would just stick them in application scope on the landing page of your application.