How to display "loading..." instead of valueField data in a cell?

[vold_by]

SmartGWT 3.1p 30.11.2012

In grids that have a lot of data and several fields with optionDataSource we see valueField data first and then it changes to displayField data after appropriate option DS fetch process finished.

Is any way not to show value data and show something like "loading..." instead in that cells until dislpay values are loaded?

[amcculley]

We have just gone through our entire app and removed all uses of optionDataSource which refer to static data (status, enums, etc).

We just found the performance to be lacking. We use "enum" types in the ds.xml along with valueMaps and find that it works much better. Of course, you don't get the reusability across the entire app that way (if multiple ds files refer to the same enum), but we control this process manually now and it is worth the tradeoff in performance.

Now if the optionDataSources point to dynamic data in some table, you don't have many options except to do proper joins instead of optionDatasource.

The reason you see this (from my experience) is because the dataset is large. On smaller datasets, you don't tend to see that lag and switch of values.

If you read the API, it specifically warns of using optionDatasource on large datasets. It really isn't meant for that. Use proper joins instead.

[Isomorphic]

Just to make sure nobody misinterprets this - amcculley is talking about listGridField.optionDataSource. If you read the docs for that API, it indeed is recommended for small datasets only, and alternative approaches are explained.

Other uses of optionDataSource, like SelectItem.optionDataSource, ComboBoxItem.optionDataSource *are* intended for very large datasets, and work very well in that case.

[vold_by]

Just to make sure nobody misinterprets this - amcculley is talking about listGridField.optionDataSource. If you read the docs for that API, it indeed is recommended for small datasets only, and alternative approaches are explained.

Ok, I understood that better to use preloading of optionDataSource data for listGrigField in my case.

Other uses of optionDataSource, like SelectItem.optionDataSource, ComboBoxItem.optionDataSource *are* intended for very large datasets, and work very well in that case.

I'm not sure that they "work very well in that case". I have a form to edit data from the table. I show the form and call editRecord(record). The form contains some items like ComboBoxItem with optionDataSource with large amount of data and I see value data first and than display data after 3-5 sec.

But anyway, thanks for reply.

[Isomorphic]

That simply indicates that your server is responding very slowly. optionDataSource only requests the first batch of records from the server - either you are returning all data unnecessarily, or your server code is just slow. Either way, the optionDataSource system is not at fault and is performing well.

[vold_by]

That simply indicates that your server is responding very slowly. optionDataSource only requests the first batch of records from the server - either you are returning all data unnecessarily, or your server code is just slow. Either way, the optionDataSource system is not at fault and is performing well.

I don't want to blame the optionDataSource system for slow responding. In fact I have some sort of JPA layer on the server and maybe it has some delays, but I can't do something better with that right now so I asked in the topic if I can show some loading message in this case or not.
It would be enough to show something like "loading..." instead of value data.

[Isomorphic]

It's possible via implementing a ValueFormatter that checks whether getDisplayValue() is the same as getValue(), but we'd recommend figuring out why your JPA layer is so slow instead. Only one value is being fetched in this scenario (see formItem.fetchMissingValues). With a server with normal performance the delay is usually small enough that end users don't even notice the internal ID is being briefly displayed.

[stonebranch1]

I am experiencing a similar problem with the initial display of a form where the select item briefly shows the value and then shows the display name for that field after the subsequent fetch has been made on that option datasource to get the display field for that value.

It is very brief but causes any of those fields to "flash" which people have been complaining about. I have been looking for some way to resolve this but have not found any way of doing it.

I tried even to refetch the record from the server before calling editRecord and including as related updates in the response the record for the field that will be populated in that select item hoping this would then be used and prevent any subsequent fetch or "flashing".

Is there anyway I can return the option datasource data with the record so that all the data is available on the client at the same time and prevent the fetch to lookup the display name for the specific value that is in that field?

[stonebranch1]

Isomorphic, I was trying to use your suggestion of setting a value formatter to compare the value to the display value in order to prevent the flashing. Problem is, the call within the formatValue method I was trying to use: item.getDisplayValue() to get the display value to compare against the passed in value and that call causing an infinite recursion since calling getDisplayValue() call the FormItemValueFormatter to get the display value.

Any suggestions?

[wolf]

I just want to add that I see the same occurrence in my app when editing a record in a form. When I call DynamicForm.editRecord(record), ComboBoxItems etc will first show the key value very briefly before showing the display value. I am using SmartGWT Pro and using all the builtin server side data handling.