Informal survey on Web app look and feel
lazarus / 38-Networking and Web Programming

----------------------------------------------------------------------
Phil · 2012-08-28 02:49

The new Raudus example app raises a question that developers have been
struggling with for years: Should Web apps look like (a) form-based
desktop apps, (b) HTML Web pages, (c) somewhere in between, or (d)
something else entirely.

Fortunately we now have an opportunity to review essentially the same
app done four different ways as a Web app. Here they are:

(1) New Raudus example app. No longer uses Ext JS; now has its own JS
framework apparently. Optimized for both desktop and mobile.

http://samples.raudus.com:88/18-FishFacts

More info: http://www.raudus.com/


(2) ExtPascal example app. Uses Ext JS. Not optimized for mobile.

No on-line example running that I can find, but screenshot of what it
looks like, both at runtime and design time, is here:

http://dl.dropbox.com/u/28343282/ExtPascal/MacXPlatform_Part7.html

The source of the example app is included with ExtPascal if you want
to compile and run it yourself locally.


(3) uniGUI example app. Uses Ext JS and ExtPascal. Not optimized for
mobile, but can be compiled as a standalone desktop app as well as a
Web app:

http://prime.fmsoft.net/demo/ucdemo.dll

Note: Click FishFacts on the left, then click the "Open" button.

More info: http://unigui.com/


(4) Dashcode example app. Pure JS solution, meaning it can be deployed
from any Web server, even from a Dropbox account. Optimized for both
desktop and mobile.

http://web.fastermac.net/~MacPgmr/iApps/fishfacts/

-or-

http://dl.dropbox.com/u/28343282/iApps/fishfacts/index.html

More info:
http://dl.dropbox.com/u/28343282/MacXPlatform/MacXPlatform_Part9.html


Questions:

Which app's look-and-feel do you prefer? And why?

Thanks.

-Phil

----------------------------------------------------------------------
DelphiFreak · 2012-08-28 05:07

For me No. 3 uniGUI looks interesting.

But what is more important for me than "look and feel": How easy can
it be deployed?

----------------------------------------------------------------------
Phil · 2012-08-28 14:41

Quote from: DelphiFreak on August 28, 2012, 07:07:32 amHow easy can it
be deployed?

Apps 1, 2 and 3 all require a server where you are permitted to
install compiled binaries. Free or cheap "shared" servers will
generally _not_ permit that - PHP scripts, etc. may be allowed on
some, but not compiled binaries. For that you'll need either your own
server or a VPS server, for example from someone like Linode:

http://www.linode.com/

App 4 can be deployed anywhere that Web pages can be deployed.

Thanks.

-Phil

----------------------------------------------------------------------
TurboRascal · 2012-08-29 19:07

It's hard to tell, I most of the times feel most comfortable with just
the "rich web page" look&feel, but stuff that looks like desktop apps
confined in the browser also has its "cool factor". UniGUI feels like
something inbetween. Ultimately, the usefulness should be the deciding
factor, and I'd guess it's not easy to say in advance. Perhaps the web
page style should be used when the target is a web service, say
something similar to a forum like this, while an application which
would mainly replace a desktop application should look like a desktop
application. Paradigm shift isn't easy for most people, so I believe
people would be most comfortable with what most resembles what they
expect, no matter what the other factors are.

I myself would most likely prefer something that is free and open
source, regardless. Is there anything like that? Ability to use
Lazarus in development doesn't hurt either...

----------------------------------------------------------------------
Phil · 2012-08-29 21:02

Quote from: TurboRascal on August 29, 2012, 09:07:46 pmIt's hard to
tell, I most of the times feel most comfortable with just the "rich
web page" look&feel, but stuff that looks like desktop apps confined
in the browser also has its "cool factor". UniGUI feels like something
inbetween. Ultimately, the usefulness should be the deciding factor,
and I'd guess it's not easy to say in advance. Perhaps the web page
style should be used when the target is a web service, say something
similar to a forum like this, while an application which would mainly
replace a desktop application should look like a desktop application.
Paradigm shift isn't easy for most people, so I believe people would
be most comfortable with what most resembles what they expect, no
matter what the other factors are.

Can't disagree with anything you've said here.

Quote from: TurboRascal on August 29, 2012, 09:07:46 pmI myself would
most likely prefer something that is free and open source, regardless.
Is there anything like that? Ability to use Lazarus in development
doesn't hurt either...

Here's a take on the open source status and other notes for these 4
tools:

(1) Raudus. Source not available (yet); does not support Mac (yet?).

(2) ExtPascal. Open source; visual components require Ext JS, which is
free to use for open source projects, license required for non-open
source projects.

(3) uniGUI. This is currently Delphi-only and Windows-only (it
integrates with Delphi form designer). But Farshad is a very good
programmer and could probably port this to Lazarus / FPC / all
platforms if he wanted to. Quite a few users if the unigui.com forums
are any guide.

(4) Dashcode. This is not a Pascal tool; it's a full Javascript IDE;
resulting JS apps can communicate via standard Ajax with backend (on
server) written in PHP, Pascal, etc. Available only on Mac, but it's
free, with no cost to deploy its JS "Parts" (visual components) with
the app.

Thanks.

-Phil

----------------------------------------------------------------------
bobo · 2012-08-30 07:59

I think you are not needed to buy extjs license in case your clients
can just download extjs and install it themselves to run your web
application and use your Lazarus/FPC backend on their servers.
License is only needed - if your application is not open source itself
- in case you modify extjs yourself - downloading already published
extensions does not matter - or ship it packaged with your app.

----------------------------------------------------------------------
Phil · 2012-08-30 20:08

Quote from: bobo on August 30, 2012, 09:59:12 amI think you are not
needed to buy extjs license in case your clients can just download
extjs and install it themselves to run your web application and use
your Lazarus/FPC backend on their servers.
License is only needed - if your application is not open source itself
- in case you modify extjs yourself - downloading already published
extensions does not matter - or ship it packaged with your app.

Here's the actual license:

http://www.sencha.com/products/extjs/license/

Thanks.

-Phil

----------------------------------------------------------------------
ojn · 2012-08-31 03:34

Hi Phil:

Thanks for presenting this information on these web products.

Do you having any idea how Morfik would fit into this comparison?

Thanks,
Jerry

----------------------------------------------------------------------
Phil · 2012-08-31 14:15

Quote from: ojn on August 31, 2012, 05:34:49 amDo you having any idea
how Morfik would fit into this comparison?

I haven't heard much about Morfik in quite a while. Does it have a
FishFact example Web app we could add to the comparison?

Thanks.

-Phil

----------------------------------------------------------------------
ojn · 2012-09-01 04:58

Quote from: Phil on August 31, 2012, 04:15:41 pmI haven't heard much
about Morfik in quite a while. Does it have a FishFact example Web app
we could add to the comparison?

Hi Phil:

I don't know that much about Morfik, other than reading about it
discussed here in the past. I was hoping that you may have known about
a FishFacts web example created with Morfik.

Thanks,
Jerry

----------------------------------------------------------------------
Phil · 2012-09-01 15:17

Quote from: ojn on September 01, 2012, 06:58:37 amI don't know that
much about Morfik, other than reading about it discussed here in the
past. I was hoping that you may have known about a FishFacts web
example created with Morfik.

Morfik does have some pretty impressive demos. See the chess demo
here:

http://chess.sampleprojects.morfikspace.com

Even their forum was created with Morfik.

More info here:  http://en.wikipedia.org/wiki/Morfik

Note that Morfik is a Windows-only tool, although Web apps created
with it can be deployed to Windows or Linux. Note also that it appears
development on the free version has stopped.


The most impressive Web development tool I've seen lately is Elevate
Web Builder.

http://www.elevatesoft.com/products?category=ewb&type=web

Again, Windows only, not open source, not free. But you code in Pascal
and it compiles the Pascal to Javascript. Here's a demo:

http://www.elevatesoft.com/cdcollector/cdcollector.html

Note that the Morfik or Web Builder demos are _not_ optimized for
mobile devices, which is often a requirement these days.


Is there a chance for an open-source Pascal tool for Web app
development that rivals what Morfik and Web Builder provide? Probably
not - two things are working against that possibility.

(1) Lazarus community is not big enough to support that kind of tool.
Not enough users or contributors - both are essential.

(2) The trend toward mobile has shown that the ultimate "Web app" may
really be a native mobile app, what's sometimes referred to as an
"out-of-browser" Web app. This kind of app access online resources
via, say, Web services, automatically syncs its data with the user's
other devices and computers via, say, iCloud, usually has some
functionality off-line, and looks and feels and performs great.

Thanks.

-Phil

----------------------------------------------------------------------
shaneavery · 2012-09-01 19:04

Phil,

I have followed your work and additions to Ext-Pascal, and I am
grateful for your efforts.  I am no expert, but I have spent about 12
months worth of R & D regarding this very question, and would like to
offer up some of my observations based on my own experience. The
project I was working on was an enterprise level CMS (Content
Management System).

When it comes to web apps, the first consideration that came up for me
was, "What should be processed on the client and what should be
processed on the server?"  I soon realized that putting as much
processing as possible onto the client app has many advantages. Two
mention just two, (1) a good user experience (fewer HTTP requests,
less network latency, faster drawing/painting etc.) and (2) relieving
server load for multiple simultaneous users/connections (concurrency).
With that thought in mind, I believe client side JavaScript is a good
choice for GUIs if you want to run your web-app in a browser, and you
can cache your app.  I believe Ext-Pascal still has to do some server
side work to push out the GUI, even though the final output is
JavaScript.  Is that correct?  Is that the same with the other Pascal
offerings?  If so, then it may be better to use a pure JavaScript
framework like Sencha Touch or Ext-JS (or any other, for that matter)
for your client side GUI.  I have created apps using both of these. 
They have nice looking, functional, and user friendly widgets. Sencha
does a good job of trying to emulate class based OOPs, even though
JavaScript is prototype based.  This is one thing that made it easier
for me to transition from Object Pascal to JavaScript, which I had no
experience with prior.  Sencha is trying to create a common code base
for their desktop and mobile browser offerings, which in theory would
make it easier to code web app front-ends with shared code for both. 
However, they have yet to pull this off in real-world practice. 
Sencha Touch is a robust framework for HTML5 mobile web-apps, but
performance on mobile browsers (especially Android) have serious
issues - depending on what widgets are used. I have created a hybrid
mobile app using Sencha Touch and PhoneGap, but performance is still
an issue on Android.

Be that as it may, I also explored creating a regular desktop app as a
client side "web-app".  I created a test desktop app in Lazarus and
compiled it for Windows and Linux, which worked like a charm.  The
look and feel was much superior to any of the JavaScript versions I
created.  Since the test app only needed a JSON parser and an HTTP
library, it was very easy to write using Lazarus.  My app made calls
to my server using standard GET, PUT, POST and DELETE requests over
HTTP(s).  Based on my experience with this test app, I feel (if it is
possible) the best web-apps eliminate the browser altogether.  I was
able to implement superior security by implementing a VPN tunnel for
connections.  I can do all this because my app has full access to the
OS and filesystem, not just the pieces and parts the browser allows. 
Plus, I don't have to worry about all the hacking and browser exploits
out there, because there is no browser.  You sure eliminate a lot of
wasted time debugging and fighting with browser compatibility issues
if you can factor out the browser. Sometimes it is not possible to
just create standard desktop apps as client-side "web-apps", due to a
project's requirements. If it is possible, it is a superior approach
IMHO.

On the server side, I had to answer the question, "What work
absolutely needs to be done here?"  In my case, I needed to store and
perform CRUD operations with data in a database, query the database
for formatting data later, automatically generate static HTML pages
with embedded JavaScript, and serve them out to the masses in a way
that can be easily scaled.  The best solution I found (at the time and
within the budget) involved writing my own custom Template Engine with
Lazarus/ FPC, using CouchDB for the Database System, and using Apache
as an HTTP server to serve out the rendered pages.  CouchDB uses a
restful interface for all it's features, so all you need is an HTTP
library and you can control any instance of CouchDB from anywhere.  It
also has an excellent replication system, so you can include a local
instance of the DB with your app, and replicate that with the Internet
server instance in the "cloud".  This yields an exceptional user
experience, because there is no network latency when the user
interacts with the data, only when they sync - which is a background
process.  CouchDB also provided the query functionality I needed on
the server side to re-format data that would later become HTML.  The
Template Engine took care of the formatting, rendering, and file
management chores. Apache did what it is best at - serving out
gazillions of static web pages with very low overhead.  This
architecture would scale very well, even dynamically with VPS(s) if
needed.  Even though I never finished the template engine, I believe
writing a natively compiled server-side application in Pascal would
have been a very efficient, cost effective, high performing, and
secure way to handle the work - especially compared to interpreted
language solutions.  Granted, we were expecting to control our own
dedicated servers in the data center, but I believe we could still
create a template engine that could be run as a Fast-CGI app all the
same. Most common web hosts will allow Fast-CGI.

Sorry for the long speech, I guess I rambled on a bit.  I hope what I
shared is helpful to someone.

Thanks,

Shane Avery

----------------------------------------------------------------------
Phil · 2012-09-01 19:43

Quote from: shaneavery on September 01, 2012, 09:04:42 pmI am no
expert, but I have spent about 12 months worth of R & D regarding this
very question, and would like to offer up some of my observations
based on my own experience. The project I was working on was an
enterprise level CMS (Content Management System).

Shane,

Very interesting to hear your experiences.

In answer to your question, yes, server apps developed with ExtPascal
(or uniGUI) generate JS dynamically in response to AJAX requests (eg,
when a user clicks a button), although the amount of JS sent by the
server is generally fairly modest. The Ext JS .js file is downloaded
with the first page load. Other tools like Dashcode and Elevate Web
Builder generate static JS files that are all downloaded initially
with the page load.

I agree that a native, standalone app that uses online resources often
makes a better Web app, particularly on mobile devices, where
downloading big chunks of JS at startup may be fairly slow,
particularly over public wifi systems.

Oftentimes presenting the online stuff behind a Web service is a good,
modern way. If you look at Part 11 here, you can see how an existing
Web service that provides weather forecasts is used. Although the
series is about Mac and iOS programming, the code presented in Part 11
can be used on any platform. It uses Web Service Toolkit for the
client; WST can also be used on the server to provide a Web service to
clients.

http://dl.dropbox.com/u/28343282/ObjP/index.html

Although this example Web service returns XML, which the client app
then has to parse, some of the Web services I've worked with break the
returned data down into multiple properties and methods so that no
parsing is needed.

Thanks.

-Phil

----------------------------------------------------------------------
MikeO · 2012-09-07 22:06

Shane,

Thanks for sharing your experiences.

Quote from: shaneavery on September 01, 2012, 09:04:42 pmSometimes it
is not possible to just create standard desktop apps as client-side
"web-apps", due to a project's requirements. If it is possible, it is
a superior approach IMHO.

That's true. If you don't mind me asking, what HTML library did you
use? Did you try RealThinClient (RTC)? Or did you go with Synapse or
Indy?

QuoteThe best solution I found (at the time and within the budget)
involved writing my own custom Template Engine with Lazarus/ FPC,
using CouchDB for the Database System, and using Apache as an HTTP
server to serve out the rendered pages
Did you give a look at MongoDb? It also uses JSON (actually BSON for
Binary JSON). I looked at it 2 years ago when I first saw CouchDb. I
didn't get any further than kicking the tires. 

There is also open source  morMot from http://synopse.info  that is
ORM (Object Relational Model). It looks to be quite powerful because
you write the business rules in Pascal, not as triggers in the
database. They use SQLite as a fast client server database (yes, I did
say Client Server), or you can connect to other databases like Oracle.
It transfers JSON from the webserver to the application.

Quote......  Even though I never finished the template engine, I
believe writing a natively compiled server-side application in Pascal
would have been a very efficient, cost effective, high performing, and
secure way to handle the work - especially compared to interpreted
language solutions.  Granted, we were expecting to control our own
dedicated servers in the data center, but I believe we could still
create a template engine that could be run as a Fast-CGI app all the
same. Most common web hosts will allow Fast-CGI.

I used Morfik for 6 months and it too generated on the fly JS for the
user. I assume that is what you are doing with your templates.

When I first saw Morfik 5 years ago I thought it was great (very
expensive at around $2000). But when it went free in Nov 2010 I spent
time with it. It was really quite good (if you like Firebird which is
its default db engine). It now (supposedly) connects to PostgreSQL but
I wouldn't bet the farm on it. Since they released it for free in late
2010, the company was bought out by another company that used Morfik
for their commercial applications. Unfortunately they haven't been
updating Morfik in the past 19 months so it is dying a lingering
death. The concept of Morfik was fantastic. Write your application in
Pascal or Basic or C# and run it on the desktop or the web. Morfik can
also write webservices so passing data back and forth was
straightforward. If the new company kept supporting and improving
Morfik, I might still be using it.

The Morfik application is compiled in either Delphi or FPC (your
choice). The problem with Morfik was speed. It takes time for the
webserver to generate JS for each page that has to be rendered. It can
cache pages for individual users, but not between users if the users
are authenticated (different URL parameters). Morfik could handle
maybe 24 users, but after that it slowed down dramatically. Their
claim to fame was Morfik was faster than an interpreted language like
PHP because the web server is compiled. Well, a compiled webserver
doesn't necessarily mean it's faster. Morfik is stateless which means
it had to transfer quite a bit of session data back and forth.
Authenticating users took too much time. Fast-CGI would run circles
around Morfik without breathing hard.

UniGUI maintains state on the web server in memory so it should handle
a few hundred users easily.
I used Raudus when it first came out and it was very interesting. The
documentation back then was missing so progress was slow and there
quite a few bugs. I never did get the hang of extPascal because I had
to write JS code to communicate with the ExtJs components. I might as
well just use PHP and JS.

I am still looking for web app nirvana. 
I'm looking at WebBuilder from ElevateSoft which writes the JS front-
end but not the web server back-end. I downloaded their eval today and
will give it a try. It of course connects to ElevateDb or DBISAM. 
Access to other databases will be along later.

Anyways, I thought I'd give you and the guys some feedback.

Mike
(Old Delphi User)

----------------------------------------------------------------------
fredycc · 2012-09-07 22:58

Here another chess created with uniGUI:
http://forums.unigui.com/index.php?/topic/2253-chess-game/

I like uniGUI,:

 -Very easy to use and deploy,
 -Easily work with JS code
 - Various types of databases with Zeos

But only Delphi 

regards

----------------------------------------------------------------------
JuhaManninen · 2012-09-08 07:46

Quote from: shaneavery on September 01, 2012, 09:04:42 pmBased on my
experience with this test app, I feel (if it is possible) the best
web-apps eliminate the browser altogether.

That is my thinking, too. A "normal" client app is easier to make,
debug and maintain. It usually provides a better user experience.
The only problem is deployment. The installation and version update
should be very easy, almost automatic.

What kind of deployment solutions are you people using?
I soon have to find such solution for a project I am working on.


Regards
Juha

----------------------------------------------------------------------
Phil · 2012-09-08 15:03

Quote from: JuhaManninen on September 08, 2012, 09:46:58 amThat is my
thinking, too. A "normal" client app is easier to make, debug and
maintain. It usually provides a better user experience.
The only problem is deployment. The installation and version update
should be very easy, almost automatic.

What kind of deployment solutions are you people using?
I soon have to find such solution for a project I am working on.

Depends on whose point of view you're taking - end users, people who
manage the end users' computers, or developers. The claim for in-
browser Web apps is that they satisfy all 3 groups - users always use
the latest version and don't need admin privileges to run it, admins
don't need to deal with user requests for installs or elevated
privileges, developers don't have to deal with end user install
issues.

Of course, Web apps have their own issues: don't work offline, no
local storage of user-entered data, dreadful in-browser user
experience, etc.

The only thing that comes close to meeting Web app claims without Web
app downsides is the App Store model: easy install and update, code-
signed, sandboxed, local storage of data that is synced to user's
other devices means many apps can be used off-line, great look and
feel.

Thanks.

-Phil

----------------------------------------------------------------------
Phil · 2012-09-08 15:23

Quote from: MikeO on September 08, 2012, 12:06:22 amI might as well
just use PHP and JS.

MikeO: When I first started looking at Web app tools almost 5 years
ago, I started with PHP. Now I think I've come full circle to the
conclusion that PHP + JS might very well be a good choice for many
types of Web apps. This forum is running on PHP, for example.

But for the JS side a UI framework is still needed to provide at least
a semblance of what a native app would look and feel like. Recently I
looked at some additional JS frameworks. They all have drawbacks, but
the qooxdoo JS framework has recently been updated to version 2.0 and
has support both for desktop browsers and mobile browsers, with tablet
options for mobile.

http://qooxdoo.org/

I worked through the qooxdoo tutorial for their Twitter mobile example
and uploaded it to my Web site. Since there is no visual designer for
qooxdoo, this example involves quite a bit more JS code than, say,
Dashcode (the FishFacts app I wrote only required writing about a
dozen lines of JS).

http://web.fastermac.net/~MacPgmr/iApps/mobiletweets/

Enter something like "qooxdoo" or "LazarusDev" (without quotes).

Note that this example app's UI is intended for mobile browsers. It
does work in some desktop browsers, but for desktop support you would
write a separate UI (this is generally true of any Web app).

Thanks.

-Phil

----------------------------------------------------------------------
Phil · 2012-09-08 15:39

Quote from: fredycc on September 08, 2012, 12:58:40 amI like uniGUI,:

 -Very easy to use and deploy,

Only if you have your own dedicated server or a VPS server. Shared
servers and many employers do not allow executable binaries to be run,
only scripting languages like PHP.

Quote from: fredycc on September 08, 2012, 12:58:40 amBut only Delphi 

And only Windows. As a Mac user, uniGUI can't be of much interest to
me.

Thanks.

-Phil

----------------------------------------------------------------------
TurboRascal · 2012-09-08 19:09

Quote from: shaneavery on September 01, 2012, 09:04:42 pmSometimes it
is not possible to just create standard desktop apps as client-side
"web-apps", due to a project's requirements. If it is possible, it is
a superior approach IMHO.

Superior indeed. An example - for the past year i had a chance to
observe two online services provided by my country's financial agency;
one of them is a web app and the other one has a standalone Windows
client. The web app works only in IE, although its module for digital
signing is actually a Java applet, but it simply has problems in other
browsers I've tried, and the smartcard authentication has similar
troubles. Moreover, it doesn't work the equally well in all IE
versions, and it seems to be sensitive to the Java version. There are
some tweaks needed in the IE options, the first being to put the
address to the Trusted Sites and sometimes some more... In short, a
living nightmare to setup, and it has different problems on different
machines.

The other app, the native one is a completely different story, works
like a charm. It has a webinstaller which downloads depedencies and
the main installer, installs everything and it simply works when
started from the Start menu. Of course, it also behaves consistently
on every machine it is installed.

And that's just one example, I've seen many other similar cases. There
were also some efforts to exchange some traditional business
applications with local intranet web aplications, since it is supposed
to be so easy to deploy, by simply opening the address in a browser
and/or putting a desktop shortcut to it. However, I'd say native
clients can be just as easily deployed, especially Lazarus and Delphi
apps whose binaries can often work completely standalone, without
installations. Deployment can therefore be as easy as for webapps, by
simply putting a desktop shortcut to the executable on a network
share. And I'd say the quality of working in typical native apps still
surpasses that in typical web apps by far.

Quote from: MikeO on September 08, 2012, 12:06:22 amI am still looking
for web app nirvana. 

Same here

Lazarus already has nice server-side options, if only there were some
free and efficient JS framework which could be served to the client
side...

----------------------------------------------------------------------
JuhaManninen · 2012-09-08 19:12

Quote from: Phil on September 08, 2012, 05:03:58 pmThe only thing that
comes close to meeting Web app claims without Web app downsides is the
App Store model: easy install and update, code-signed, sandboxed,
local storage of data that is synced to user's other devices means
many apps can be used off-line, great look and feel.

Yes.
Actually I was hoping for something more concrete, like links for
example projects using this App Store model.
Has anyone done it using FPC?

Java has the Web Start system. It has a restricted sandbox mode and
then a non-restricted mode which requires authentication.
It installs Java VM automatically if needed, and updates the program
when a new version is available. All this happens by clicking a link
in a browser.
It looks like a perfect system although it has not became very
popular, for some reason (?).

I am looking for something similar for FPC / Lazarus.

Juha

----------------------------------------------------------------------
Phil · 2012-09-08 19:49

Quote from: JuhaManninen on September 08, 2012, 09:12:05 pmActually I
was hoping for something more concrete, like links for example
projects using this App Store model.
Has anyone done it using FPC?

These two apps were developed with Lazarus and are available from the
Mac App Store:

http://itunes.apple.com/us/app/earmaster-pro/id412626299?mt=12
http://itunes.apple.com/us/app/jigsaws-galore/id426250075?mt=12

Note that these would not be considered "out-of-browser Web apps",
which I believe is what Shane was referring to, but they do meet your
requirement of "installation and version update should be very easy,
almost automatic".

Quote from: JuhaManninen on September 08, 2012, 09:12:05 pmJava has
the Web Start system.
It looks like a perfect system although it has not became very
popular, for some reason (?).

Yes, I've tested Java's Web Start system. It's unpopular because
nobody creates desktop apps with Java.

Thanks.

-Phil

----------------------------------------------------------------------
Phil · 2012-09-08 19:54

Quote from: TurboRascal on September 08, 2012, 09:09:05 pm[...]one of
them is a web app and the other one has a standalone Windows client.
The web app works only in IE

Yes, I've seen similar efforts. I'm not sure that a government agency
product that targets only Windows is evidence of much beyond limited
imagination.

Quote from: TurboRascal on September 08, 2012, 09:09:05 pmLazarus
already has nice server-side options, if only there were some free and
efficient JS framework which could be served to the client side...

Look at qooxdoo, as I suggested above:  http://qooxdoo.org/

Thanks.

-Phil

----------------------------------------------------------------------
TurboRascal · 2012-09-08 22:29

Quote from: Phil on September 08, 2012, 09:54:19 pmI'm not sure that a
government agency product that targets only Windows is evidence of
much beyond limited imagination.

I think it has nothing to do with the developers' imagination, and
everything to do with the way they get hired hahah

Quote from: Phil on September 08, 2012, 09:54:19 pmLook at qooxdoo, as
I suggested above:  http://qooxdoo.org/

This most certainly looks interesting. That might be it, combined with
the server-side CGI programs...

----------------------------------------------------------------------
fredycc · 2012-09-09 00:36

Quote from: Phil on September 08, 2012, 05:03:58 pmThe only thing that
comes close to meeting Web app claims without Web app downsides is the
App Store model: easy install and update, code-signed, sandboxed,
local storage of data that is synced to user's other devices means
many apps can be used off-line, great look and feel.

PhoneGap?

----------------------------------------------------------------------
Phil · 2012-09-09 00:40

Quote from: fredycc on September 09, 2012, 02:36:48 amPhoneGap?

The only thing PhoneGap does is wrap HTML/JS/CSS into a native wrapper
(eg, Objective-C Webview control), which can then be compiled as
usual. The resulting app can then be distributed via an app store.
Nothing else is different.

Thanks.

-Phil

----------------------------------------------------------------------
Phil · 2012-09-09 01:03

Quote from: TurboRascal on September 09, 2012, 12:29:33 amThis most
certainly looks interesting. That might be it, combined with the
server-side CGI programs...

With all of these JS frameworks, it comes back to: how to use them
with a visual designer (eg, Laz form designer)?

Perhaps some ideas could be borrowed from ExtPascal. For those who
have forgotten, here's a simple example of how an ExtPascal app works
when created with the optional Lazarus add-in packages:

(1) In Lazarus, choose File | New | ExtPascal Application. Then drop a
button on the resulting form, change the button's caption, and double-
click its Click property to add an event handler. The resulting code
looks very much like an LCL form:

Code: [Select]type
  TExtWindow1 = class(TExtWindow)
    ExtButton1: TExtButton;
    procedure ExtButton1Click;
  private
  public
    constructor Create;
    procedure Show;
  end;

implementation

uses
  AppThread;

constructor TExtWindow1.Create;
begin
  inherited;
{$IFDEF UseRuntime}
 {$I *.inc}
{$ENDIF}
end;

procedure TExtWindow1.Show;
begin
  inherited Show;
end;

procedure TExtWindow1.ExtButton1Click;
begin
  ExtButton1.Text := 'Clicked';
end;

And the resulting .lfm file looks familiar too:

Code: [Select]object ExtWindow1: TExtWindow1
  Left = 246
  Height = 300
  Top = 157
  Width = 400
  Title = 'ExtWindow1'
  object ExtButton1: TExtButton
    Left = 168
    Height = 25
    Top = 168
    Width = 75
    MinWidth = 75
    Text = 'Click Me'
    Click = ExtButton1Click
  end
end

One thing that's different is that there's an extra step when you
compile - Laz runs a converter that generates the include file
referenced in the code. The .inc file's code looks like this: (This is
code you would have to write by hand otherwise.)

Code: [Select]  Id := 'ExtWindow1';
  Height := 334;
  Width := 408;
  OnEsc := JSFunction('');
  Title := {$IFNDEF MSWINDOWS}AnsiToUTF8{$ENDIF}('ExtWindow1');
  Layout := lyAbsolute;

  ExtButton1 := TExtButton.Create;
  with ExtButton1.AddTo(Items) do
    begin
    Id := 'ExtWindow1_ExtButton1';
    X := 168;
    Height := 25;
    Y := 168;
    Width := 75;
    Text := {$IFNDEF MSWINDOWS}AnsiToUTF8{$ENDIF}('Click Me');
    On('click', Ajax(ExtButton1Click));
    TooltipType := 'title';
    end;

When you run the app on the server, the ExtPascal code generates
Javascript that's sent to the browser (along with the Ext JS
framework's .js file). I've excerpted the JS and inserted some line
breaks to make it more readable:

Code: [Select]O10=new Ext.Button({id:"ExtWindow1_ExtButton1",x:168,hei
ght:25,y:168,width:75,text:"Click Me",tooltipType:"title"});

O0=new Ext.Window({id:"ExtWindow1",height:334,width:408,onEsc:function
(){},title:"ExtWindow1",layout:"absolute",items:[O10]});

O10.on("click",function(){return Ext.Ajax.request({url:"/cgi-bin/cgiga
teway.cgi/ExtButton1Click",params:"Ajax=1&Obj=O0&`",success:AjaxSucces
s,failure:AjaxFailure});});

O0.show("");

When the button is clicked, an Ajax call to the app's ExtButton1Click
method causes additional JS to be sent to the browser - you just don't
see this since it's generated dynamically.


It would seem as though something similar could be done with qooxdoo,
only this time build the design control capabilities in from the
start, rather than bolting them on after the fact like I did with
ExtPascal.

If you look in the qooxdoo SDK's framework/api/script folder, you'll
see the JS API for all of the controls. It seems like FPC's JSON
parser (Source/packages/fcl-json/src) could be used to parse this into
corresponding Pascal code, similar to what Wanderlan's parser did with
the Ext JS docs. For example, it looks like everything you see about
the Button control here is in the qx.ui.form.Button.json file:

http://demo.qooxdoo.org/current/apiviewer/#qx.ui.form.Button


Anyone interested in this? Or have their own ideas?

Thanks.

-Phil

----------------------------------------------------------------------
Phil · 2012-09-16 21:25

Quote from: TurboRascal on September 09, 2012, 12:29:33 am
Quote from: Phil on September 08, 2012, 09:54:19 pmLook at qooxdoo, as
I suggested above:  http://qooxdoo.org/

This most certainly looks interesting. That might be it, combined with
the server-side CGI programs...

Here's my qooxdoo mobile FishFacts app:

http://web.fastermac.net/~MacPgmr/iApps/fishfacts_qx/

If you have a tablet (eg, iPad), rotate it and see how the app
rearranges itself.

I don't have any Android devices, but I tested it in the Android 2.3.3
emulator and it ran okay there.

This app uses the qooxdoo _mobile_ widgets, but should work on most
desktop browsers too (except IE).


I'm working on a package for Lazarus that provides a simple way to
create qooxdoo master-detail apps like this - even though all
JavaScript, Lazarus can edit and syntax highlight JS files too.

Thanks.

-Phil

----------------------------------------------------------------------
esvignolo · 2012-09-16 22:32

That's a great idea Phil, works great! I am eager to try your package.
Thanks for sharing and your work.

----------------------------------------------------------------------
Phil · 2012-09-16 22:46

Quote from: esvignolo on September 17, 2012, 12:32:56 amThat's a great
idea Phil, works great! I am eager to try your package. Thanks for
sharing and your work.


I'm still probably a couple weekends away from having something to
post, but I'm pleased with how well the integration with Laz is going.
You'll even be able to "compile" from within Laz, which updates the
app's various dependencies (generate.py script) and also Laz will jump
to the line of any JavaScript syntax error that this script catches.

One goal of the package is to create a new qooxdoo app that includes a
lot of boilerplate code, so you can get started without learning
everything about qooxdoo. For example, the master-detail structure and
the iOS look to the Fish Facts demo app is a very common pattern in
mobile apps - most of the basic code can be generated automatically
and you just fill in, say, your JSON source - eg, .json file on server
or CGI/FCGI/PHP server-side app that delivers JSON, add widgets to
your detail page, and bind them to elements of your JSON data.

Although I don't plan on doing anything like a visual designer, with
Web apps widgets are generally not positioned absolute like they would
be, say, in a Pascal form. Instead they "flow" and position themselves
relative to other controls. In fact, this demo app doesn't have any
absolute positioning in it.

Thanks.

-Phil

Thanks.

-Phil

----------------------------------------------------------------------
esvignolo · 2012-09-16 23:11

Understandably, not handled as Pascal Forms due to the nature of
qooxdoo and share the design in the mobile, tablet or desktop. Deputy
catches a android phone and android tablet, to illustrate your
explanation to other users. Thanks again for your commitment and
ability.

Phil take a look at http://code.google.com/p/qxpascal/ this
discontinued since 2010, but you might find something interesting.

----------------------------------------------------------------------
TurboRascal · 2012-09-17 07:52

Phil, that demo looks great! This qooxdoo looks quite promising, and
it would be really nice if you can work on the Lazarus integration...

----------------------------------------------------------------------
Phil · 2012-09-17 21:15

Quote from: esvignolo on September 17, 2012, 01:11:46 amPhil take a
look at http://code.google.com/p/qxpascal/ this discontinued since
2010, but you might find something interesting.

Yes, I vaguely recall when "bee" was working on qxpascal. But what I'm
doing is very different - write the entire client in JS, with no
restrictions on what the server side app is written in - Pascal, PHP,
etc.

An advantage to this approach is that you can optionally convert the
JS client into a native mobile app via PhoneGap.

Thanks.

-Phil

----------------------------------------------------------------------
Phil · 2012-09-17 21:19

Quote from: TurboRascal on September 17, 2012, 09:52:29 amPhil, that
demo looks great! This qooxdoo looks quite promising, and it would be
really nice if you can work on the Lazarus integration...

Yes, I think the Fish Facts demo turned out looking better than I
expected it to. The list has a very modern look to it. Does it have a
native look and feel? Probably not quite. But the idea I think is that
you don't use qooxdoo with the goal of writing a native app, not even
via PhoneGap. Instead, you use it with the goal of writing a Web app,
with an option to also have a native app for one or more mobile
platforms.

Thanks.

-Phil

----------------------------------------------------------------------
Phil · 2012-09-21 21:54

If anyone wants to get started with qooxdoo, take a look at the
manual:

http://manual.qooxdoo.org/2.0.2/qooxdoo.pdf

qooxdoo is documented about as well as one ever sees for this type of
open source toolkit. The framework looks well designed and so far
pretty bug-free too.

Thanks.

-Phil

----------------------------------------------------------------------
Phil · 2012-10-02 19:40

Quote from: Phil on September 21, 2012, 11:54:06 pmIf anyone wants to
get started with qooxdoo...

Here's the qooxdoo "Mobile Showcase" that shows the mobile widgetset:

http://demo.qooxdoo.org/devel/mobileshowcase-ios/index.html#%2F

Thanks.

-Phil

----------------------------------------------------------------------
Phil · 2012-10-06 16:22

Tools for integrating with and developing qooxdoo Web apps with
Lazarus are now available. See post in 3rd party section:

http://www.lazarus.freepascal.org/index.php/topic,18463.0.html

Thanks.

-Phil

----------------------------------------------------------------------
TimYoung · 2013-06-15 07:10

I know that this thread has long been dead, but I just wanted to
update everyone with a new online demo application for Elevate Web
Builder that does the FishFacts demo in EWB style:

http://www.elevatesoft.com:8080/datasetclient/datasetclient.html

It shows how to do a basic database application in a grid with
editing, along nested transactions and saving/loading the database
to/from local storage.

There are also some other online demos here (bottom of the page) for
painting (canvas), master-detail database work, docking, and more:

http://www.elevatesoft.com/products?category=ewb&type=web

Currently the back-end modules that are used for custom back-end work
or for automatic dataset handling are only available for Delphi, but
if there's interest, I can do some versions for Lazarus also.

Tim Young
Elevate Software
www.elevatesoft.com