(dirty little) Trick for calling methods with multiple input parameters from JSF EL Expressions

4

I am not sure yet whether I have been really clever or am suffering from a twisted mind. In this article I present a grantedly farfetched approach for invoking methods from EL expressions in JSF (and JSP) applications – nothing spectacular so far – including calling methods that take one or even multiple input parameters.

Calling a method for retrieving its return value – other than normal bean getters – is not supported in JSF EL Expressions, outside of specific method-bound properties such as action. A trick for calling a method that does take at most one input parameters from an EL expression is using an object that implements the Map interface. Through a notation such as #{bean[object]}, we can invoke the get method on the Map implementing bean and pass as key parameter the object. The get method can use the key to decide which method to invoke or as the input parameter for the one method it knows to invoke. See: How to call methods from EL expressions- pre JSP 2.0 trick for JSPs with JSTL (June 2005) for a description of that ‘trick’.

I have extended that trick to allow for passing of multiple parameters. ....

Note: the trick described here is somewhat contrived. As far as I am concerned, that may be because I am overlooking some better approach and functionality in JSF or simply because I am looking for generic, declarative rather than specific and programming based solutions for my challenges. It does not reflect on limitations in JSF or EL as a whole, as I am a very satisfied JSF developer.

The actual call to the multi-parameter method is preceded by multiple calls to managed beans that act as placeholders. These placeholders are made available to the bean on which the multi-parameter method is invoked. In its very simplest form, we can invoke a multi-parameter method from a JSF EL expression in the following way:

#{((store1[row.Value1]) and (store2[row.Value2])?beanWrapper.method:'')} 

In this example, store1 and store2 are both managed beans that implement the Map interface. Their get method always returns true. The special element in this get method is that it stores the key value passed to the get method, and publishes it through a special getter: getStoreValue. The beanWrapper-method can retrieve the values for its parameters from the various store beans that have been injected into it, using the getStoreValue() method.  Then it can make the actual call, passing these parameters.

Multiple Parameter method calling in action 

I will demonstrate this approach in a simple example. Note: for this particular example, I would have easily extended the Book bean itself to implement a getSummary() method. I only use this simple example to demonstrate how the mechanism works. I have used it for complex applications, that are not as easily presented in a blog article.

The case is the Library system, that presents the books in our collection. Our model consists of the Book and the LibraryManager class, the latter returning a collection of the former. We want to present a list of our books using a readonly JSF datatable component. However, instead of the individual properties title, year of publication and author, we want to show a summary of those three values. For some reason we (pretend we) cannot extend the Book class to implement a getSummary method. We are forced to use the method bookSummary on a BookUtils class; this method takes three parameters: String, int and String. I will demonstrate the multiparameter-method-call trick for this bookSummary method (and again: this can be done in simpler ways, I just want to demonstrate the mechanism).

The JSF snippet that writes the book summary in the datatable is this one:

&lt;h:column&gt;<br />  &lt;f:facet name=&quot;header&quot;&gt;<br />    &lt;h:outputText value=&quot;Book Summary&quot;/&gt;<br />  &lt;/f:facet&gt;<br />  &lt;h:outputText value=&quot;#{((store1[book.title]) and (store2[book.publicationYear]) <br />                       and (store3[book.author]))?booksUtil.bookSummary:null}&quot;/&gt;<br />&lt;/h:column&gt;<br />&nbsp;

It refers to three managed beans store1, store2 and store3. These are the ObjectPlaceHolders that will record the value send to them as Map Key (in this case the title, publicationYear and author of the book). It then calls the bookSummary method on a managed bean called booksUtil. That is an instance of the BooksUtilWrapper class. Its getBookSummary method is shown here:

    public String getBookSummary() {<br />        return BooksUtil.bookSummary((String)param1.getStoreValue()<br />                                    , ((Integer)param2.getStoreValue()).intValue()<br />                                    , (String)param3.getStoreValue() );<br />    }<br />&nbsp;

It calls the static bookSummary method on the BooksUtil class, passing the three parameters it has collected from the JSF page through the three injected param members.

The rendered page in the browser displays the bookSummary:

 

Of some interest now are the faces-config.xml file with the managed bean definitions:

&lt;faces-config xmlns=&quot;http://java.sun.com/JSF/Configuration&quot;&gt;<br />  &lt;managed-bean&gt;<br />    &lt;managed-bean-name&gt;libraryManager&lt;/managed-bean-name&gt;<br />    &lt;managed-bean-class&gt;nl.amis.model.library.LibraryManager&lt;/managed-bean-class&gt;<br />    &lt;managed-bean-scope&gt;session&lt;/managed-bean-scope&gt;<br />  &lt;/managed-bean&gt;<br />    &lt;managed-bean&gt;<br />    &lt;managed-bean-name&gt;store1&lt;/managed-bean-name&gt;<br />    &lt;managed-bean-class&gt;nl.amis.jsf.util.ObjectPlaceHolder&lt;/managed-bean-class&gt;<br />    &lt;managed-bean-scope&gt;request&lt;/managed-bean-scope&gt;<br />  &lt;/managed-bean&gt;<br />    &lt;managed-bean&gt;<br />    &lt;managed-bean-name&gt;store2&lt;/managed-bean-name&gt;<br />    &lt;managed-bean-class&gt;nl.amis.jsf.util.ObjectPlaceHolder&lt;/managed-bean-class&gt;<br />    &lt;managed-bean-scope&gt;request&lt;/managed-bean-scope&gt;<br />  &lt;/managed-bean&gt;<br />    &lt;managed-bean&gt;<br />    &lt;managed-bean-name&gt;store3&lt;/managed-bean-name&gt;<br />    &lt;managed-bean-class&gt;nl.amis.jsf.util.ObjectPlaceHolder&lt;/managed-bean-class&gt;<br />    &lt;managed-bean-scope&gt;request&lt;/managed-bean-scope&gt;<br />  &lt;/managed-bean&gt;<br />    &lt;managed-bean&gt;<br />    &lt;managed-bean-name&gt;booksUtil&lt;/managed-bean-name&gt;<br />    &lt;managed-bean-class&gt;nl.amis.model.library.BooksUtilWrapper&lt;/managed-bean-class&gt;<br />    &lt;managed-bean-scope&gt;request&lt;/managed-bean-scope&gt;<br />        &lt;managed-property&gt;<br />      &lt;property-name&gt;param1&lt;/property-name&gt;<br />      &lt;value&gt;#{store1}&lt;/value&gt;<br />    &lt;/managed-property&gt;<br />        &lt;managed-property&gt;<br />      &lt;property-name&gt;param2&lt;/property-name&gt;<br />      &lt;value&gt;#{store2}&lt;/value&gt;<br />    &lt;/managed-property&gt;<br />        &lt;managed-property&gt;<br />      &lt;property-name&gt;param3&lt;/property-name&gt;<br />      &lt;value&gt;#{store3}&lt;/value&gt;<br />    &lt;/managed-property&gt;<br /><br />  &lt;/managed-bean&gt;<br />&nbsp;

And the ObjectPlaceHolder class:

package nl.amis.jsf.util;<br /><br />import java.util.Collection;<br />import java.util.Map;<br />import java.util.Set;<br /><br />public class ObjectPlaceHolder implements Map {<br /><br />    private Object storeValue;<br />    public ObjectPlaceHolder() {<br />    }<br /><br />    public Object get(Object key) {<br />        this.storeValue = key;<br />        return Boolean.TRUE;<br />    }<br /><br /><br />    pu
blic void setStoreValue(Object
storeValue) {<br />        this.storeValue = storeValue;<br />    }<br /><br />    public Object getStoreValue() {<br />        return storeValue;<br />    }<br />... and the trivial default implementations of the other methods in the Map interface<br /><br />&nbsp;

The BooksUtilWrapper class that takes the three params (inject ObjectPlaceHolders) and turns the call to getBookSummary() into a multiparameter call to BooksUtil.bookSummary:

package nl.amis.model.library;<br /><br />import nl.amis.jsf.util.ObjectPlaceHolder;<br /><br /><br />public class BooksUtilWrapper  {<br /><br />    ObjectPlaceHolder param1;<br />    ObjectPlaceHolder param2;<br />    ObjectPlaceHolder param3;<br /><br />    public BooksUtilWrapper() {<br />    }<br />    <br />    public String getBookSummary() {<br />        return BooksUtil.bookSummary((String)param1.getStoreValue()<br />                                    , ((Integer)param2.getStoreValue()).intValue()<br />                                    , (String)param3.getStoreValue() );<br />    }<br /><br />    public void setParam1(ObjectPlaceHolder param1) {<br />        this.param1 = param1;<br />    }<br /><br />    public ObjectPlaceHolder getParam1() {<br />        return param1;<br />    }<br /><br />    public void setParam2(ObjectPlaceHolder param2) {<br />        this.param2 = param2;<br />    }<br /><br />    public ObjectPlaceHolder getParam2() {<br />        return param2;<br />    }<br /><br />    public void setParam3(ObjectPlaceHolder param3) {<br />        this.param3 = param3;<br />    }<br /><br />    public ObjectPlaceHolder getParam3() {<br />        return param3;<br />    }<br />}<br />&nbsp;

In a subsequent article I will extend this trick a little to support collecting an array of values while itering over a collection. This can be used for example to calculate aggregate values over all rows in a table, like column totals.

Afterthoughts

After having completed this article and reading Jan’s comment, I realized that my example is really lame. I sort of overlooked the fact that inside any method invoked from EL expressions in the JSF page I can use EL expressions to get access to managed beans as well as objects created in iterations inside the page. That means that my contrived way of making the three parameters available to the booksUtil bean through the three ObjectPlaceHolders is totally ridiculous, as the bookSummary method can reach out to get at the book variable:

 

< <code>>  public String getBookSummary() {<br />    FacesContext context = FacesContext.getCurrentInstance();<br />    ValueBinding vb = context.getApplication().createValueBinding(&quot;#{book}&quot;);<br />    Book book = (Book)vb.getValue(context); ><br />< <code>>    return BooksUtil.bookSummary( book.getTitle(), book.getPublicationYear(), book.getAuthor());><br />< <code>>  }<br />>

That means that the applicability of my ‘trick’ is reduced to a small niche of situations, that may not even exist.

Resources

The JDeveloper 10.1.3 Application with the source code for this article: multiparametermethodcalldemo.zip

Share.

About Author

Lucas Jellema, active in IT (and with Oracle) since 1994. Oracle ACE Director for Fusion Middleware. Consultant, trainer and instructor on diverse areas including Oracle Database (SQL & PLSQL), Service Oriented Architecture, BPM, ADF, Java in various shapes and forms and many other things. Author of the Oracle Press book: Oracle SOA Suite 11g Handbook. Frequent presenter on conferences such as JavaOne, Oracle OpenWorld, ODTUG Kaleidoscope, Devoxx and OBUG. Presenter for Oracle University Celebrity specials.

4 Comments

  1. You are right that it introduces complexity in the page – programming of a sort where you would not want this to happen. I was looking for the trick in order to be able to use a generic bean that I do not have the source code for. However, perhaps I would be better of introducing just a wrapper between that bean and my page. Let’s say I found this trick to work and posted it to elicit some reactions from people like yourself. If I am misguided and this so-called trick is really utterly useless, I will happily accept that and move on to other useless stuff. That seems to be my forte.

    Lucas

  2. Jan Vervecken on

    I am not sure yet whether you have been really clever or are suffering from a twisted mind. ;-)
    It was an interesting read Lucas, but I’m not sure I understand why you want to work like this. Does this reduce complexity in your applications? Does this increase productivity in your applications?
    It also looks like this approach introduces code/complexity in places that are not intended to have such code/complexity in JSF and as such “short circuit” the JSF lifecycle, not?
    regards
    Jan Vervecken