Here’s the story:
We needed multiple “dynamic tables” in our projects. Thanks to Russel Maher I had something to start off with.
Too bad his solution worked on the “backend” document. After I had managed to get a “container” around his solution another problem popped up: Save conflicts.
I couldn’t figure out why this happened. I could only imagine it was some sort of “timing issue”. In his solution upon a save a cleaning of the table is done. This merely renames the fields such that they order properly (in case some rows had been deleted). In this process the document was saved in the end. Cause I had several such “tables” to handle the saves of each of those kind of interfered and created those save conflicts.
But how could I solve this?
After a LOT, you should by the time now (if you followed my blog for a while) know what a LOT means!!! Enough to almost give up! Luckily I didn’t.
I figured: if I could only “reorder/rename” those items in the DominoDocument, then those changes would “magically” be transferred to the document upon the actual save. This is all thanks to the architecture of JSF, the data store etc.. (don’t ask me details, I am just about to get a hang on this one!)
So while I tried to get this working I always came accross this thing here.
As I mentioned in that other blog: that guy reporting this error on the Lotus forum had mentioned it happened when trying to put a NULL value vector somewhere.
After a LOT of testing I found: this is exactly what happened in my case!!! I was trying to copy values from date fields over (in order to rename them). But date fields which have no date simply have a NULL in them.
So the final solution was pretty simple: Just check if that item is available or has a NULL value.
Now my solution works smooothly: no more save conflicts, just the way I imagined!
Here’s how it could look like:
