SelectItem on select shows briefly value instead of display

[martintaal]

Hi,
I have a selectitem with a suggestion box like behavior (so with a datasource), when the user types a text and then selects a value a very brief moment the value (a database id) is visible before it is replaced by the display value in the field.

Is this known behavior or something which you have seen before, maybe something I can prevent somehow?

gr. Martin

[Isomorphic]

This is because the fetchMissingValues behavior is fetching the display value in the background. The only way to avoid it is to provide a valueMap that has the display value for the initial value for the field.

[yavery]

Sorry to re-activate this old thread ...

Would it be possible to display something else, like a blank value or "Loading ..." instead ? It does
look weird to see KEY values being displayed while the actual legitimate display value is being loaded.

Thanks,

[yavery]

Anyone from Isomorphic can tell me if there's something I can do about this ?

Also, I'd like to know if it's possible to have the data cached by the data source so that
subsequent usages of the same lookup datasource don't return to the server every
time to load the same lookup data, over and over, again.

Thanks,

[Isomorphic]

On a "Loading.." message - this would be a good one to sponsor, otherwise, you could add a formatter that checked if value == getDisplayValue() and returned the "Loading.." message if so.

On caching, have you seen DataSource.cacheAllData?

[yavery]

I'll look at the suggested "Loading..." strategy. Thanks for that ...

As for the cacheAllData property, I tried that but it seems to be conflicting with all of my fields of
type SelectItem or ComboBoxItem on which I've attached a custom getPickListFilterCriteria()
handler.

I do call Super() in my implementation of getPickListFilterCriteria().

For any of those SelectItem or ComboBoxItem where I have defined such custom handlers, I get
an empty options list ...

Do you know why this could be ?

Thanks,

[Isomorphic]

cacheAllData necessarily causes client-side filtering to be used. If your criteria are set up so that your server understands them but the client can't perform equivalent filtering (perhaps the data values for one of the criteria are never delivered to the client) it could cause this effect.

[yavery]

Thanks. I'll further investigate in that direction.

Kind regards,

[yavery]

Indeed.

When my DataSource first gets loaded, no criteria is supplied, so the backend returns the entire data set.

Then later, in one of my ComboBoxItem components, I provide a getPickListFilterCriteria() that
adds an additional/simple criteria value.

Is there any way I can make this work so that it doesn't go back to the server, yet return only those
rows that match that additional/simple criteria ?

Right now, when I've set things up with cacheAllData = true, my combo box shows up without any
options at all and without cacheAllData = true, it works A1 (but goes to the server every single time).

Thanks for your help,

[Isomorphic]

What you're asking for is exactly how it works. The question is, I'd you look at the criteria supplied and the dataset you're returning, is client-side filtering just going to eliminate all records, because the criteria are on a field that has no value in the dataset you're returning to the client?

[yavery]

Hi guys,

I just wanted to let you know that I did manage to have this work, but the way the optionDataSource dependant
strategies were implemented in the ISC framework had limitative shortcomings that were not acceptable for us
so I decided to revert to not using optionDataSource strategies, but instead have pre-resolved lookups, fed
by server-side joins that return the actual lookup values as part of the payload itself (as well as the keys of course).

For example our returned payload is the following :

{
   ...
   'account' : 1234,
   'account.display' : 'the account name displayed'
}

So I bind my U/I component to 'account.display' instead or 'account' and avoid lookups altogether.

The shortcomings that I found were the following :

1) while keys get resolved to actual lookup values, the key value gets displayed to the user instead
of a "loading" spinner (or some other more appropriate visual feedback) ...

2) when embedded within listGrids and such listGrid component uses column sizing based on its content,
it doesn't work because the column width gets sized before the actual lookups get resolved, therefore
the width of the column is based on the key value and not the looked up value.

3) when embedded within listGrids and with large lookup data sets, the lookup strategy doesn't scale
very well as it seems to be loading the whole lookup data set, once for each column for which there's
an optionDataSource.

If you ever improve in any of those areas, please let me know as I might revisit my decision.

PS: We still use optionDataSource driven components for editing data. Data scrolling works in those
cases and scales well even with large lookup data sets.

[Isomorphic]

See docs on listGridField.optionDataSource - your 2 and 3 strategy is what we document and recommend except you've got it slightly wrong, you should be using listGridField displayField and binding to the actual data value.

On 1), we gave a strategy for showing a placeholder, did this not work out?

[yavery]

Great! Thanks for that clarification ...

I didn't see that it was documented as such, and therefore, I was trying to have this work
with large data volumes ... I'm glad to see that what I implemented is what you documented
and recommend ;-)

As for the "loading..." strategy, it did work but I didn't require implementing it in the end,
since I moved away from lookups altogether.

Thanks - Talk to you later,

[martintaal]

Hi,
I am interested in showing the placeholder, so the solution for 1), is this documented/available somewhere?

Thanks!

gr. Martin

[yavery]

Read the earlier posts from this thread. A workaround was provided by Isomorphic.