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."

*_*