If you get an error that indicates that ADF/BC (the version out of JDev 10g) has compared the value it originally retrieved from the database to the value now in the database, and finds that they have changed; please, bear in mind that a database default value will do this on new records also!
So for example: you are now editing a record that you just created, suddenly you get this jbo error on a postback. The ADF Developer's Guide... says that in the case of columns altered by triggers associated with an insert, that you will need to check the "update after insert" checkbox in the entity for that attribute. The documentation does not specifically mention database table column default values, but these will have the same effect.
Once you realize this is what is happening you need only check these checkboxes to fix this.
Thursday, December 17, 2009
Monday, December 14, 2009
Just updated my blog profile
I just updated my blog profile to have a valid email address. I forgot that the one in there was not valid, since I am not job-hunting at the moment.
Sorry if it has caused me to give the appearance of ignoring anybody's questions.
Sorry if it has caused me to give the appearance of ignoring anybody's questions.
Friday, December 11, 2009
adding 1 or more blank rows to your af:table for data entry
Boy am I embarressed. I read the whole 1160 ADF 10g developers guide for 4GL developers from Oracle, have professional experience with building ADF, and claim to be becoming an expert in all this stuff.
But I had failed in getting this simple thing done before successfully: have more than one rows availble in an af:table to allow data entry. I kept running into trouble with validation on the second row. I knew how to do what I wanted in Oracle*forms, just not ADF/BC/ADF Faces!
To my credit though I am sure I must have inquired of the JDev Forum at least once before on this subject. Literally I had come up with an "alternative" solution on a prior contract, but it was WRONG!
The correct solution is very simple: like it says in the manual: whenever you do a VO.create(); follow that by taking the resulting row and saying resultingRow.setNewRowState(Row.STATUS_INITIALIZED);
Then you can VO.insertRow(resultingRow), or do whatever you want.
The odd part of this is, I guess, if you have overridden your initDefaults in the VO's entity, using the entity's setters may changed the status of this VO row from STATUS_INITIALIZED to STATUS_NEW. I kinda figured that if you have setter method calls (e.g., this.set...(blah))in that method that you would not "dirty" your row or entity. I guess that is not right.
At any rate: that's how it is supposed to be done.
So embarressed.
But I had failed in getting this simple thing done before successfully: have more than one rows availble in an af:table to allow data entry. I kept running into trouble with validation on the second row. I knew how to do what I wanted in Oracle*forms, just not ADF/BC/ADF Faces!
To my credit though I am sure I must have inquired of the JDev Forum at least once before on this subject. Literally I had come up with an "alternative" solution on a prior contract, but it was WRONG!
The correct solution is very simple: like it says in the manual: whenever you do a VO.create(); follow that by taking the resulting row and saying resultingRow.setNewRowState(Row.STATUS_INITIALIZED);
Then you can VO.insertRow(resultingRow), or do whatever you want.
The odd part of this is, I guess, if you have overridden your initDefaults in the VO's entity, using the entity's setters may changed the status of this VO row from STATUS_INITIALIZED to STATUS_NEW. I kinda figured that if you have setter method calls (e.g., this.set...(blah))in that method that you would not "dirty" your row or entity. I guess that is not right.
At any rate: that's how it is supposed to be done.
So embarressed.
Sunday, December 6, 2009
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.
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.
Subscribe to:
Posts (Atom)