The Tale of the Read Only Input Text Item

It always starts out easy:

"If variable x has value y, it is forbidden to update values in column z."

Easy! ADF is well suited for the task. Some Groovy based business rules on the entity, and it just works. Simple, declarative, transparent and instantly enforced everywhere the entity is in use. Neat, isn't it?

In addition, the input item in the faces view reflects the change, and renders the input item as plain text.

"We want to keep the input box. Just disable the input text field."

Easy! On the af:inputText, just move the EL-expression from the ReadOnly property to the Disabled property, and set the ReadOnly property to false.

"We can't read the text. Set the text color to black."

Easy! Create and set a StyleClass with the ADF Skin Editor, or even some InlineStyle magic. Looks good in both Firefox and Chrome!

"We can't read the text in Internet Explorer, gray on gray is not a good combination."

Ah, I see... And I can't do much about it the "easy" way. IE won't let you set color of text on disabled elements.

Can I perhaps do something with the ReadOnly attribute to solve the issue? Nope, ReadOnly renders as plain text as soon as you touch it.

Google to the rescue.

Oh. Lots of other people with the same issue. OTN yields nothing but similar problem descriptions, all pointing to the fact that not being able to set the text color on disabled items is an IE issue.

Aino Andriessen has written a blog post describing a workaround to the same issue. Using a plain jsf input text lets you set the ReadOnly attribute, and still keeping the box intact. Yay! But blog post is from 2006, is this really all there is?

Add plain jsf input text and set Rendered property to a mutual exclusive expression with the updateable af:intputText.

Starting to get real clunky now, but it works. I even got the style class to match, and the number formatting right...

"Where is the context menu on the disabled fields?"

Doh! Take a deep breath. Context menu on plain jsf items? Just add an af:showPopupBehavior to the h:inputText elements and you are good to go! No? Ah, phases and what not, big runtime exception telling me I do not know what I am doing. Again.

Running out of time now. Stepping back to the Disabled and ReadOnly properties of the original af:inputText element. Hmm. I wonder.

Add some jQuery magic! The page already has jQuery included to do some fancy color highlight/fade thingys. Set DisabledProperty and let jQuery handle the rest after page load:
$('input[id^=<yourTableId>][id*=<yourColumnId>][disabled]').attr('readonly', 'true').removeAttr('disabled');

Simply put, it finds all input items in a given column of my table, and removes disabled attribute, and sets it to read only. I'm a genius!

"Works great the first time, but not after we push this button!"

Argh! Not so genius after all. PPR will of course ruin my newly crafted lifeline. jQuery live won't trigger correctly for some reason.

Getting really stressed out now. Explaining to the users that I do not know how to display a read only input box is not an appealing option!

Are there any javascript hooks like "I am now done refreshing your model driven table"? Diving into the ADF Javascript API. Looks like I can register a listener on the event triggering the refresh. Luckily there are just two ways for the user to invoke ppr refresh of this particular table, which means I can use af:clientEvent along with addBusyStateListener as described by Frank Nimphius in ADF Code Corner 027.

"It works now! Finally..."

Yes!

It started out simple, declarative and very maintenance friendly, but ended up as a slippery beast of a thing. All because I could not make ADF keep the box when setting ReadOnly on the af:inputText...

"By the way, we want to update the z column always. Just revert the last few changes."

*_*

Preparing to Work With ADF

So, you have started something in Oracle ADF without the safety of a tutorial. How do you even begin thinking about planning how to start developing? Welcome to this short five step program that will have you flying off the cliff in no time ;-)

Before You Even Start!
Move the properties window in JDeveloper! Did you see the nice categorized look of the object properties in the Quick Start Guide by Grant Ronald? If you want that look (and trust me, you do), move the properties window inside the bottom middle window.

One
I am a dinosaur. I enjoy reading books on real paper, so I buy those. I also like CTRL+F, so I get the electronic versions too. Anyway you do it, you have to have at least some essential books. They are important for more reasons than their actual technical content, they will help you realize just how much code you are going write. That is correct, you thought it was all declarations and xml files? Prepare to be amazed at the amount of "cheating" you have to resort to.

Recommended books:

• Oracle JDeveloper 11gR2 Cookbook by Nick Haralabidis
• Oracle ADF Enterprise Development Made Easy by Sten E. Vesterli

There are other books too, but these are the important ones for a real ADF project. If you are a complete ADF noob, start off with Grant Ronalds "Quick Start Guide to Oracle Fusion Development: Oracle JDeveloper and Oracle ADF", and follow up with (the slightly dated) "Oracle JDeveloper 11g Handbook: A Guide to Fusion Web Development".

I really, really wish I could have had the book by Nick Haralabidis earlier, would have saved me a ton of head scratching! Ah, well...

Two
The official docs. Keep them close. The most important are Fusion Developer's Guide, and Web User Interface Developer's Guide. A whopping 2960 pages pure enlightenment. I would also recommend installing the whole document library locally: http://docs.oracle.com/docs/cds/E24382_01.zip. If possible, insist on working connected to the Internet. JDeveloper is not as helpful as it could have been (it tries to reach oracle.com from the Help Center) when offline.

Three
Get your online resources ready. In my experience when you start developing, you will spend about half your time fiddling with JDeveloper, and the rest on various online sources. Prepare early by picking some winners:

• Google.com
  Hmm, yes, not really a big surprise. The thing is, Google has indexed a lot of pages, even some with ADF related content. To locate the good stuff, you have to be specific. Learn the lingo: vo, eo, am, etc. If you can, use method names or names of the standard classes (EntityImpl, ViewObjectImpl, ApplicationModuleImpl, etc). Also use faces component names ("af:outputText"), or names from the javascript api.
• forums.oracle.com
  This is where most of the technical stuff gets sorted out. It is a very active forum (and apparently Oracle product managers are spending some time there). I do not use Oracle's own search, but use a targeted Google search instead ("<your search term> site:forums.oracle.com").
• Sample code
  There are some resources besides the official tutorials; Oracle ADF Code Corner and corresponding blog by Frank Nimphius, Steven Muench's Not Yet Documented Examples (Look at the top of the page for more sample code resources),  Andrejus Baranovskis' sample list and some bits by Nick Haralabidis. AMIS also has some nice examples sprinkled in between their blog posts.
• youtube.com
  Yes, this is the way we are used to be entertained, so why not educated too? Pay special attention to ADF Insider Channel and Shay Shmeltzer's feed.

As I said, you will spend a fair amount of time searching the net, and you have to beware what you find. Often old and outdated resources are ranked high in Google, and if you are on 11.1.2, clunky solutions from 10g is not really what you want.

Four

Get the source code! Supported Oracle ADF customers can request the source code from Oracle Support. It might not be the first natural thing to occur to you (it would, if you were a "proper" java developer), and at this stage in your "project" it is not first and foremost because of the debugging possibilities.

With the source code you are able to see parameter names (and not just types) in the code editor, Quick JavaDoc actually works, and "Go to Declaration" actually goes to a place with code in it.

+1 to ADF. When developing in Forms or APEX you are calling black boxes, in ADF you are actually able to see what happens.

Five

Depending on how advanced you intend your first sample application to be, you might want to have a look at two utility classes used extensively in the ADF community. They go by the names ADFUtils and JSFUtils. In a real project, you definitely want them! Nick Haralabidis also mentions them in his book.

You will frequently see them in sample code, but where do they actually live? If you download the official Oracle Fusion Order Demo Application, and look into the StoreFrontModule workspace, under the Application Sources of the StoreFrontUI project, you will be rewarded.

...And off you go!

To be continued...

The Art of Self-preservation

This post is aimed at all those poor souls that find themselves facing Oracle ADF coming from a PL/SQL background (Forms, APEX or plain old database development).

Normal First Reactions
Despair. Most of us have felt it in the beginning, and it is considered perfectly normal. The feeling of constant despair will diminish slightly over time, but relapses will be frequent.

You will feel as if you have stepped 20 odd years back in time; yes, it has to be this hard to make even the simplest CRUD application.

You will have to pass some fairly elevated hurdles; yes, you have to learn (or at least have some knowledge of) Java, JSF, Expression Language, Groovy, CSS, HTML, Javascript and last but absolutely not least ADF itself.

Start in the Right End
You (or more likely your superior) bought the sales pitch, and thought you arrived to a mature, complete development framework specifically suited to leverage your existing Oracle investments. What you got was the biggest jigsaw puzzle ever, and all the corners missing. To even attempt fiddling around with the pieces, you have to have some basic skills.

ADF is a Java framework (although Java developers would call it xml-based). Java is core. You have to learn the stuff. You will not get far without Java. It is that simple. After all, the kids all learn it at school these days, how hard can it be? The answer is like always; 10% talent, 90% practice, it will take time to be good at it.

As a starting point, I recommend Head First Java. Not only is it educational, it will also help you to realize just how bad all other introductory programming books actually are.

The Next Step
As Java frameworks go, ADF is pretty big. Full JEE stack with lots of bells and whistles, and an abundance of XML-files. The good news is that you can achieve some pretty sophisticated behavior by declaration, the bad news is that you have to know where to turn the knobs. There are a lot of knobs.

First you have to learn the grand picture of the framework;

• The model, aka the meat, or business components
• The other model. Err? This is the binding layer, or view backend model or some such
• The controller thingy with task flows
• The view, as in GUI, and not to be confused with the view object in the first model. Argh...

Grant Ronald will help you on the way with his book Quick Start Guide to Oracle Fusion Development: Oracle JDeveloper and Oracle ADF. Do not let the lengthy title put you off, Mr. Ronald understands where you are coming from, and will gently nudge you in the right direction.

Ready Yet?
Well, that depends. Do you want to create tutorial applications, or the real thing? You should not balk at tutorials, that is not what I am saying. It is just that real business users have never had any clue how to best work with <insert technology/framework here>, they just have needs (of which, you are of course grateful, as it gives you work).

Users do not want to have plain CRUD anymore, they want to have an extremely functional and visually appealing working environment delivered at lightning speed. Business users will push you to the edge, they are both educated within their domain, and most likely used to some seriously fast client server applications.

Nervous?

Relax...
Stay sane just a bit longer. Take a deep breath, there will eventually be a light at the end of the tunnel. Let us hope it is not an oncoming train ;-)

Shay Shmeltzer has a more elaborate (and infinitely better) approach on how to get started with ADF in this blog post.

To be continued...

Updated Statement of Direction

...Of sorts. Actually, I did not even know I had one until now. But here goes:

My long absence from this blog are based on all the right reasons. Family. Life. You know, the things that matters. And some reasons slightly off. Like ADF. Yup, Oracle Application Development Framework. Just writing it out loud like that is probably going to make Dimitri's blog feed processor choke all over again, and get this blog instantly blacklisted from anything slightly PL/SQL related for all time.

The Old Road
My fascination with APEX has not diminished by far, and I hope to revisit extremelyproductivefundevelopingsmoothookingdatacentricapplications-land in the future. But for now, the "other" framework is more than enough.

The New Direction
Being a consultant will make you do strange things from time to time. This is one of those. Am I a Java-programmer? No. Do I know JSF? No. Am I a Groovy programmer? No. Am I at least proficient at Expression Language? No. How about ADF-skills? Well, some. I guess. Luckily, Oracle says I only need a week, or at least a day to become an expert. Hmm. I had to pass on OOW last year, due to a project using ADF... Catch 22 all over again.

I cannot say I am that sorry, actually. Learning new stuff (i.e. banging my head against a wall), and really trying to understand it (i.e. repeatedly), is part of my nature.

It was a professional change long overdue.

The Blog
I will continue to post my progress with ADF (or lack thereof) here, feel free to divert this blog from your favorite feed reader... Oh, and some APEX stuff will probably still make it here from time to time.

You can go wash your eyes now :D