In a recent project I’ve extended the document wrapper Tim Tripcony showed in his NotesIn9 series on XPages and Java. Previously I’ve just used the dominoDocument datasource on the XPage. Today I was battling with a problem when editing a document that had been created in Notes. I was getting the very helpful message “Validation Error: Value is not valid”, with no help on which field it was referring to.
I eventually tracked it down to a Combo Box. On the underlying document, the field was Text with a blank value. But the code that was writing the field value to the underlying Map was using wrappedDoc.getValue(), which was returning an empty Vector. If it had a value, wrappedDoc.getValue() was returning a String with the value. That was not unexpected. However, when the comboBox was bound to that, it was throwing the error. My suspicion is that, because the combo box only accepts a single value, it was trying to use “[]” as the value, rather than identifying it as a Vector and assigning the first value.
So I modified the code so that, if wrappedDoc.getValue() returned a Vector whose toString() value was “[]”, it valled setValue(new String(“”));. Once I did that, all was fine.
At the moment I’ve made a number of changes to Tim’s classes. So once this project is finished I plan on reviewing the final classes against Jesse Gallagher’s controller classes and feeding anything useful into that project. (I know his project also deals with Rich Text fields with attachments, which I haven’t.)
Document Wrappers are really interesting getting a layer between the actuall backend data and the frontend xpage can really extend what you can do.
* a field modification tracker for auidts
* Extended validation of data
* Debugging
* Redirect some data to an external data source or all data
the possibilities are endless.
@Fredrik: can you provide more examples for that?
The DocumentWrapper basically allows you to set a whole host of additional properties that you’re likely to want if you access that object. They can also be properties from e.g. a parent document. From that one class you can create a single method to dump out all those properties into a String or ArrayList or whatever. I’ve used it to dump data to a dialog or to OpenLog for debugging purposes.
Based on Tim’s project, the SmartDocumentModel also has querysave and postsave methods, so validation can be done there as well as updates of related documents, if needed. And it also means those updates are done for every XPages-triggered save, not just on a specific instance of the datasource.
I haven’t done it for field modification tracking, but because the document wrapper calls database.createDocument() and then creates items in the *back-end*, I have extended it to do some “field modification”. In my wrapper I added a Map of Readers, Authors and Names fields, and checked the Map during the save() method to set those properties accordingly.
For field modification tracking, I tend to use a ValueChangeListener bound to a specific component. But again that only captures changes made via that specific component. You could create in your wrapper a Map of fields to track, then in the save() method, check the Map as you’re updating each field and, if the valule in the Item is different to the value in the wrapper, add an audit trail. That would capture the audit regardless of where it’s done.
Similarly the wrapper could hold a Map of fields as well as config of where to store the alternate data. The save() method could pick that up and move the data accordingly.