Web App Development Overview

[Phil]

A few notes on one approach to developing Web apps with Lazarus and Pascal:

https://dl.dropboxusercontent.com/u/28343282/MacXPlatform/WebAppOverview.html

[howardpc]

Thanks Phil for sharing your code and expertise.

[Phil]

Thanks, Howard. It's actually quite a bit of fun to develop these Web apps.

I'm using qooxdoo's mobile-optimized controls, which make the app look a bit like an iOS app (eg, the master-detail look), but they also work pretty good in desktop browsers too. Try the Fish Facts app on a phone or tablet to see how it adapts.

-Phil

[ArtLogi]

Ohh. Will be reading this when I have some free time to spend again for programming with free pascal & Lazarus. Thx, for the write up (I only skimmed it through really fast, so at the moment I only say write up.  )

[Leledumbo]

Don't you have any interest in making qooxdoo wrapper, Phil? Something like ExtPascal approach, with Lazarus integrated form designer.

[Phil]

Don't you have any interest in making qooxdoo wrapper, Phil? Something like ExtPascal approach, with Lazarus integrated form designer.

It's tempting, isn't it? However, when I survey the wreckage of past attempts, I'm not sure that's something I would want to attempt.

For those who don't know the now-abandoned ExtPascal, it generated ExtJS-based JavaScript dynamically in response to user events, sending this JS to the browser in order to update the UI. ExtPascal also included an optional package for Lazarus that provided "design" controls for the corresponding ExtPascal classes (which in turn corresponded to the underlying ExtJS classes). This allowed the Web app UI to be visually designed to some extent in Lazarus.

The final version of ExtPascal is here:

https://github.com/farshadmohajeri/extpascal

The natural successor to ExtPascal is probably something like Farshad's UniGui, which also uses "design" controls when laying out the page to set properties, etc. of the actual server-side controls. UniGui is Delphi and Windows only, but the on-line demos and list of controls and features are interesting:

http://www.unigui.com/

There was much to like about ExtPascal, but I think it suffered from several design problems that manifested themselves once you got apps beyond the trivial stage:

(1) You ended up still writing some JS and "emitting" it from the server-side Pascal app, meaning you still have to know JS and the JS controls, and when and where the dynamically generated JS is being sent.

I did a Fish Facts demo for ExtPascal too. Most of the code is in its mainform.pas file. Take a look at it here to see where JS is being embedded - look for JSFunction calls. (You can also see in this code how it toggles between the ExtPascal runtime units and the design controls - Laz only sees the design controls, but when you compile FPC only sees the runtime units.)

https://github.com/farshadmohajeri/extpascal/blob/master/ExtP_Toolkit/fishfacts_example/mainform.pas

(2) Server and client side logic gets combined, like in the worst kind of VCL/LCL app where all the UI and program logic is tangled up together in the form classes.

(3) Because a pixel-oriented UI designer is used, apps didn't have the modern Web (and mobile) feel, where the UI elements just flow and fill in "naturally" the available space, meaning the app looks good in mobile and desktop browsers both.

I'm not sure what a designer would even look like for qooxdoo controls.

-Phil

[Leledumbo]

(1) You ended up still writing some JS and "emitting" it from the server-side Pascal app, meaning you still have to know JS and the JS controls, and when and where the dynamically generated JS is being sent.

Yup, this is the ugly part. Looks like unfinished wrapper so you have to code in a stringly typed language. Should be avoidable if the wrapper is complete so we really really only deal with Pascal code.

(2) Server and client side logic gets combined, like in the worst kind of VCL/LCL app where all the UI and program logic is tangled up together in the form classes.

This is a bit hard, since the JS itself is generated from server side. Carefully designed, however, the client and server can be totally separated. Let the form designer generated app deals with client side, then the server is another app and surely can be written in anything else (handwritten, fpweb, brook, whatever). Then we raise another problem: debugging the two apps together. Yay!

(3) Because a pixel-oriented UI designer is used, apps didn't have the modern Web (and mobile) feel, where the UI elements just flow and fill in "naturally" the available space, meaning the app looks good in mobile and desktop browsers both.

This due to the fact that desktop designer is pixel oriented, I too can't imagine if the designer should be able to replicate real web behavior. Unless we have another form designer that actually embeds some kind of webview / web browser, but we control the content.

[Phil]

Some good ideas, but they all point in the direction of lots of work, which is something I'd like to avoid.

One of the things I really like about using qooxdoo and qxotica is that it's so simple to set up and simple to maintain. The qxotica "toolkit" consists of two small bits of Pascal:

(1) A package that adds some File | New entries to Lazarus. This has been regularly broken by Lazarus changes, but it's fairly easy to keep running.

(2) A small console app that is run by Laz when you choose Run | Compile. This runs the qooxdoo generate.py script that pulls together all the qooxdoo JS code that the app will need. It also checks the syntax of your app's JS. If it outputs an error message, the console app that ran generate.py will reformat the error message so that Laz thinks it's a normal error and will jump to the file and line of the syntax error. To run the app, just reload the page in your browser.

That's it, other than some documentation and a couple of demo apps.

This approach could be taken with any IDE. I just happened to pick Laz because I already knew how to write an IDE add-in. And Laz already had JS syntax highlighting.

Now whether you could wrap the dynamic nature of JS and the asynchronous, client-server nature of a Web app behind Pascal in a way that would still make sense to Pascal developers remains to be seen. Not sure it would even be worth it.

[bee]

Most of the mentioned problems had been solved by Morfik quite a long time ago. For example:

• The UI designer in Morfik supports flowing layout, not only pixel-based.
• Client side languange can also be done in Pascal, so there's no need to use JS at all.
• Server side and client side part is clearly separated and can be debugged independently.

If you're advance enough, you could integrate third party JS frameworks or libraries e.g. qooxdoo or extjs into your Morfik app. And, it's all free. The problem is Morfik seems to be no longer developed. It's a dead and abandoned product. And unfortunately, there's no sign the author will open source the product. So that is that. 

[Phil]

This due to the fact that desktop designer is pixel oriented, I too can't imagine if the designer should be able to replicate real web behavior. Unless we have another form designer that actually embeds some kind of webview / web browser, but we control the content.

If you haven't seen qooxdoo's Playground demo, take a look at it here:

http://demo.qooxdoo.org/current/playground/#Hello%20World-ria

The mobile Playground only works with Appkit-browsers like Safari, but the desktop Playground will give the same idea.

Note how this is a kind of designer, and on-line too, for testing UI controls. Enter code on the left and click Run to see it run on the right. Now imagine you're typing in Pascal on the left and generating Javascript on the fly when you click Run...  QxPascal author, please step up.

Note that the source for the Playground demo is included with qooxdoo.

-Phil