How to Write Your Own Custom JSF Variable and Property Resolver

Value binding is a powerful feature of JSF that implicitly creates the data and makes the model ready for the developers to process. Value binding expressions are simple strings like #{somebean.somevariable}, jsf processes this expression and creates the value to be used in later phases of the lifecycle. The facilities that extracts the value from these value binding expressions are resolvers called Variable Resolver and  the Property Resolver. Variable Resolver finds what the leftmost segment of the expression corresponds to. It looks at the several scopes of the application like application, session etc. When it finds a match, property resolver takes the step and extracts the remaining expression.When the variable resolver could not find a match, faces will use another variable resolver if defined in the faces-config.xml. For example Spring’s delegating variable resolver.
 
These resolvers are linked together and responsibility is passed to another.(Chain of Responsibility Design Pattern) If nobody could find a match than property not found exception will be thrown. Most JSF developers could remember the message that begins with Error getting property…:) What I like about resolvers that you can extend them, actually this is what I like about JSF generally. There are lots of extension points like resolvers, navigation and view handlers, components etc.

In our project we have lots of readonly lookup data that we bind to comboboxes or listboxes. We are using service methods that returns all the relative data from the db. The idea is to make a service call that actually calls Hibernate.loadAll(Class) method then we get the data in the lookup table as a list and bind it to a combobox or whatever. Day by day, many new entities come up and as you may guess for each one we need a new service method returning all of the corresponding the db. At this point I’ve decided to create a resolver that will work as a lookup resolver doing what the service method does without calling it:) For example, we have an entity called Job, and there is a lookup table T_JOB full of readonly Job records like engineer, doctor, nurse, other etc. Using the resolver we could retrieve all the Job objects like this and bind them to a combo by this;

<h:selectOneMenu id=”menu1″>
 <f:selectItems value=”#{lookup.some.package.domain.job.jobname.this.all}” >
</h:selectOneMenu>

The keywords I’ve used are lookup and all. lookup takes the attention of the variable resolver I’ve written and it answers yes when faces asks the resolver whether it knows what lookup means or not. all is another word that enables me to stop parsing the expression. Between these two keywords, class name and key-value pair are located. There are three classes that I’ve used;

You can download the sources above.

Finally declaring the custom resolvers in the faces-config is needed in order to put them to the responsibility chain:)
 <application>
  <variable-resolver>resolver.LookupVarResolver</variable-resolver>
  <property-resolver>resolver.LookupPropResolver</property-resolver>
 </application>

The flow is as follows;
1) When faces tries to resolve the expression it asks all the resolvers defined, the default resolvers will not resolve the expression since it begins with a lookup word, then faces will ask the lookupvarresolver and the resolving process begins.
2) The lookup property resolver will put each token after the lookup word to the LookupWrapper’s tokens list until it sees the token named “all”.When it sees the “all” word, the property resolver will return the lookupwrappers’s getAll method in the getValue method of its own.
3) LookupWrappers getAll method creates the object list by parsing the the class name and key-value pair. The wrapper has a Crud Service that we use in our project injected. Using the class name, wrapper reads all the data in the db and returs as a list.
4) For all the objects in the list, a select item is created. SelectItem is an entity of Faces. Each select item has a key and a value. The key and values are also in the expression thus using java reflection the getter of the key is called. Finally all of the selectitems are put in an array and returned.

Writing a custom variable and a property resolver will be tricky and in my view one should have a look at the source code of JSF and observe what the default variable and property resolver of JSF does actually. 

One Response to How to Write Your Own Custom JSF Variable and Property Resolver

  1. madhav bhargava says:

    I find that the EL in JSF is still unable to resolve the issue that i am facing:

    I have a Map of objects of type Address stored as values against String constants defined as public static constants in the same Address class.

    If i want to get an address of a particular type then today i will have to do the following:

    #{someBean.map[‘primary-addres’]} – Here i am hard coding the key which i actually wanted to come from something like Address.PRIMARY_ADDRESS.

    I wanted the EL expression to look like:

    #{someBean.map[Address.PRIMARY_ADDRESS]}

    Can you think of a way in which i can achieve this?

    Thanks,
    madhav

%d bloggers like this: