Putting SPELs on ADF Code

Leon van Tegelen 3
0 0
Read Time:51 Second

There is a simple way to use the Expression language you use in JSTL expressions in your JSP’s, in ADF’s DataAction. Actually anywhere you can get hold of a LifeCycleContext (or any subclass) you can use SPEL. What you need is the class oracle.adf.controller.lifecycle.Evaluator.
You can obtain one like this
.

Evaluator eval = Evaluator.getEvaluator(lifeCycleContext);

You can feed this baby EL expressions just like in a JSP. The following code snippets show examples of doing it the code way as opposed to doing it the EL way

Getting a request parameter


daContext.getHttpServletRequest().getParameter("name");
(String)eval.getValue("${param.name}")

Setting a Session Atribute


daContext.getHttpServletRequest().getSession().setAttribute("SORTMANAGERPROVIDER", prov);
eval.setValue("${sessionScope.SORTMANAGERPROVIDER}", prov);

Getting a ControlActionBinding


DCBindingContainer bc = daContext.getBindingContainer();
JUCtrlActionBinding action = (JUCtrlActionBinding) bc.findCtrlBinding("sortAny");
JUCtrlActionBinding action = ( JUCtrlActionBinding ) eval.getValue("${bindings.sortAny}");

There must be some overhead involved in the ExpressionEvaluator. In my simple method I didn’t measure any significant differences in performance.
But be sure to SPELL your expressions right to avoid runtime errors ..

About Post Author

Leon van Tegelen

Consultant at AMIS
Happy
Happy
0 %
Sad
Sad
0 %
Excited
Excited
0 %
Sleepy
Sleepy
0 %
Angry
Angry
0 %
Surprise
Surprise
0 %

Average Rating

5 Star
0%
4 Star
0%
3 Star
0%
2 Star
0%
1 Star
0%

3 thoughts on “Putting SPELs on ADF Code

  1. Hey Leon,
    you’re right, I got JSTL and EL mixed up. There’s only so much new technology I can take 😛
    Still I’m not too fond of using EL in code; and looking back, I see you’re mentioning the point yourself:
    ‘But be sure to SPELL your expressions right to avoid runtime errors’. Making a typo in a getter would of course
    get you a compile-time error…

  2. Hi Hans
    I didn’t say there was a point to it ;-). It is just an alternative way of making your way through the objects. If the performance penalty
    isn’t too big I see no harm. Your other argument does not hold completely. eval.getValue(â€?${mybean.property}â€?) will actually return a null value
    not an empty String. In JSTL it is true that a null value will be represented as an empty String, but that makes sense in JSP.
    Also in both cases there is an equal amount of casting.
    Interestingly enough, in the source JDeveloper delivers with the ADF code ( adfc directory onder JDEv home ), the evaluator is not used. That makes you
    wonder why Oracle supllied it all. Maybe there is a dependency in the framework code they didn’t supply.
    I’ll put a post on OTN on the topic

  3. Hi Leon, I can’t see the point of doing so. Where’s the gain? Less typing?
    In fact, wouldn’t you be hiding errors in cases where objects are null, eg
    wouldn’t eval.getValue(“${mybean.property}”) evaluate to an empty string when
    mybean can’t be found / is null? Doing it in code would give you a NPE telling you there’s
    something wrong, while an empty String might go unnoticed…

Comments are closed.

Next Post

JDBC database copy of table contents

For one of our projects, we wanted to copy the contents of our production database to the test database. Both databases are accessible via JDBC. After an investigation of available tools, I had to revert to my own solution. Related posts: Steve Muench on improving ADF performance JHeadStart ADF beta […]
%d bloggers like this: