The following thought popped into my mind..

Tim adds an option to display a server-side holding page with an
animation...
A little gymnast, in Elevate colors, performing a round-off, several
back flips, leading into a back double somersault landing in the splits!
Might bring tears of pain to the gymnast (Tim) but of joy to the users.
Users would not notice the time passing.

On second thoughts this may be a BAD idea - Tim could decide to extend
the download times in order to get more coverage!  <bg>

Raul wrote:

> Simple loader page should help in this case - for example something

I don't understand why the application page can't be used for this. I
just did a check in Chrome to see the network times for my shop admin.
The initial page is under 200ms, and then it starts loading the
javascript. For my 700,000 byte application, it takes 362ms (over the
internet). But the page is sitting there being blank. That's where you
could put the "please wait while the page loads". The only problem I
can see is that adding other content to the page might cause the EWB
application to not have the DOM it expects, but that could be easily
fixed by putting it in a div or something that the EWB code deletes
when it is run.

Tim, is there any restriction on what can be put in the initial HTML
page? Could a spinner be put there for slow connection use?

--

Matthew Jones

Matthew

It is not a big deal for me, but ..

I am not seeing what you report.
When I click my website link for my EWB app, nothing changes while the
app downloads.
Then the application page displays and my form comes up so fast that I
can only see a flicker if I show the load progress.
So I don't think adding something to the initial HTML page would help
me .. unless I misunderstand.

So that is why I was thinking about using a server-side spinner or
message.

Malcolm wrote:

> I am not seeing what you report.

Okay, I was going to say go into Chrome and watch the timeline, but I
thought I'd check that myself first, and telling it to throttle to a 2G
signal speed, I see that the HTML page arrives, but it isn't rendered
which is a pity, and breaks my suggestion. Oh dear!

Okay, looked into it more, and the new EWB2 HTML is heavily scripted
already, and includes the progress dialog even if I turn it off. I
wonder if there is a way to have the first javascript update the DOM
before it then loads the rest, as that would satisfy this requirement.

Hmm, and my EWB1 version also doesn't display even on the first load,
so maybe it is Chrome that changed. Pity.

Okay, this is getting beyond my knowledge, but the onload of the page
is referencing a [pagename]_load() function, which is in the .js file.
Thus I guess the browser is thinking it can't do anything until it has
that, so it waits. The question I then have is whether, given there is
a load of script in the .html now, the onload for the page can call a
small stub script which updates the visible browser, and then calls the
..js load function. I'd have to go googling a lot to learn about that,
but it seems the ideal for everyone. In the meantime, a page that
redirects (I'd do it immediately, no need to wait any seconds) is an
available cure.

--

Matthew Jones

On 10/30/2015 5:43 AM, Matthew Jones wrote:
> I don't understand why the application page can't be used for this. I

AFAIK currently the JS is needs to be fully loaded before browser can do
anything so i don't believe normal html page can do anything until that
happens.

It's a chicken and egg problem in general - until you get the JS you
don't know what you're "really" supposed to show (from browsers POV).

Raul

On 10/30/2015 7:28 AM, Matthew Jones wrote:

> Okay, this is getting beyond my knowledge, but the onload of the page
> is referencing a [pagename]_load() function, which is in the .js file.
> Thus I guess the browser is thinking it can't do anything until it has
> that, so it waits. The question I then have is whether, given there is
> a load of script in the .html now, the onload for the page can call a
> small stub script which updates the visible browser, and then calls the
> .js load function.

The issue with loading scripts "later" is that while JS can be loaded
runtime wiring things back together with DOM gets trickier now since DOM
is not necessarily in "known place" anymore (initial state).

> In the meantime, a page that
> redirects (I'd do it immediately, no need to wait any seconds) is an
> available cure.

Extension of basic loader page is to have a loader page loads the EWB
app JS file runtime (but not use it) and then redirect to actual EWB app
in which case JS is already in local cache so nothing needs to be
downloaded.

Again for most of us it's not a real problem though - fast internet and
desktop browser (2g and/or mobile would be another story for larger files )

Raul

I am thinking that instead of my <a href="MyEWBApp.html" ......
I will have <a href="SmellTheCoffee.php" ......

SmellTheCoffee.php will include:
<?php  header("Location: MyEWBApp.html");  ?>
... and have a message or spinner or whatever in its body to be
displayed until the browser is able to display MyEWBApp.html.

Not tested .. but should be close.. maybe.  

No doubt there will be more elegant solutions like a server-side java
popup.

Raul wrote:

> AFAIK currently the JS is needs to be fully loaded before browser can
> do anything

Which is why I wonder if it is possible for the javascript to be
embedded (as some is) and then somehow (that's where Tim does magic) it
loads the other parts. Why is everyone looking at me like that? 8-)

--

Matthew Jones

Nah, that won't work.
PHP's Location:  must come before any other output.
Defeats the purpose.  

Matthew,

<< Which is why I wonder if it is possible for the javascript to be embedded (as some is) and then somehow (that's where Tim does magic) it loads the other parts. Why is everyone looking at me like that? 8-) >>

What needs to occur is this:

1) The HTML loader file does *not* directly call the load_xxxx function for the app's .JS file.

2) Instead, it has some embedded JS on the page that does some low-level "show progress", etc. and dynamically loads the app's .JS file into the HTML.  It then waits on a successful load, and if so, proceeds from there.

Now, the problems with this approach:

1) Flicker - the "loading" code will have to be smart enough to not show anything on the page unless x number of milliseconds have expired, i.e. a timeout.

2) Any "show progress" elements will have to get "erased" before the EWB load_xxxx function is called.

3) ??????  I can't think of anything else, can you ?

Tim Young
Elevate Software
www.elevatesoft.com