Putting SPELs on ADF Code
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
<code>
daContext.getHttpServletRequest().getParameter("name");
(String)eval.getValue("${param.name}")
</code>
Setting a Session Atribute
<code>
daContext.getHttpServletRequest().getSession().setAttribute("SORTMANAGERPROVIDER", prov);
eval.setValue("${sessionScope.SORTMANAGERPROVIDER}", prov);
</code>
Getting a ControlActionBinding
<code>
DCBindingContainer bc = daContext.getBindingContainer();
JUCtrlActionBinding action = (JUCtrlActionBinding) bc.findCtrlBinding("sortAny");
JUCtrlActionBinding action = ( JUCtrlActionBinding ) eval.getValue("${bindings.sortAny}");
</code>
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 ..
-
Comments are closed
-
#2 written by Leon van Tegelen 8 years ago
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 written by hans 8 years ago
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… - Comment Feed for this Post
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…