http://qs321.pair.com?node_id=1232353


in reply to Mojolicious::Lite and Webperl

As discussed in Corion's reply and my follow-up, getting modules into WebPerl takes a bit of work, especially modules with XS/C code, and sockets are a much more complex topic. The typical way to approach this kind of thing is to have a server (in this case probably the Mojolicious::Lite app) communicate with the browser with e.g. HTTP+JSON. The repository contains an example of using jQuery's ajax method here and a native XMLHttpRequest here - the latter example is a synchronous request, which is not typical, but since translating JavaScript to Perl is fairly straightforward, many of the examples of using XMLHttpRequest can be easily translated.

In your reply here you said:

Even php is banned for the end user.

I'm not sure what you mean here - do you mean you can't even use PHP on the server side? That'd be a pretty strange restriction, given that based on your question, apparently your database server would be reachable from the clients?

I think if you re-think the architecture a little bit, the whole thing is doable with WebPerl: Instead of trying to put everything in the browser, you can split it up: One Perl script, running locally, acts as the webserver (Mojolicious::Lite), and it can also launch the browser, which accesses that local webserver, and the webserver serves up a HTML page with an embedded WebPerl script, acting as the GUI, which can then communicate with the local webserver as mentioned above. While the WebPerl script is pretty much sandboxed in the browser, the local webserver can do anything that a normal Perl script on the machine can, i.e. access local files, open network connections, etc.

Replies are listed 'Best First'.
Re^2: Mojolicious::Lite and Webperl
by frazap (Monk) on Apr 09, 2019 at 13:45 UTC
    I'm not sure what you mean here - do you mean you can't even use PHP on the server side?

    Web pages have to be edited with ModX revolution, and php code can't be added using this tool (as it is configured). Running the mojolicious lite script from a pc, with starting the script at pc launch, would be a poor man's server, better this is better then nothing. I can link to this Mojolicious::Lite page using the pc IP address.

    you can split it up: One Perl script, running locally, acts as the webserver (Mojolicious::Lite), and it can also launch the browser, which accesses that local webserver, and the webserver serves up a HTML page with an embedded WebPerl script, acting as the GUI, which can then communicate with the local webserver as mentioned above.

    do you mean: anyone interested would have to download the packed script ? That would not work for Mac or *nix users.

    Why using WebPerl to build the GUI ?

    Or do I misunderstand ?

[reply]
      do you mean: anyone interested would have to download the packed script ?

      Everything could still be packed into one distribution: the local webserver script plus the files it serves to the local browser, which would include the WebPerl code.

      Why using WebPerl to build the GUI ?

      You don't say if you've already built a GUI, and if you have, what toolkit you used? WebPerl allows one to basically replace JavaScript, so it's possible to write a fully interactive GUI in the browser, using Perl instead of JS. If you've already got a GUI written with a different toolkit, then it's currently not possible to just put that into WebPerl and have it work.

      It's unfortunately also currently not possible to just stick any interactive command-line script into WebPerl, because reading from STDIN is blocking, and doing blocking I/O, while not impossible, requires some pretty complex workarounds. (I've got this in the back of my head, and if I see some possible workarounds showing up, I'd see if I could implement those.) So while some Perl code can be copied directly into WebPerl, other Perl code requires one to think about the limitations inherent in the browser environment.

[reply]
[d/l]

      There are now two examples available:

      • WebPerl Basic GUI Example - the local web server is Plack, and it shows how to access a DBD::SQLite database on the local machine; the frontend (in the browser) is written in Perl without the help of any JavaScript libraries.
      • WebPerl Advanced GUI Example - the local web server is a Mojolicious::Lite app, and the frontend is of course also written in Perl, but this time including Bootstrap and jQuery. (This example doesn't implement anything fancy on the server side, it just shows how to communicate with the server via JSON.)

      I've implemented both so they can be packed by PAR-Packer (tested on Linux).

[reply]

In Section Seekers of Perl Wisdom