The proper tool for the job

My grandpa used to say, "The proper tool for the proper job!" I knew what he meant, and it seemed to apply to what I was experiencing yesterday.

I am using some Dojo widgits to get ADF Faces (JDev 10g/Trinidad) some extra functionality. It integrates pretty well. The way I am doing the integration each widgit I use requires a hidden field in the background. But I think there is a caveat. There is something that does not work right in some JavaScript I am using so that the integration code does not work right if there are only af:inputHidden's on the screen, and no actual input fields...just the dojo widgits providing that function. In other words there still needs to be at least one inputText for the dojo integration to work right. No problem, I just made my first dojo integrate with an af:inputText with a style of "display:none;". Works fine normally.

Well yesterday and the day before it was NOT working fine. I was imagining a SIMPLE use-case whereby I had several Dojo rich text editors on the same page. I thought: I will just bind the value of my hidden af:inputText to a backing bean getter/setter that just pulls the data it needs from the database when it needs it and caches it when possible on a session bean HashMap to avoid needless trips to the database.

I typed out some code how I imagined it would work...that was 3 working days ago!

Since then, trying to make af:inputText work, knowing what I know, I think I have encountered every caveat know to man related to using af:inputText and not binding to the database with ADF bindings. For one thing my setter would not fire! The processing would go through the motions like it WANTED to fire (i.e., it was firing "isReadOnly()" in the PropertyResolver when it was trying to evaluate my value binding. The only reason I know of to fire isReadOnly() is to test for fitness for doing a set, and every call it made returned "false", so I kept waiting for the setter to fire. It did not!

So I started thinking of alternatives. I thought: maybe I can use a valueChangeListener. It turned out that either the presense of the value binding or perhaps references to the binding layer (not for a value but just for VO attribute metadata purposes, like getting a value for required property) was diabling my use of the valueChangeListener, so I had a hard time even getting that to fire. When I got it to fire, it was without the value binding. So I switched to bind to an input component in my backing bean.

The nice thing about my original plan is that the getting and setting happens at all the right time, and since my af:inputText was inside an af:iterator loop, I need access to the requestScope "var" variable generated each loop. Using the getters and setters I had the perfect alternatives. But since that was not working out so well, I now was trying to figure out how to use this component I was bound to that is going through the ringer anyway to populate it. I was imagining that I would ultimately need a custom component that would give me the control I needed to be able to fire things at the right time so that I could hit the database for the values I wanted in time to use them as Dojo was loading, and also be able to save them back if someone updated the Dojo widgit.

Anyway, I was really not looking forward to going down that road, so after doing a few more experiments, I finally tried using h:inputText and going back to my original plan.

IT WORKED BEAUTIFULLY.

I was grateful; I did not have to slit my wrists after all! It worked so beautifully that I literally just connected up that code I created initially for the getter and setter, and everything worked according to plan, just like I had imagined.

I think the lesson I learned was, if you are going through ADF binding layer, there is probably no better solution than using af:inputText, and the like. And if not...if you have a simple JSF usecase that does not seem to fit the ADF Binding scenario, maybe you are (or at least, I am) better off using good old JSF components for simplicity and predictability sake.

One thing in my career I am trying to obtain is some depth and breadth to my knowledge. I think yesterday helped me obtain that just a bit more.