Update 2: Code for Custom Converter that helps work around the problem
I reported this to IBM today (my first Service Request). I thought I should share the bugs, so others are aware of it.
Bug with multi-value fields and converters in XPages
By multi-value field, I mean a field that have the multi-value
separator set.
When saving a multi-value field of type String, the value alternates
between being split into multi-value, and being a flat string.
First save -> multi-value
Second save -> flat string
Third save -> multi-value
When saving a multi-value field of type date or number, the field only saves
the first value.
I also tried using a custom converter to modify the field
(getAsObject -> split, getAsString -> join). This doesn't work at all.
It seems custom converters only can be result in string values.Example:
How hard can it be to implement multi-value. It seems like someone slapped together a couple of lines of code, and forgot to test it. I'm surprised that there isn't any other bloggers haven't written about this. Maybe multi-value fields aren't that popular?
9 comments:
Wow - haven't run into this yet, but probably will soon. Please keep us updated on the progress.
You should also consider posting in the 8.5 forum with the full source of your page. There are some IBMers that frequent there that jump on xPage stuff really quickly.
I use lists and multi-value fields everywhere. They are one of the most powerful parts of Notes/Domino. I haven't started using xPages yet. The learning curve is too steep and I've got to get results fast. Eventually I'm sure I'll start using xPages ... just not yet ... so keep finding those bugs so I don't have to.
@Karen: Posted the bug in the forums today, along with a link to a demoapp of the bug.
@Rob: I agree that it's a steep learning curve, but when you start to get your head around the monster, it is really powerful.. :)
I got an RSS feed for your post to the forum, and had to work on the same thing today. It's definitely a bug. But see my blog for a workaround.
http://hermes.intec.co.uk/Intec/Blog.nsf/dx/10122009181407HERPDV.htm
@Paul: Our workaround is adding input translation @Explode( @ThisValue ; separator ) (separator -> @NewLine, ",", etc.), to the fields in the Notes form, and enable compute with form on the data source in the XPage.
There are probably several ways to work around this, but the best would be if IBM fixed this (and started spending more money on testing and documentation).
I ran into this issue a couple of weeks ago. At the time I just put it down to me not knowing what I was doing with XPages yet.... I ended up storing binding my values to a sessionScope variable and then saved it to the document manually during the save. Thx for making it clear every mistake I make is not the result of my own stupidity.. (Just 99%)
@.Domino: You can't blame yourself, when you look at how little the XPages framework is documented.
If IBM spent more time and money on testing and documentation, I bet tens or hundreds of million dollars (total) would be saved every year for their customers.
aaaaaaaaaaaaaaaah, facing myself with this problem now. STupid IBM, why can't you provide us a multi value core control? Asses!
Tommy, you came with a simple solution based on good Lotus Notes form and formula coding. I find that coders forget simplicity, and instead recommend hugely complex solutions with tons of Javascript code. Thanks a lot! By the way, I could not figure how to make it work with NewLine, but it works certainly very well with comas.
Post a Comment