phpweather-devel

Re: Iconize weather info and something else

[Ray v. B. <r_v...@ho...>]

Kristian,

I've started doing some experiments with Javascript and php, but then I 
realized that I did things in the wrong order. It is important to know that 
php is executed first on the server, that results in a page that is 
'executed' in the browser. I think that this construction is of no use: the 
page loads only in the browser when the php script has received the metar 
data.

I reread Kristians suggestion and I think you mean this:

It should be possible to have a webpage (nr-1) that contains:
- a text 'Retrieving data...' with some id/name (dhtml-tag) in that
  part.
- some javascript. When this page has been loaded, the javascript
  executes. The javascript should then generate a new 'page' (nr-2).
  This nr-2 page contains php script that retrieves the metar data.
  The nr-2 page comes to the browser only when the metar data has
  been received and processed. The nr-2 page contains javascript
  (outputted by the php) that sets a javascript metar-variable.
- some other javascript that cyclicly tests metar-variable. Once
  set, it updates the 'Retrieving data...' text via the id/name tag
  and closes the nr-2 page. This same script can check for timeouts:
  When the page nr-2 does not come (while the php does not execute, or
  the noaa server cannot be found, or whatever), the nr-1 page cyclic
  javascript can terminate the second page and display something like
  'Metar data not found...'. I think that is what Martin meant.

Some Javascript questions though:
- is it possible to have two webpages (one started by the other) from
  which a Javascript can access data from the other?
- If inter-webpage communication via Javascript is not possible,
  maybe the same could be accomplished by frames in stead of pages?

I am willing to try this, but let me know if the above is correct...

Greetz,

Ray


_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp.

RE: Iconize weather info and something else

[Ray v. B. <r_v...@ho...>]

The problem with the loading part in the first part of the page and the 
reconstruction of the "Loading..." text is that the server does not return a 
page before the entire page is processed, at least that is what i see. Maybe 
with very large pages, the browser does not wait for the end and starts 
displaying before it has received the end.

Martin, you're right. Generating a new page from js which contains php is 
not parsed at the server but processed in the browser directly.

Ray


>From: "Max Hammond" <ma...@fl...>
>To: <php...@li...>
>Subject: RE: Iconize weather info and something else
>Date: Sun, 10 Feb 2002 10:02:08 -0000
>
>
>Another idea:
>
>some js at the top of the page that says "Loading..." that is sent before
>the metar load is started, and then some more at the bottom (ie, after the
>metar has been loaded and processed) that rewrites the document to just
>display the metar? I've no idea what kind of event handler you'd need to 
>get
>it to carry on :)
>
>Max
>
> > -----Original Message-----
> > From: php...@li...
> > [mailto:php...@li...]On Behalf Of Martin
> > Geisler
> > Sent: 10 February 2002 09:55
> > To: php...@li...
> > Subject: Re: Iconize weather info and something else
> >
> >
> > "Ray van Beek" <r_v...@ho...> writes:
> >
> > > - some javascript. When this page has been loaded, the javascript
> > > executes. The javascript should then generate a new 'page' (nr-2).
> > > This nr-2 page contains php script that retrieves the metar data.
> > > The nr-2 page comes to the browser only when the metar data has been
> > > received and processed. The nr-2 page contains javascript (outputted
> > > by the php) that sets a javascript metar-variable.
> >
> > I don't know very much about java(script), but I do know this:
> > java(script) runs on the client and PHP runs at the server. The client
> > will not be able to make a page nr-2 with come PHP code, as this code
> > is executed only at the server. So I think the step above would fail.
> >
> > But I've seen several pages that redirect you to another page after
> > 5-10 seconds. So we could make a page that says 'Retrieving data...',
> > and then after 5 seconds the user is redirected to a page that
> > displays the data. The first page should trigger the PHP code that
> > retrieves the data, so that the data is ready 5 seconds later.
> >
> > It's just that this would impose a 5 seconds-penalty to every report
> > shown, and it also makes the caching mechanisms useless.
> >
> > What we need is this: a way to update a page on the client at the
> > moment data arrives. I don't know if java(script) can be run
> > asynchronously in the background, so that the script could wait for
> > data in the background (the same way as the browser waits for data in
> > the foreground as it is now) and then update the right paragraph on
> > the page when the data has arrived.
> >
> > > [...]
> >
> > --
> > Martin Geisler                       My GnuPG Key: 0xF7F6B57B
> >
> > See my homepage at http://www.gimpster.com/ for:
> > PHP Weather => Shows the current weather on your webpage.
> > PHP Shell   => A telnet-connection (almost :-) in a PHP page.
> >
> > _______________________________________________
> > PHPWeather-devel mailing list
> > PHP...@li...
> > https://lists.sourceforge.net/lists/listinfo/phpweather-devel
> >
>
>
>_______________________________________________
>PHPWeather-devel mailing list
>PHP...@li...
>https://lists.sourceforge.net/lists/listinfo/phpweather-devel


_________________________________________________________________
Send and receive Hotmail on your mobile device: http://mobile.msn.com

Re: Iconize weather info and something else

[Martin G. <gim...@gi...>]

"Ray van Beek" <r_v...@ho...> writes:

> The problem with the loading part in the first part of the page and
> the reconstruction of the "Loading..." text is that the server does
> not return a page before the entire page is processed, at least that
> is what i see. Maybe with very large pages, the browser does not
> wait for the end and starts displaying before it has received the
> end.

I've actually got something working - take a look at

  http://www.gimpster.com/php/phpweather/demo2.php?sleep=5

The idea is this:

  o Instead of calling print_pretty_metar(), we call some other
    function. This function will write 'Please wait...' in a <span>
    tag with the id attribute set accordingly. The ICAO is saved in an
    array

  o We call flush() after writing 'Please wait...'. This will push the
    content from the server toward the client. This will (hopefully)
    make the browser start rendering the page, so that the user see
    the 'Please wait...' text. The browser wont start rendering the
    page, if it doesn't know the size of the box containing the
    'Please wait...' text.

  o At the very end of the page, we go through the stored ICAOs. For
    each stored ICAO, we retrieve the METAR, and retrieve the
    pretty-print.

  o We then write some JavaScript that will replace the text in the
    <span> tags inserted earlier in the text.

  o We call flush() again, so that the JavaScript is sent to the
    client, and so that the browser will execute it.

  o We repeat this process until we have made scripts for all the
    stored ICAOs.

It works in my browser (which is Mozilla 0.9.7).

What I've done is just a quick hack - we should probably restructure a
couple of things to implement this properly.

You can see the code here:

  http://www.gimpster.com/showsource.php?file=/php/phpweather/demo2.php

> Martin, you're right. Generating a new page from js which contains php
> is not parsed at the server but processed in the browser directly.

Right...

-- 
Martin Geisler                       My GnuPG Key: 0xF7F6B57B

See my homepage at http://www.gimpster.com/ for:
PHP Weather => Shows the current weather on your webpage.
PHP Shell   => A telnet-connection (almost :-) in a PHP page.

Re: Iconize weather info and something else

[Ray v. B. <r_v...@ho...>]

>I've actually got something working - take a look at
>
>   http://www.gimpster.com/php/phpweather/demo2.php?sleep=5
>
>The idea is this:
>
>   o Instead of calling print_pretty_metar(), we call some other
>     function. This function will write 'Please wait...' in a <span>
>     tag with the id attribute set accordingly. The ICAO is saved in an
>     array
>
>   o We call flush() after writing 'Please wait...'. This will push the
>     content from the server toward the client. This will (hopefully)
>     make the browser start rendering the page, so that the user see
>     the 'Please wait...' text. The browser wont start rendering the
>     page, if it doesn't know the size of the box containing the
>     'Please wait...' text.
>
>   o At the very end of the page, we go through the stored ICAOs. For
>     each stored ICAO, we retrieve the METAR, and retrieve the
>     pretty-print.
>
>   o We then write some JavaScript that will replace the text in the
>     <span> tags inserted earlier in the text.
>
>   o We call flush() again, so that the JavaScript is sent to the
>     client, and so that the browser will execute it.
>
>   o We repeat this process until we have made scripts for all the
>     stored ICAOs.
>
>It works in my browser (which is Mozilla 0.9.7).

It works for me too, IE5.0. Great!

One suggestion though, you flush the page each time the function 
wait_for_report is called. To me, it seems that that is only required once: 
immediately after the </html> tag. The page is then sent to the browser, and 
the browser can start processing a complete page.

Hmmm, while typing this, I'm not so sure anymore: doesn't the browser 
disconnect from the server when a complete page is received? If so, the 
remaining stuff (js with metar data) is not received anymore....

This is from your comment on my original post on icons:

>Well, there has been some people working on this, but I haven't
>received any code that solves the problem. The problem is (as I see
>it) that there isn't a field in the METAR that tells you if the
>weather is good or bad. You'll have to combine the information, and
>either select an appropriate image from a huge list of ready-made
>images, or perhaps generate the image on the fly using the GD library
>from within PHP.

I've been looking around on the internet. I downloaded several icon sets of 
which the single icons can be linked to metar-like data. Most of the icon 
sets concentrate on a combinatation of Sky Cover and Precipitation variants.
A few examples: sun, sun with one cloud, sun with a lot of cloads, cloads 
only, light and heavy rain with different sun/cloud combinations. 
Thunderstorms with different sun/cloud combinations.
Additionally, there are arrows pointing to different directions to indicate 
the wind direction.

What I would like to do in the coming days is creating a table that maps the 
different icon files to a Sky Cover/Precipitation combination table. A <IMG 
SRC=icon.php> construction in the webpage calls the icon.php function. This 
function then searches the table for the proper image file, that is then 
returned directly. To keep this mechanism 'tunable', the names of the icons 
files are entered in a include file. If someone likes to take his own set of 
icons, he only has to change the file names in the include file. As far as I 
can see it, the icon.php function can use the internal results of the 
phpweather script.

Like I said, I will start my first experiments probably this week, I keep 
you informed.

Bye for now,

Ray

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp.

RE: Iconize weather info and something else

[Max H. <ma...@fl...>]

> >I've actually got something working - take a look at
> >
> >   http://www.gimpster.com/php/phpweather/demo2.php?sleep=5
> >
> >The idea is this:

<snip>

That was exactly what I had in mind earlier :)

> One suggestion though, you flush the page each time the function
> wait_for_report is called. To me, it seems that that is only
> required once:
> immediately after the </html> tag. The page is then sent to the
> browser, and
> the browser can start processing a complete page.
>
> Hmmm, while typing this, I'm not so sure anymore: doesn't the browser
> disconnect from the server when a complete page is received? If so, the
> remaining stuff (js with metar data) is not received anymore....

No, flush() flushes the output buffer, it doesn't tear down the TCP
connection. I agree that it's only needed once, though, after the static
elements have been written.
But one thing: the <script> elements should be *within* the <html> element.
All the browsers I know will render a page before they receive the final
</html> anyway.

Did you all note that this won't work on windoze servers anyway?

I assume that the sleep() is just there so we can see what's going on?

Max

Re: Iconize weather info and something else

[Martin G. <gim...@gi...>]

"Max Hammond" <ma...@fl...> writes:

>> >I've actually got something working - take a look at
>> >
>> >   http://www.gimpster.com/php/phpweather/demo2.php?sleep=5
>> >
>> >The idea is this:
> 
> <snip>
> 
> That was exactly what I had in mind earlier :)

You're right - it was a good idea :-)
 
> But one thing: the <script> elements should be *within* the <html>
> element. All the browsers I know will render a page before they
> receive the final </html> anyway.

Yes, but the browser can only render the page if it knows the layout.
So I think we should be safe, if we output the javascript just before
the </html> tag.
 
> Did you all note that this won't work on windoze servers anyway?

Which part?
 
> I assume that the sleep() is just there so we can see what's going
> on?

Exactly.

-- 
Martin Geisler                       My GnuPG Key: 0xF7F6B57B

See my homepage at http://www.gimpster.com/ for:
PHP Weather => Shows the current weather on your webpage.
PHP Shell   => A telnet-connection (almost :-) in a PHP page.

RE: Iconize weather info and something else

[Max H. <ma...@fl...>]

> > But one thing: the <script> elements should be *within* the <html>
> > element. All the browsers I know will render a page before they
> > receive the final </html> anyway.
>
> Yes, but the browser can only render the page if it knows the layout.
> So I think we should be safe, if we output the javascript just before
> the </html> tag.

That's what I thought. After all, <script> is a sub-element of <html>...

> > Did you all note that this won't work on windoze servers anyway?
>
> Which part?

flush() won't.

http://www.php.net/manual/en/function.flush.php

<quote>
Several servers, especially on Win32, will still buffer the output from your
script until it terminates before transmitting the results to the browser.

Server modules for Apache like mod_gzip may do buffering of their own that
will cause flush() to not result in data being sent immediately to the
client.
</quote>

Max

Re: Iconize weather info and something else

[Martin G. <gim...@gi...>]

"Max Hammond" <ma...@fl...> writes:

>>> Did you all note that this won't work on windoze servers anyway?
>>
>> Which part?
> 
> flush() won't.

I see...

> http://www.php.net/manual/en/function.flush.php
> 
> <quote>
> Several servers, especially on Win32, will still buffer the output from your
> script until it terminates before transmitting the results to the browser.
> 
> Server modules for Apache like mod_gzip may do buffering of their own that
> will cause flush() to not result in data being sent immediately to the
> client.
> </quote>

Well, I think we'll just have to live with that... perhaps it would
help, if we produced a lot of whitespace as the page suggests.

We should also be careful not to send the JavaScript to people who use
older browsers - PHP has a function that can help with this
(get_browser()).

-- 
Martin Geisler                       My GnuPG Key: 0xF7F6B57B

See my homepage at http://www.gimpster.com/ for:
PHP Weather => Shows the current weather on your webpage.
PHP Shell   => A telnet-connection (almost :-) in a PHP page.

RE: Iconize weather info and something else

[Max H. <ma...@fl...>]

> We should also be careful not to send the JavaScript to people who use
> older browsers - PHP has a function that can help with this
> (get_browser()).

I'm not convinved that it's worth the bother. When 0.01% of people are using
browsers that won't understand this kind of javascript, it's probably not
worth it. 5 years ago, yes, you had to take into account the fact that a
good handful of people would be using netscape 2, but even then, we were
designing for the shiny new Netscape 3, with all it's advanced features.

There is a reason for doing a browser-detect though, or at least finding a
way around the problem: some people use screen readers, or parsers like
betsie to present easy-to-read versions of a page. They won't like
javascript.

Max

Re: Iconize weather info and something else

[Martin G. <gim...@gi...>]

"Max Hammond" <ma...@fl...> writes:

>> We should also be careful not to send the JavaScript to people who
>> use older browsers - PHP has a function that can help with this
>> (get_browser()).
> 
> I'm not convinved that it's worth the bother. When 0.01% of people
> are using browsers that won't understand this kind of javascript,
> it's probably not worth it. 5 years ago, yes, you had to take into
> account the fact that a good handful of people would be using
> netscape 2, but even then, we were designing for the shiny new
> Netscape 3, with all it's advanced features.

Yes, but people might have javascript turned off, even in their new
fancy browser. So, there should still be a way to get the normal
report.
 
> There is a reason for doing a browser-detect though, or at least
> finding a way around the problem: some people use screen readers, or
> parsers like betsie to present easy-to-read versions of a page. They
> won't like javascript.

I don't know betsie, but you're right: there has to be an option to
turn this javascript-thing off. And it would be preferable if the
script could try and guess when to turn if off.

-- 
Martin Geisler                       My GnuPG Key: 0xF7F6B57B

See my homepage at http://www.gimpster.com/ for:
PHP Weather => Shows the current weather on your webpage.
PHP Shell   => A telnet-connection (almost :-) in a PHP page.

RE: Iconize weather info and something else

[Max H. <ma...@fl...>]

> >> We should also be careful not to send the JavaScript to people who
> >> use older browsers - PHP has a function that can help with this
> >> (get_browser()).
> >
> > I'm not convinved that it's worth the bother. When 0.01% of people
> > are using browsers that won't understand this kind of javascript,
> > it's probably not worth it. 5 years ago, yes, you had to take into
> > account the fact that a good handful of people would be using
> > netscape 2, but even then, we were designing for the shiny new
> > Netscape 3, with all it's advanced features.
>
> Yes, but people might have javascript turned off, even in their new
> fancy browser. So, there should still be a way to get the normal
> report.
>
> > There is a reason for doing a browser-detect though, or at least
> > finding a way around the problem: some people use screen readers, or
> > parsers like betsie to present easy-to-read versions of a page. They
> > won't like javascript.
>
> I don't know betsie, but you're right: there has to be an option to
> turn this javascript-thing off. And it would be preferable if the
> script could try and guess when to turn if off.

get_browser() depends on browscap.ini being properly defined and kept up to
date, and won't help with people who've disabled js.  Since browscap does
not get installed by default with PHP, I think we're asking for trouble by
using it. Sure, give people an option, but I don't think we should be using
get_browser() at all. This is something for application designers to worry
about, whereas phpweather is a library rather than an application.

It would make more sense IMO to start building this kind of functionality
into the CVS tree. I think that a lot of what's in CVS is nearly ready for
release, so we should be concentrating on making a release out of it, rather
than tweaking the old stuff. The functions in CVS (eg browsing to the
airport of choice) are more at the application level than the current
releases.

Max

Re: Iconize weather info and something else

[Martin G. <gim...@gi...>]

"Max Hammond" <ma...@fl...> writes:

>> And it would be preferable if the script could try and guess when
>> to turn if off.
> 
> get_browser() depends on browscap.ini being properly defined and
> kept up to date, and won't help with people who've disabled js.
> Since browscap does not get installed by default with PHP, I think
> we're asking for trouble by using it.

You're right - I've actually never used get_browser(), it just seamed
like a nice builtin way of detecting the browsers capabilities - until
you pointed out that it isn't a default feature.

> Sure, give people an option, but I don't think we should be using
> get_browser() at all.

Agreed. Perhaps the easiest way of doing things would be to simply
write 'Please wait... (If you have disabled JavaScript or nothing
happens, click here)' where the last part is a link to the page with
the JavaScript-thing turned off.

> This is something for application designers to worry about, whereas
> phpweather is a library rather than an application.

Very true. I've had the exact same thought about PHP Weather: it
should be regarded as a library which people can use to build all
kinds of functionality on.

I did realise this when I made the first code, and that means that the
library-functionality is mixed with the application-level code. The
code in CVS is much more separated - the class metar_parser doesn't do
anything except parsing METARs.

But the class is still rather tightly coupled with other classes -
it's probably a mistake that it is a descendant of data_retrieval, as
metar_parser isn't an improved data-retriever - it's whole other
thing. PHP Weather is my first attempt at using objects, and I wanted
the hierarchy to end with class phpweather, so that people could do
something like this:

  $weather = new phpweather(array('icao' => 'EKYT'));
  $weather->print_pretty();

It still looks nice IMHO, but it can also be done without making
phpweather a descendant of metar_parser. 

The ideal situation would be, that the core of PHP Weather is
metar_parser. One should then be able to connect the metar_parser with
different output-modules, such as: localized textual output, numeric
output, WAP output, image output and so on.

> It would make more sense IMO to start building this kind of
> functionality into the CVS tree. I think that a lot of what's in CVS
> is nearly ready for release, so we should be concentrating on making
> a release out of it, rather than tweaking the old stuff. The
> functions in CVS (eg browsing to the airport of choice) are more at
> the application level than the current releases.

I agree - I've just been afraid to do the switch, as it seams that
people are very fond of the old version. It's probably a
chicken-and-egg problem: people doesn't switch to the new version
before it's almost complete, and I don't release the new version
before people start using it... :-)

So, let's work on getting a release of the new code, so that people
can stop using the old ugly code.

-- 
Martin Geisler                       My GnuPG Key: 0xF7F6B57B

See my homepage at http://www.gimpster.com/ for:
PHP Weather => Shows the current weather on your webpage.
PHP Shell   => A telnet-connection (almost :-) in a PHP page.

Re: Iconize weather info and something else

[Martin G. <gim...@gi...>]

"Ray van Beek" <r_v...@ho...> writes:

> It works for me too, IE5.0. Great!

Great - if it works in Mozilla and IE, then that will cover most of
the browsers people use. Someone should try with Opera too...

> One suggestion though, you flush the page each time the function
> wait_for_report is called. To me, it seems that that is only
> required once: immediately after the </html> tag. The page is then
> sent to the browser, and the browser can start processing a complete
> page.

I don't know if it's necessary to flush the page so often, but I
wanted to make sure, that the browser gets some data, so that it can
begin rendering the page.

I believe that I've read about a case, where they had to send several
empty lines to the browser before it "got the message" and started
rendering. But I haven't done any tests of things like that, so we'll
probably have to adjust this later.

> [...]
>
> What I would like to do in the coming days is creating a table that
> maps the different icon files to a Sky Cover/Precipitation
> combination table. A <IMG SRC=icon.php> construction in the webpage
> calls the icon.php function. This function then searches the table
> for the proper image file, that is then returned directly. To keep
> this mechanism 'tunable', the names of the icons files are entered
> in a include file. If someone likes to take his own set of icons, he
> only has to change the file names in the include file. As far as I
> can see it, the icon.php function can use the internal results of
> the phpweather script.

It sounds like a good approach, but how should it work, if people just
specify <IMG SRC="icon.php">? Don't you mean something like this <IMG
SRC="<?php weather_icon() ?>"> 
 
> Like I said, I will start my first experiments probably this week, I
> keep you informed.

Great. I think it would be a good idea to split this code out into
another file, so that people can include it if needed. The 'old' code
in PHP Weather really needs to be split up into several files, or even
better: we should move to the 'new' version in CVS and work on that.

It's been a long time since I've looked at the code, but as I remember
it, it does most of the things the 'old' code does, and it does it
better (more detailed, more special cases, etc...)

-- 
Martin Geisler                       My GnuPG Key: 0xF7F6B57B

See my homepage at http://www.gimpster.com/ for:
PHP Weather => Shows the current weather on your webpage.
PHP Shell   => A telnet-connection (almost :-) in a PHP page.

Re: Iconize weather info and something else

[Ray v. B. <r_v...@ho...>]

>Great - if it works in Mozilla and IE, then that will cover most of
>the browsers people use. Someone should try with Opera too...

Tried opera 6.0.1 on Win2k. The page loads, displaying the 'Retrieving...' 
text. After 5 secs, the status line says 'Done', but the page is not 
updated. When looking at the source, it shows the entire page, including the 
js. It seems that the js doesn't execute or doesn't execute properly, 
allthough no error message is issued...
I did some experiments with replacing text in an id-referenced tag. I use 
the innerHTML property, that worked also. Maybe for Opera as well.

Oh-oh, tried it on IE5.5 @ work. The screen stays blank until the entire 
page is received. It then shows the weather info right away. Is there a 
difference between IE5.0 and IE5.5 with respect to this matter?

Ray

_________________________________________________________________
Join the world’s largest e-mail service with MSN Hotmail. 
http://www.hotmail.com

Re: Iconize weather info and something else

[Ray v. B. <r_v...@ho...>]

>I did some experiments with replacing text in an id-referenced tag. I use 
>the innerHTML property, that worked also. Maybe for Opera as >well.

Forgot to tell that I did these experiments in my own test php script, and 
on IE5.0....

Ray


_________________________________________________________________
MSN Photos is the easiest way to share and print your photos: 
http://photos.msn.com/support/worldwide.aspx

Re: Iconize weather info and something else

[Martin G. <gim...@gi...>]

"Ray van Beek" <r_v...@ho...> writes:

> - some javascript. When this page has been loaded, the javascript
> executes. The javascript should then generate a new 'page' (nr-2).
> This nr-2 page contains php script that retrieves the metar data.
> The nr-2 page comes to the browser only when the metar data has been
> received and processed. The nr-2 page contains javascript (outputted
> by the php) that sets a javascript metar-variable.

I don't know very much about java(script), but I do know this:
java(script) runs on the client and PHP runs at the server. The client
will not be able to make a page nr-2 with come PHP code, as this code
is executed only at the server. So I think the step above would fail.

But I've seen several pages that redirect you to another page after
5-10 seconds. So we could make a page that says 'Retrieving data...',
and then after 5 seconds the user is redirected to a page that
displays the data. The first page should trigger the PHP code that
retrieves the data, so that the data is ready 5 seconds later.

It's just that this would impose a 5 seconds-penalty to every report
shown, and it also makes the caching mechanisms useless.

What we need is this: a way to update a page on the client at the
moment data arrives. I don't know if java(script) can be run
asynchronously in the background, so that the script could wait for
data in the background (the same way as the browser waits for data in
the foreground as it is now) and then update the right paragraph on
the page when the data has arrived. 

> [...]

-- 
Martin Geisler                       My GnuPG Key: 0xF7F6B57B

See my homepage at http://www.gimpster.com/ for:
PHP Weather => Shows the current weather on your webpage.
PHP Shell   => A telnet-connection (almost :-) in a PHP page.

RE: Iconize weather info and something else

[Max H. <ma...@fl...>]

Another idea:

some js at the top of the page that says "Loading..." that is sent before
the metar load is started, and then some more at the bottom (ie, after the
metar has been loaded and processed) that rewrites the document to just
display the metar? I've no idea what kind of event handler you'd need to get
it to carry on :)

Max

> -----Original Message-----
> From: php...@li...
> [mailto:php...@li...]On Behalf Of Martin
> Geisler
> Sent: 10 February 2002 09:55
> To: php...@li...
> Subject: Re: Iconize weather info and something else
>
>
> "Ray van Beek" <r_v...@ho...> writes:
>
> > - some javascript. When this page has been loaded, the javascript
> > executes. The javascript should then generate a new 'page' (nr-2).
> > This nr-2 page contains php script that retrieves the metar data.
> > The nr-2 page comes to the browser only when the metar data has been
> > received and processed. The nr-2 page contains javascript (outputted
> > by the php) that sets a javascript metar-variable.
>
> I don't know very much about java(script), but I do know this:
> java(script) runs on the client and PHP runs at the server. The client
> will not be able to make a page nr-2 with come PHP code, as this code
> is executed only at the server. So I think the step above would fail.
>
> But I've seen several pages that redirect you to another page after
> 5-10 seconds. So we could make a page that says 'Retrieving data...',
> and then after 5 seconds the user is redirected to a page that
> displays the data. The first page should trigger the PHP code that
> retrieves the data, so that the data is ready 5 seconds later.
>
> It's just that this would impose a 5 seconds-penalty to every report
> shown, and it also makes the caching mechanisms useless.
>
> What we need is this: a way to update a page on the client at the
> moment data arrives. I don't know if java(script) can be run
> asynchronously in the background, so that the script could wait for
> data in the background (the same way as the browser waits for data in
> the foreground as it is now) and then update the right paragraph on
> the page when the data has arrived.
>
> > [...]
>
> --
> Martin Geisler                       My GnuPG Key: 0xF7F6B57B
>
> See my homepage at http://www.gimpster.com/ for:
> PHP Weather => Shows the current weather on your webpage.
> PHP Shell   => A telnet-connection (almost :-) in a PHP page.
>
> _______________________________________________
> PHPWeather-devel mailing list
> PHP...@li...
> https://lists.sourceforge.net/lists/listinfo/phpweather-devel
>