I'm wonder if EWB will fit my needs:
Need for a limited number of customers a responsible web app for entering inventories and similar stuff. Backend will be implemented at a REST API build on Rails.
Employes will connect to a intranet with wi-fi connectivity using smartphones and 7" tablets to create inventories, invoices and so on.
We program in Delphi since 1.0 and using Elevate Software's both databases since Tim created them, but in this case DB will be PostgreSQL.

Do you think is a good combination? EWB rendered pages are ok for small sizes? Implementing our own TDataSet for communicating with back end will be hard?

Thanks in advance, guys!
Tiago Ameller
Menorca Zeros i Uns SL
www.sistemasc.net

Tiago Ameller wrote:

> I'm wonder if EWB will fit my needs:
> Need for a limited number of customers a responsible web app for
> entering inventories and similar stuff. Backend will be implemented
> at a REST API build on Rails.  Employes will connect to a intranet
> with wi-fi connectivity using smartphones and 7" tablets to create
> inventories, invoices and so on.  We program in Delphi since 1.0 and
> using Elevate Software's both databases since Tim created them, but
> in this case DB will be PostgreSQL.
>
> Do you think is a good combination? EWB rendered pages are ok for
> small sizes? Implementing our own TDataSet for communicating with
> back end will be hard?

I'd say it would work just fine. I've done REST access from EWB
applications (it's supported easily using a component). For Delphi
programmers, WebBuilder is "natural". As for the size, the smaller you
go, the more compromise you have to make, but that's the same for any
dev tool, not just EWB. I started off doing a tablet based system and
defined "must work on Nexus 7 tablet", which was fine, and have since
managed to squeeze the interface to the 3.5" displays of iPhone and
Android phones. It ain't pretty, but it works. For the larger devices,
you can spread out and make it better. I used a lot of "responsive
code" in my application, but EWB2 will remove the need for some of that.

--

Matthew Jones

Tiago,

<< I'm wonder if EWB will fit my needs:
Need for a limited number of customers a responsible web app for entering
inventories and similar stuff. Backend will be implemented at a REST API
build on Rails.
Employes will connect to a intranet with wi-fi connectivity using
smartphones and 7" tablets to create inventories, invoices and so on.
We program in Delphi since 1.0 and using Elevate Software's both databases
since Tim created them, but in this case DB will be PostgreSQL.

First of all, you should definitely try to use EWB 2 for this.  It's just
better, and more flexible than 1.x, especially in terms of layout
capabilities, and that's only going to become more the case as EWB 2
evolves.  This is important for mobile devices.

<< Do you think is a good combination? EWB rendered pages are ok for small
sizes? >>

As long as you don't go nuts and add 40 forms to an application that's
supposed to be used on mobile, you should be fine.  Basic EWB 2 applications
(just a few forms) weigh in at around 800k (compressed) for the HTML and JS
file combined, but both of those will be cached by the browser and not
re-downloaded unless they've been modified.   This means that you'll see a
slight delay when first loading the application on a mobile device, but
that's it.

In general, the average page size for most web sites is quite large now, so
the fact that EWB only requires two files (reduces latency), and is still
under 1MB, is quite good:

http://www.websiteoptimization.com/speed/tweak/average-web-page/

EWB 2 compresses form and interface data in addition to the JS code, so it
doesn't leave *anything* uncompressed.

If you find that you start to exceed a size threshold, you can also just
break up the application into smaller sub-applications.  EWB 2 also allows
you to load forms dynamically from the back-end web server, so that's an
option also, although I doubt that you would need to resort to it.

<< Implementing our own TDataSet for communicating with back end will be
hard? >>

You won't need to implement your own TDataSet just to talk to PostgresSQL.
You'll just simply use an ADO dataset that uses the PostgresSQL ODBC driver
to update the database, and the rest stays the same in the EWB client
application.

If you have any other questions, please let me know.

Tim Young
Elevate Software
www.elevatesoft.com

Matthew,

Thanks, it sounds interesting. What did you use as a backend?
--

Matthew Jones
Tiago Ameller
Menorca Zeros i Uns SL
www.sistemasc.net

Tim,

<<First of all, you should definitely try to use EWB 2 for this. >>
Sure, I'll check the demo

<< Do you think is a good combination? EWB rendered pages are ok for small
sizes? >>

Sorry I meant small *screen* sizes, but very interesting explanation about file sizes.
My worries about this project are about responsible screens (alternative is a lot of Bootstrap) and a server should be a hosted Linux.

In the case of having a Rails REST API serving JSON, how is made the TDataSet magic in EWD?

Thanks!


Tiago Ameller
Menorca Zeros i Uns SL
www.sistemasc.net

Tiago Ameller wrote:

> What did you use as a backend?

For the REST service, "it doesn't matter". That's the beauty of these
things, in that they are replaceable. But it was actually a C# system
running on Azure. I don't go for the direct database access, good
though the EWB solution is, as my solutions are not really "table"
based, even though there is of course database storage behind. My web
shop (you can play on dev.banxia.com) uses a RemObjects SDK based
Windows Service.

--

Matthew Jones

On 24/03/15 05:29, Tim Young [Elevate Software] wrote:
> First of all, you should definitely try to use EWB 2 for this.  It's
> just better, and more flexible than 1.x, especially in terms of layout
> capabilities, and that's only going to become more the case as EWB 2
> evolves.  This is important for mobile devices.
>

Tim. a couple of interesting and new aspects of EWB2 raised in your post!

> As long as you don't go nuts and add 40 forms to an application that's
> supposed to be used on mobile, you should be fine.  Basic EWB 2
> applications (just a few forms) weigh in at around 800k (compressed) for
> the HTML and JS file combined, but both of those will be cached by the
> browser and not re-downloaded unless they've been modified.   This means
> that you'll see a slight delay when first loading the application on a
> mobile device, but that's it.

800K is significantly larger than the compressed size of EWB1
applications. Anything we can do to reduce that a bit? I understand that
web page sizes have grown in general but for those of us on slow
connections every byte counts, even with caching.

I'm also wondering how much extra is added with each new form. EWB1
doesn't grow much with each form...is this different in EWB2? 40 forms
is probably excessive for a mobile site but would the difference between
a 5 form and 40 form EWB2 application be that much?

> If you find that you start to exceed a size threshold, you can also just
> break up the application into smaller sub-applications.  EWB 2 also
> allows you to load forms dynamically from the back-end web server, so
> that's an option also, although I doubt that you would need to resort to
> it.

Downloading forms dynamically sounds like a useful innovation. Is this
something that's flagged at the unit level and causes multiple JS files
to be created? Would this allow the browser to download multiple JS
files simultaneously?

--
Rick

Tiago,

<< Sorry I meant small *screen* sizes, but very interesting explanation
about file sizes. My worries about this project are about responsible
screens (alternative is a lot of Bootstrap) >>

EWB 2 is good with layouts, but needs a little bit of "nudging" in terms of
manual code to do "flow" layouts still.  IOW, you would still need to change
a couple of layout properties when you want different containers to stack
for mobile instead of being side-by-side on a tablet/desktop screen.  It's
not difficult, though.

<< and a server should be a hosted Linux. >>

This will be an issue for the default EWB Web Server, but not for EWB client
applications, in general.

<< In the case of having a Rails REST API serving JSON, how is made the
TDataSet magic in EWD? >>

In the case of a REST API, you probably won't use the TDataSet functionality
at all.  Instead, you would just send/receive the JSON using TServerRequest
instances and use the RTTI or custom parsing to handle getting it into/out
of object instances.

We do include a JSON parser with EWB, so you could use it to parse the JSON
manually and populate a TDataSet yourself, if you would want to do so.  It's
really up to you.  The code for how EWB does the JSON parsing is included
with the product, so you can see how we're doing it.

Tim Young
Elevate Software
www.elevatesoft.com

Rick,

<< 800K is significantly larger than the compressed size of EWB1
applications. >>

The 800k figure is an estimate with a "fudge factor" to account for
different forms.  Actual applications may be smaller or larger than that,
depending upon the identifiers used, etc.

For example, the HTML5 canvas TPaint example application is 373,820 bytes
compressed in EWB1 (HTML, JS, and CSS), and 507,712 bytes compressed in EWB2
(HTML and JS).

That difference is pretty insignificant, considering what EWB2 does up and
above EWB1.

<< Anything we can do to reduce that a bit? I understand that web page sizes
have grown in general but for those of us on slow connections every byte
counts, even with caching. >>

If you throw in "even with caching", then you've just eliminated the whole
issue.  If the application assets are being cached, which they will be, then
this caching means that the 2nd and subsequent times the application is run
on the computer/device will result in *zero* download time for the
application.

As for reducing the size, the only thing you can do is turn on compression
in the project's compiler options.  That's the only way to reduce the size
of the emitted application files.

<< I'm also wondering how much extra is added with each new form. EWB1
doesn't grow much with each form...is this different in EWB2? >>

It's slightly different.  There's about a 600-byte difference between the
two (EWB2 is bigger) with each successive form (compressed output).

<< 40 forms is probably excessive for a mobile site but would the difference
between a 5 form and 40 form EWB2 application be that much? >>

It's the same as with EWB1 - what matters is what's *on* the form, not just
the number of forms.  If you have 100 controls on a form, then the
application would be larger than if you had 10 controls on a form.

<< Downloading forms dynamically sounds like a useful innovation. Is this
something that's flagged at the unit level and causes multiple JS files to
be created? Would this allow the browser to download multiple JS files
simultaneously? >>

The forms are not JS files, they're JSON.  As for downloading
simultaneously, you're not really buying yourself anything by doing so,
especially with a slow connection.  If you want the fastest loading time,
then you will want the forms embedded with the application HTML like the
compiler emits them.  Dynamic forms are *not* compressed, whereas the forms
embedded in the HTML *are* compressed.  The key with a slow connection is
compression and reducing the number of requests to the server.  A default
EWB application results in two requests to the server, including the first
one for the HTML.  That's a very large decrease in the number of requests
compared to most web applications.

Tim Young
Elevate Software
www.elevatesoft.com

Rick,

Based upon our conversation here, I took some time yesterday to review the
EWB 2 compiler's "strip out the unused code" functionality in the emitter
portion of the compiler, and was able to improve upon it a bit more and trim
off some more application code weight.

The paint example now weighs in at 480,727 compressed with EWB 2, compared
to the 373,820 in EWB 1.  But, more importantly, I also discovered another
emitter optimization that can be done with the interface images that will
allow me to cut another ~50k (estimate) off of the size (the portion of the
480,727 bytes that is interfaces/forms is 178,739).

So, as it stands right now, there's only a 54,458-byte difference in emitted
code size (compressed) between EWB 2 and EWB 1 for the paint example.
That's pretty good, considering the amount of extra functionality in EWB 2.
It's also just a blip on the radar with a 4G mobile connection, and not much
worse for a 3G connection.

Tim Young
Elevate Software
www.elevatesoft.com