LanX has asked for the wisdom of the Perl Monks concerning the following question:

Hi

I'm having an issue with fetching web-content via webperl which is probably related to asynchronism. (final goal: to dynamically load and install non-bundled Perl modules)

This code works when included into the democode page

    
use warnings;
use strict;
use Data::Dumper;
use WebPerl qw/js/;
my $fetch =<<'__JS__';
var req = new XMLHttpRequest();
req.open('GET', 'https://webperl.zero-g.net/', false);
req.send(null);
if(req.status == 200)
   (req.responseText);
__JS__
print Dumper js($fetch);

[download]

please note that because of the same origin policy I can only access data from the same server.

After installing webperl and plack locally I can run it under localhost:5000

Now I copied webperl_demo.html to a new page and included the follwing JS-code 

<script>
var req = new XMLHttpRequest();
req.open('GET', 'http://localhost:5000/emperl.js', false);
req.send(null);
if(req.status == 200)
   alert(req.responseText);

</script>

[download]
which is able to fetch (for demonstration) the included emperl.js

BUT running the following webperl code not only fails, but blocks the page

<script type="text/perl">
use warnings;
use strict;
use Data::Dumper;
use WebPerl qw/js/;

my $fetch = << '__JS__' ;
var req = new XMLHttpRequest();
req.open('GET', 'http://localhost:5000/emperl.js', false);
req.send(null);
if(req.status == 200)
   (req.responseText);
__JS__
               
print Dumper js($fetch);
</script>

[download]

What am I missing?

Cheers Rolf
(addicted to the Perl Programming Language :)
Wikisyntax for the Monastery FootballPerl is like chess, only without the dice

Replies are listed 'Best First'.
Re: webperl: fetching data over the web
by haukex (Archbishop) on Nov 08, 2018 at 15:15 UTC

    You're right that it has to do with async execution - the fetch happens in the background, and you can't just check req.status right away - you need to register an event listener (I think you were probably just lucky in your tests that the requests returned very quickly :-) ). (Update: Oops, see replies!) See e.g. Using XMLHttpRequest.

    The secondAnother issue to be aware of is that scripts in the "democode" page are run in a perl that gets ended when the main script is done; no async stuff is possible. For that, you need to either embed <script> tags in an HTML file, or use the "Run & Persist" mode of the "mini IDE". In the latter, the following works for me. (Note there are also other events on XMLHttpRequest, such as error and abort.

    use warnings;
use 5.028;
use WebPerl qw/js js_new/;

my $xhr = js_new('XMLHttpRequest');
$xhr->addEventListener("load", sub {
    say "Loaded! <<<<<",$xhr->{responseText},">>>>>\n";
});
$xhr->open("GET", "http://localhost:5000/");
say "Sending...\n";
$xhr->send();

    [download]

    Actually, I am currently working on a subclass of Future::HTTP that I'd like to include by default in WebPerl to make HTTP requests easier out of the box, hopefully I can release it soon.

[reply]
[d/l]
[select]
      From what I understood is my demonstrated js code synchronous and blocking. Running it directly works, also from the Dev console in FFM

      I'm not sure Perl should return earlier than alert does.

      Cheers Rolf
      (addicted to the Perl Programming Language :)
      Wikisyntax for the Monastery FootballPerl is like chess, only without the dice

[reply]
        From what I understood is my demonstrated js code synchronous and blocking.

        Sorry, I missed the third argument to your req.open() call that makes the request synchronous. But I did copy your third piece of example code exactly, and on my end it works, and only blocks the page while the fetch is running - which is to be expected, since it's a synchronous request. Not sure why it's failing for you, but like I said, check the browser's debugging tools (e.g. in Firefox, hit Ctrl+Shift+e).

        Note that synchronous XHR's aren't recommended, see e.g. here:

        Note: Starting with Gecko 30.0 (Firefox 30.0 / Thunderbird 30.0 / SeaMonkey 2.27), Blink 39.0, and Edge 13, synchronous requests on the main thread have been deprecated due to the negative effects to the user experience.

        Synchronous XHR often causes hangs on the web. But developers typically don't notice the problem because the hang only manifests during poor network conditions or slow server response. Synchronous XHR is now in deprecation state. Developers are recommended to move away from the API.

[reply]
[d/l]
Re: webperl: fetching data over the web
by LanX (Saint) on Nov 08, 2018 at 15:21 UTC
    Just a guess because I can't test at the moment:

    The first demo page is redirecting STDERR to a text area, the second isn't.

    Probably a warning by JS is blocking then.

    Cheers Rolf
    (addicted to the Perl Programming Language :)
    Wikisyntax for the Monastery FootballPerl is like chess, only without the dice

[reply]

      The "democode" pages always display STDERR if there is any output there. It also helps to watch the JavaScript console in your browser. I'm not sure what's blocking the page - I unfortunately can't reproduce that on my end with the third example code you showed in the root node.

[reply]
[d/l]
        The zip file from your webpage didn't include a democode directory.

        That's why I copied and hacked webperl_demo.html.

        (edit: cloning the frame structure of the former didn't work instantly)

        Cheers Rolf
        (addicted to the Perl Programming Language :)
        Wikisyntax for the Monastery FootballPerl is like chess, only without the dice

[reply]
Re: webperl: fetching data over the web
by LanX (Saint) on Nov 09, 2018 at 15:11 UTC
[reply]

Back to Seekers of Perl Wisdom