jsdo synchronous xmlhttprequest

Merci Wayne,

I'll upgrade.

Regards, Stefan.

Just downloaded 4.0 but the warning still comes up (I checked the cache refresh). It comes from progress.jsdo.js:  xhr.open(verb, uri, async);

Regards, Stefan.

Hello Stefan,

As Wayne mentioned, you would need to use the asynchronous version of login(), addCatalog() and logout().

Here is a link to an example using the new progress.data.JSDOSession object with promises:

oemobiledemo.progress.com/.../example001p.html

You can download this and other examples from the following link:

community.progress.com/.../2020.aspx

Best regards.

Thanks Edsel,

I did not find the progress.data.JSDOSession object, should that replace progress.jsdo.js version 4.0? Where can I download it? I did not see it on github.com/.../JSDO.

Regards, Stefan.

Hello Stefan,

What file are you using?

I just took a look and confirmed that the progress.data.JSDOSession object is present in the progress.jsdo.js from github.com/.../lib.

Please check.

Thanks,

Edsel

Edsel,

I was looking for an object with the exact name you provided,  progress.data.JSDOSession. You must mean progress.jsdo.js, that file I can see on the link you give,

I downloaded the zip from github.

Regards, Stefan.

Yes, progress.jsdo.js is the file that contains the progress.data.JSDOSession object.

(progress.all.js is progress.jsdo.js + progress.data.kendo.js which is the file containing the support for the Kendo UI DataSource.)

Please let me know if you need additional information.

Regards.

Hi Edsel,

I do not need info, only wanted to point out that I still see the warning in firefox devtools (see somewhere above) about the synchronous xmlhttprequest. It shows up on a custom read operation.

Regards, Stefan.

Hello Stefan,

Thank you for the feedback.

I would like some additional information on what you are seeing.

Your reference to "custom read operation" make it sounds like you are seeing the issue with an invoke operation.

Invoke operations are asynchronous by default (there is a parameter that you could use if you really wanted to call them synchronously).

BTW, I tested with program example004.html using Firefox devtools:

   oemobiledemo.progress.com/.../example004.html

This program shows the warning and points to line number 8954.

This line corresponds to function setXHRCredentials() which is called from login().

Once I changed the code to use the new progress.data.JSDOSession object which uses Promises, the warning is no longer shown. See the execution with the updated version example004p.html:

   oemobiledemo.progress.com/.../example004p.html

Are you using the new JSDOSession object?

Could you check the line number of code that causes the message?

Thanks,

Edsel

I'll let you know after the weekend. I'll add a debug message also to the jsdo.

Ah, now I understand Wayne's message. Reading documentation.progress.com/.../oemobile1151

I'm changing my code according to this.

Thanks, Stefan.

After close reading the code (see below for a copy) in the mentioned documentation link I do not understand which problem it solves compared to the code in the old progress.data.session. In fact the execution of the calls is still synchronous. At first after the catalog json has been loaded from the webserver you can start loading a first page of data. I don't know what happens with the GET of home.html, in the old progress.data.session it was fetched even three times synchronously from the webserver after navigating to the URL. I'm trying to solve the same problem for the extra data I need when fetching a first page of data (I need to fetch a dataset with - for now, more to follow -  validations). See community.progress.com/.../16826.aspx last message.

Ideal for UX would be *only one* roundtrip after navigating to a URL. And why shouldn't this be doable.

rauchg.com/.../7-principles-of-rich-web-applications

https://developers.google.com/speed/docs/insights/mobile?hl=en

https://community.dynatrace.com/community/display/PUB/Best+Practices+on+Network+Requests+and+Roundtrips

https://www.iispeed.com/pagespeed/recommendations

korynunn.wordpress.com/.../deploying-a-web-app-in-14-days-no-html

Again something for the DRS (dark room sessions) aka the CCS?

Regards, Stefan.

var session;

/* create jsdoSession   */

session = new progress.data.JSDOSession(

       { serviceURI: "http://localhost/CustService",

         authenticationModel: progress.data.Session.AUTH_TYPE_FORM

       };

/* create login screen (using UI defined in HTML file) */

window.loginView = kendo.observable( {

   submit: function() {

       var loginParams = {

                username: this.username,

                password: this.password) };

       /* log in (also loads CustService.json if it succeeds) */

       session.login(loginParams

           ).done( // Logged in

           function(session, result, info) {

               session.addCatalog("http://localhost/.../CustService.json"

                   ).done( // JSDO catalog loaded

                   function(session, result, details){

                       /* success function – create grid and datasource */

                       $("#grid").kendoGrid( {

                           dataSource: {

                               type: "jsdo",

                               transport: {

                                   jsdo: { resourceName: "Customer" }

                               },

                               error: function(e) {

                                   console.log("Error: ", e);

                               }

                           },

                           /* etc., other kendoGrid properties */

                       };

                       /* switch UI to show grid */

                       window.location.href = "#grid";

                   }).fail( // JSDO catalog not loaded

                   function(session, result, details){

                       alert("JSDO catalog failed to load");

               }); //JSDOSession addCatalog()

           }).fail( // Not logged in

           function(session, result, info) {

               /* display error message, stay on login screen */

               alert("Login failed");

       }); // JSDOSession login()

   } // observable submit method

} ); // kendo.observable

You're correct that, from the standpoint of the app developer, async login() and addCatalog() calls need to be done sequentially anyway, since you usually don't want to try to access the catalog until you have successfully logged in, and you definitely don't want to try to create a JSDO until you have retrieved the appropriate catalog. (In fact, that is why the initial implementations of login() and addCatalog() were synchronous.) However, synchronous HTTP requests are, in general, deprecated, and in fact we had a bug where the synchronous login() method did not work in Firefox in certain situations because of Firefox's restrictions on synchronous requests. Other user agents are more lenient, but will still give you warnings about making synchronous requests.

The async login and addCatalog also give the app the opportunity to do something else while waiting for the reply (although I'll admit that there usually won't be a long wait anyway).

Thanks for the explanation. I hope though something will be done to reduce the number of roundtrips (that is my standpoint as appdeveloper, I want to offer an optimal ux).

Regards, Stefan.

Not synchronous, not asynchronous, but simultaneous. :-)

Regarding the multiple round trips, what are the requests that you see being made? You referred to fetching home.html 3 times -- do you see three GET requests for home.html?

That's right Wayne.

Hi Stefan,

Hmm. We don't deliberately do three GETs of home.html for a login, so I am very interested in the case where you see it, in case there is something we need to do about it. If you can send me a code sample that shows your login sequence, as well as a screen capture or dump of the network traffic (from a browser debugger Network tab, or Fiddler, or something similar), I'll take a look.

I will say that if you are using Form-based authentication and CORS, there is always more traffic than might be expected. In that case, you'd see both an OPTIONS request and a GET request of home.html, and then an OPTIONS request and a POST for j_spring_security_check, all as part of the login. And there would be an OPTIONS and a GET for a ping that we do after login. But these would not show up as three GETs of home.html.

Regards,

Wayne

I'll try to make time tomorrow. Nothing special in any case.

Regards, Stefan.

Hi Wayne,

Here is the code:

 dataModel.configDatasource = function(config) {
        var session = new progress.data.Session(),
            loginResult = session.login(config.crudServiceBaseUrl + "/" + config.service, "", "");
        session.addCatalog(config.crudServiceBaseUrl + "/" + config.service + "/static/mobile/" + config.service + ".json");
        dataModel.jsdo = new progress.data.JSDO({ name: config.datasource });
    };

And here is the network tab:

The three gets for home.html are not expensive, the three (related?) _oeping gets are more expensive (when the test is repeated this looks true on avarage). Besides it is interesting for me to see how expensive the gets for pictures are. I replaced most of them with fontello fonts, the ones you see will be soon. The two customreads are a get for a first page of data + a get for info I need for the screen (only needed to initialize the screen). I will try to merge these (see https://community.progress.com/community_groups/mobile/f/17/t/16826.aspx last message).

  Chrome btw is faster, in the networktab I can see fontello (not so in firefox). In the meantime I replaced one of the images with fontello.

Regards, Stefan.

Thanks, Stefan. I'll take a look.

Hi Stefan

Is there any possibility that dataModel.configDatasource() is being called three times?  What stands out about the Network traffic is that there is a GET of the catalog (CustomerService.json) right after the first request for home.html. Given the code in configDatasource (which looks fine), we would only see the request for the catalog after the login call is completely done executing and returns. That suggests that login was called, successfully got home.html (only requesting it once, at that point), returned, and then addCatalog was called. The two additional requests for home.html may mean that there actually were calls to login() (via 2 calls to configDatasource() ) two more times. (Even though that implies that addCatalog() would also be called twice more, you wouldn't see any repetition of the request for CustomerService.json because the Session code would detect that it had already fetched it and so doesn't send the request.)

I did run your code against my own service (a Customer service using Anonymous authentication) and saw the same pattern of network traffic that you did, but only if I called configDatasource() three times.

Regards,

Wayne

Hi Wayne,

You're right, I'm sorry I did not think of this myself before. I call it for the initial page of data, the validations and a foreign key. I can solve this by calling the foreign key service as soon as it is needed (select a fk the first time when doing mainentenance) and getting the validations with the initial page of data together (community.progress.com/.../16826.aspx last message as mailed a couple of messages ago).

Regards, Stefan.