Unexpected SelectItem behavior at DataSource errors

[ilab]

When a SelectItem is configured to use a DataSource, it loads the data to display from the DataSource.

However, there are be cases when this data load is unsuccessful for the first time, but would succeed for a second time if it happened.

One of these cases is when the user fills in a form, which takes too long (coffee break) and its session timeouts, so when she clicks the SelectItem, the DataSource will receive a timeout-occured-error.
The user is kindly requested to log in again, and then being user friendly, she can continue her work from the very place, so she clicks the SelectItem again, which will show "No items to show" without retrying to load the data.

In my understanding, SelectItem is expected to retry to load the data on dropdown event until it succeeds (the same is true for latter on-demand data fetches if there are any).

SmartClient Version: v11.1p_2017-09-27/LGPL Development Only (built 2017-09-27)

Please see a code sample below.

    public void onModuleLoad() {

        Canvas canvas = new Canvas();

        RestDataSource selectDS = new RestDataSource();
        selectDS.setDataURL("http://127.0.0.1:8888/dummyLookupData.jsp");

        DynamicForm form = new DynamicForm();
        SelectItem item = new SelectItem();
        item.setOptionDataSource(selectDS);
        item.setDisplayField("display");
        item.setValueField("value");
        form.setItems(item);
        item.setAutoFetchData(false);
        canvas.addChild(form);

        canvas.draw();  
    }

Note: the DataSource JSP below returns an error for the first and then every second time.

<%
    String requestedValue = request.getParameter("value");

    if (requestedValue != null || "false".equals(session.getAttribute("last_succeed"))) {
        if (requestedValue == null)
            session.setAttribute("last_succeed", "true");
%>
<response>
    <status>0</status>
    <startRow>0</startRow>
    <endRow>2</endRow>
    <totalRows>3</totalRows>
    <data>
<% 
    if (requestedValue == null || requestedValue.equals("1000") ) { %>
        <record><value>1000</value><display>1 thousand</display></record>
<%}
    if (requestedValue == null || requestedValue.equals("2000") ) { %>
        <record><value>2000</value><display>2 thousand</display></record>
<%}
    if (requestedValue == null || requestedValue.equals("3000") ) { %>
        <record><value>3000</value><display>3 thousand</display></record>
<%
        }
%>
    </data>
</response>
<%
    }
    else {
            session.setAttribute("last_succeed", "false");
%>
<response>
    <status>-1</status>
    <data>Some error, which won't happen on next refresh.</data>
</response>
<%
    }
%>

[Isomorphic]

See Relogin in the QuickStart Guide for how to properly handle session timeout errors. There is no reason you should be allowing session timeout errors to bubble to GUI components, and avoiding this will fix this problem and dozens of others within your application.

[ilab]

Dear Isomorphic,

Thank you for the suggestion, I actually did read the Relogin docs and our session timeout handling is designed (almost) according to that, just the suspending/resuming is missing because in my oppinion things should work without that although I admit suspending/resuming is more elegant. Anyway, I will definitely fix that.

However, please note that I wrote session timeout just as an example.
There are other situations where a data request can temporarily get an error (for example temporary netwok error, but virtually anything), and in these cases it is also not desirable to expect the user to reload the whole page so that she can have a next try to load the data.

Based on the above, I still claim that it is not correct that SelectItem behaves as it loaded successfully zero rows when it actually got an error from the datasource.

Thank you!

[ilab]

Dear Isomorphic,

Any comments?
Is the case I made out in the last message correct?