From the Desk of Oracle ACE Director

Chris Muir

Subscribe to Chris Muir: eMailAlertsEmail Alerts
Get Chris Muir via: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn

Related Topics: Java EE Journal, Java Developer Magazine

Blog Feed Post

JDev Contextual Events: PayLoad, Payload, ah, Pay Load

Another blog post along the lines of "this caught me out, hopefully you'll learn from my mistakes"

Another blog post along the lines of "this caught me out, cost two hours of debugging, hopefully you'll learn from my mistakes."

JDev 11g readers will be familiar with the concept of contextual events, a powerful addition that allows task flows embedded in regions to communicate with each other, passing data payloads back and forwards.

Oh, did I say payloads? I meant pay-loads, or is that pay loads? Let's try Pay Loads. Geez what's the difference?

What am I on about?

Within the contextual event framework, effectively there is a "producer" task flow and a "consumer" task flow. The producer publishes a contextual event, and the consumer subscribes to the contextual event. It's all rather handily described in Section 28.7.1 of the Fusion Guide How to Create Contextual Events Declaratively

The publisher can pass a data payload (payLoad, PayLoad, um, pay load?) to the consumer. The publisher users an EL expression to extract data from their local bindings to do this, maybe something like #{bindings.employeeNo.inputValue}, which would be familiar to ADF programmers. The consumer however needs to use an EL expression #{payLoad} to capture the data from the published event.

Now to be specific here the EL expression is "pay" all lowercase, then "Load" with a capital "L" lowercase "oad", not "payload" all in lowercase.

What's the big deal? Well if you do anything else like #{payload} or #{PayLoad}, while the consumer will receive the published contextual event, unfortunately no data gets passed. Of course that's expected behaviour because EL is case sensitive and for whatever ADF internal code is calling behind the scenes, it can't resolve the Java routine name to lookup.

However the problem for developers is, in the English language if you search numerous dictionaries, you'll find the term is "payload", not two words "pay" and "load". It's therefore not intuitive for developers, something people I think will make a mistake on particularly when you read the examples where capital L looks very similar to a lowercase l anyway, and unfortunately, in JDev (at least where I tested this) the IDE gives you no warning that you've got it wrong at design time.

So hopefully for readers, forewarned is forearmed (or is that forewarned is forearmed?), and you wont waste an afternoon trying to get something that is in essence very simple to work.

Read the original blog entry...

More Stories By Chris Muir

Chris Muir, an Oracle ACE Director, senior developer and trainer, and frequent blogger at http://one-size-doesnt-fit-all.blogspot.com, has been hacking away as an Oracle consultant with Australia's SAGE Computing Services for too many years. Taking a pragmatic approach to all things Oracle, Chris has more recently earned battle scars with JDeveloper, Apex, OID and web services, and has some very old war-wounds from a dark and dim past with Forms, Reports and even Designer 100% generation. He is a frequent presenter and contributor to the local Australian Oracle User Group scene, as well as a contributor to international user group magazines such as the IOUG and UKOUG.