Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.php > #4931 > unrolled thread

Is there a way to distinguish an auto-refresh from a manual page load?

Back to article view | Back to comp.lang.php

Contents

  Is there a way to distinguish an auto-refresh from a manual page load? The Natural Philosopher <tnp@invalid.invalid> - 2012-02-22 22:26 +0000
    Re: Is there a way to distinguish an auto-refresh from a manual page load? Scott Johnson <noonehome@chalupasworld.com> - 2012-02-22 16:27 -0800
    Re: Is there a way to distinguish an auto-refresh from a manual page load? Jerry Stuckle <jstucklex@attglobal.net> - 2012-02-22 22:49 -0500
    Re: Is there a way to distinguish an auto-refresh from a manual page load? "Álvaro G. Vicario" <alvaro.NOSPAMTHANX@demogracia.com.invalid> - 2012-02-24 13:40 +0100
      Re: Is there a way to distinguish an auto-refresh from a manual page load? The Natural Philosopher <tnp@invalid.invalid> - 2012-02-24 13:26 +0000
        Re: Is there a way to distinguish an auto-refresh from a manual page load? bill <nobody@spamcop.net> - 2012-02-25 07:56 -0500
          Re: Is there a way to distinguish an auto-refresh from a manual page load? "Beauregard T. Shagnasty" <a.nony.mous@example.invalid> - 2012-02-25 17:21 +0000
            Re: Is there a way to distinguish an auto-refresh from a manual page load? crankypuss <no@email.thanks> - 2012-02-26 01:31 -0700
              Re: Is there a way to distinguish an auto-refresh from a manual page load? The Natural Philosopher <tnp@invalid.invalid> - 2012-02-26 12:25 +0000
                Re: Is there a way to distinguish an auto-refresh from a manual page load? crankypuss <no@email.thanks> - 2012-02-26 11:08 -0700
                  Re: Is there a way to distinguish an auto-refresh from a manual page   load? "J.O. Aho" <user@example.net> - 2012-02-26 19:40 +0100
                    Re: Is there a way to distinguish an auto-refresh from a manual page load? crankypuss <no@email.thanks> - 2012-02-26 13:06 -0700
                      Re: Is there a way to distinguish an auto-refresh from a manual page load? The Natural Philosopher <tnp@invalid.invalid> - 2012-02-26 21:12 +0000
                  Re: Is there a way to distinguish an auto-refresh from a manual page load? "Peter H. Coffin" <hellsop@ninehells.com> - 2012-02-26 12:44 -0600
                    Re: Is there a way to distinguish an auto-refresh from a manual page load? crankypuss <no@email.thanks> - 2012-02-26 13:09 -0700
                      Re: Is there a way to distinguish an auto-refresh from a manual page load? The Natural Philosopher <tnp@invalid.invalid> - 2012-02-26 21:14 +0000
                        Re: Is there a way to distinguish an auto-refresh from a manual page load? crankypuss <no@email.thanks> - 2012-02-27 04:02 -0700
        Re: Is there a way to distinguish an auto-refresh from a manual page load? "Álvaro G. Vicario" <alvaro.NOSPAMTHANX@demogracia.com.invalid> - 2012-02-27 10:22 +0100
          Re: Is there a way to distinguish an auto-refresh from a manual page load? The Natural Philosopher <tnp@invalid.invalid> - 2012-02-27 12:00 +0000
            Re: Is there a way to distinguish an auto-refresh from a manual page load? "Álvaro G. Vicario" <alvaro.NOSPAMTHANX@demogracia.com.invalid> - 2012-02-27 14:08 +0100
              Re: Is there a way to distinguish an auto-refresh from a manual page load? The Natural Philosopher <tnp@invalid.invalid> - 2012-02-27 14:12 +0000
                Re: Is there a way to distinguish an auto-refresh from a manual page load? "Álvaro G. Vicario" <alvaro.NOSPAMTHANX@demogracia.com.invalid> - 2012-02-27 17:18 +0100
                  Re: Is there a way to distinguish an auto-refresh from a manual page load? Jerry Stuckle <jstucklex@attglobal.net> - 2012-02-27 11:59 -0500

Page 1 of 2  [1] 2  Next page →

#4931 — Is there a way to distinguish an auto-refresh from a manual page load?

Cos I want to make a page  slightly different depending...
..I cant think of any parameter I might pass that would be affected by 
autorefersh or not tho.

Maybe javsacript and a timer would enable one?

Ideas?

[toc] | [next] | [standalone]

#4934

On 2/22/2012 2:26 PM, The Natural Philosopher wrote:
> Cos I want to make a page slightly different depending...
> ..I cant think of any parameter I might pass that would be affected by
> autorefersh or not tho.
>
> Maybe javsacript and a timer would enable one?
>
> Ideas?

I am pretty sure it can only be done in JS.

I played around with it some time back.

I think I used cookies with name and timestamps.
Was not fool-proof however.

Good Luck.

[toc] | [prev] | [next] | [standalone]

#4935

On 2/22/2012 5:26 PM, The Natural Philosopher wrote:
> Cos I want to make a page slightly different depending...
> ..I cant think of any parameter I might pass that would be affected by
> autorefersh or not tho.
>
> Maybe javsacript and a timer would enable one?
>
> Ideas?

Can't be done in PHP.  But then an out of work ditch digger wouldn't 
understand that.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#4970

El 22/02/2012 23:26, The Natural Philosopher escribió/wrote:
> Cos I want to make a page slightly different depending...
> ..I cant think of any parameter I might pass that would be affected by
> autorefersh or not tho.
>
> Maybe javsacript and a timer would enable one?

The "auto-refresh" concept implies some previous work on your side. It'd 
help a lot to know what's the code you wrote to accomplish it 
(JavaScript, <meta> tag or whatever). Whatever, I have the impression 
that it'd help even more to know the problem you want to fix rather than 
just the solution you figured out.


-- 
-- http://alvaro.es - Álvaro G. Vicario - Burgos, Spain
-- Mi sitio sobre programación web: http://borrame.com
-- Mi web de humor satinado: http://www.demogracia.com
--

[toc] | [prev] | [next] | [standalone]

#4973

Álvaro G. Vicario wrote:
> El 22/02/2012 23:26, The Natural Philosopher escribió/wrote:
>> Cos I want to make a page slightly different depending...
>> ..I cant think of any parameter I might pass that would be affected by
>> autorefersh or not tho.
>>
>> Maybe javsacript and a timer would enable one?
> 
> The "auto-refresh" concept implies some previous work on your side. It'd 
> help a lot to know what's the code you wrote to accomplish it 
> (JavaScript, <meta> tag or whatever). Whatever, I have the impression 
> that it'd help even more to know the problem you want to fix rather than 
> just the solution you figured out.
> 
> 
Well I used a meta tag so that the client refreshes in case new info has 
come in.

However in this case the client can also POST new information, and I 
don't want it POSTING the same information every 5 minutes or whatever.


The idea is to construct a not very real time view (5 minute granularity 
is good enough)  on some data, some of which the user can change.

I haven't tested it to see if a refresh is actually different from a 
submit.

[toc] | [prev] | [next] | [standalone]

#5001

On 2/24/2012 8:26 AM, The Natural Philosopher wrote:
> Álvaro G. Vicario wrote:
>> El 22/02/2012 23:26, The Natural Philosopher escribió/wrote:
>>> Cos I want to make a page slightly different depending...
>>> ..I cant think of any parameter I might pass that would be
>>> affected by
>>> autorefersh or not tho.
>>>
>>> Maybe javsacript and a timer would enable one?
>>
>> The "auto-refresh" concept implies some previous work on your
>> side. It'd help a lot to know what's the code you wrote to
>> accomplish it (JavaScript, <meta> tag or whatever). Whatever, I
>> have the impression that it'd help even more to know the
>> problem you want to fix rather than just the solution you
>> figured out.
>>
>>
> Well I used a meta tag so that the client refreshes in case new
> info has come in.
>
> However in this case the client can also POST new information,
> and I don't want it POSTING the same information every 5 minutes
> or whatever.
>
>
> The idea is to construct a not very real time view (5 minute
> granularity is good enough) on some data, some of which the user
> can change.
>
> I haven't tested it to see if a refresh is actually different
> from a submit.

UNTESTED:
On the original submit, attach a parameter with a random number. 
  Keep the sequence number in your database.  On every invocation 
of the php script, check the number in the database.  If it is 
the same as last time, it is a refresh.
bill

[toc] | [prev] | [next] | [standalone]

#5007

bill wrote:

> The Natural Philosopher wrote:
>> Álvaro G. Vicario wrote:
>>> The Natural Philosopher wrote:
>>>> Cos I want to make a page slightly different depending... ..I cant
>>>> think of any parameter I might pass that would be affected by
>>>> autorefersh or not tho.
>>>>
>>>> Maybe javsacript and a timer would enable one?
>>>
>>> The "auto-refresh" concept implies some previous work on your side.
>>> It'd help a lot to know what's the code you wrote to accomplish it
>>> (JavaScript, <meta> tag or whatever). Whatever, I have the impression
>>> that it'd help even more to know the problem you want to fix rather
>>> than just the solution you figured out.
>>
>> Well I used a meta tag so that the client refreshes in case new info
>> has come in.
>>
>> However in this case the client can also POST new information, and I
>> don't want it POSTING the same information every 5 minutes or whatever.
>>
>>
>> The idea is to construct a not very real time view (5 minute
>> granularity is good enough) on some data, some of which the user can
>> change.
>>
>> I haven't tested it to see if a refresh is actually different from a
>> submit.
> 
> UNTESTED:
> On the original submit, attach a parameter with a random number.
>   Keep the sequence number in your database.  On every invocation
> of the php script, check the number in the database.  If it is the same
> as last time, it is a refresh. bill

..unless another visitor views the page in between. This 'database' would 
have to also include at least the IP address and the random number, or 
perhaps the IP and the date/time and the random number to ever have a 
shot at being close.

-- 
   -bts
   -This space for rent, but the price is high

[toc] | [prev] | [next] | [standalone]

#5010

On 02/25/2012 10:21 AM, Beauregard T. Shagnasty wrote:
> bill wrote:
>
>> The Natural Philosopher wrote:
>>> Álvaro G. Vicario wrote:
>>>> The Natural Philosopher wrote:
>>>>> Cos I want to make a page slightly different depending... ..I cant
>>>>> think of any parameter I might pass that would be affected by
>>>>> autorefersh or not tho.
>>>>>
>>>>> Maybe javsacript and a timer would enable one?
>>>>
>>>> The "auto-refresh" concept implies some previous work on your side.
>>>> It'd help a lot to know what's the code you wrote to accomplish it
>>>> (JavaScript,<meta>  tag or whatever). Whatever, I have the impression
>>>> that it'd help even more to know the problem you want to fix rather
>>>> than just the solution you figured out.
>>>
>>> Well I used a meta tag so that the client refreshes in case new info
>>> has come in.
>>>
>>> However in this case the client can also POST new information, and I
>>> don't want it POSTING the same information every 5 minutes or whatever.
>>>
>>>
>>> The idea is to construct a not very real time view (5 minute
>>> granularity is good enough) on some data, some of which the user can
>>> change.
>>>
>>> I haven't tested it to see if a refresh is actually different from a
>>> submit.
>>
>> UNTESTED:
>> On the original submit, attach a parameter with a random number.
>>    Keep the sequence number in your database.  On every invocation
>> of the php script, check the number in the database.  If it is the same
>> as last time, it is a refresh. bill
>
> ..unless another visitor views the page in between. This 'database' would
> have to also include at least the IP address and the random number, or
> perhaps the IP and the date/time and the random number to ever have a
> shot at being close.

That's where the concept of a user session comes in handy.  I've been 
doing other things for some time now, but prior to that I was building a 
text editor and it was able to flawlessly detect re-sends of POST-ed 
information, etc.   The underlying code is doubtless more complex than 
most people would care to deal with, but it is possible.

[toc] | [prev] | [next] | [standalone]

#5011

crankypuss wrote:
> On 02/25/2012 10:21 AM, Beauregard T. Shagnasty wrote:
>> bill wrote:
>>
>>> The Natural Philosopher wrote:
>>>> Álvaro G. Vicario wrote:
>>>>> The Natural Philosopher wrote:
>>>>>> Cos I want to make a page slightly different depending... ..I cant
>>>>>> think of any parameter I might pass that would be affected by
>>>>>> autorefersh or not tho.
>>>>>>
>>>>>> Maybe javsacript and a timer would enable one?
>>>>>
>>>>> The "auto-refresh" concept implies some previous work on your side.
>>>>> It'd help a lot to know what's the code you wrote to accomplish it
>>>>> (JavaScript,<meta>  tag or whatever). Whatever, I have the impression
>>>>> that it'd help even more to know the problem you want to fix rather
>>>>> than just the solution you figured out.
>>>>
>>>> Well I used a meta tag so that the client refreshes in case new info
>>>> has come in.
>>>>
>>>> However in this case the client can also POST new information, and I
>>>> don't want it POSTING the same information every 5 minutes or whatever.
>>>>
>>>>
>>>> The idea is to construct a not very real time view (5 minute
>>>> granularity is good enough) on some data, some of which the user can
>>>> change.
>>>>
>>>> I haven't tested it to see if a refresh is actually different from a
>>>> submit.
>>>
>>> UNTESTED:
>>> On the original submit, attach a parameter with a random number.
>>>    Keep the sequence number in your database.  On every invocation
>>> of the php script, check the number in the database.  If it is the same
>>> as last time, it is a refresh. bill
>>
>> ..unless another visitor views the page in between. This 'database' would
>> have to also include at least the IP address and the random number, or
>> perhaps the IP and the date/time and the random number to ever have a
>> shot at being close.
> 
> That's where the concept of a user session comes in handy.  I've been 
> doing other things for some time now, but prior to that I was building a 
> text editor and it was able to flawlessly detect re-sends of POST-ed 
> information, etc.   The underlying code is doubtless more complex than 
> most people would care to deal with, but it is possible.

I haven't got around to testing this, but it has been interesting 
hearing deas - so thanks for all those.

It occurs to me if I do refresh under Javashite I can always hand set a 
variable to say 'ignore the post variables, if they happen to be set'

BUT I have to say I am attracted to playing with web sockets sim0ply 
because its new and a bit of a challenge. That avoids the need to 
refresh the page ...at all.

[toc] | [prev] | [next] | [standalone]

#5012

On 02/26/2012 05:25 AM, The Natural Philosopher wrote:
> crankypuss wrote:
>> On 02/25/2012 10:21 AM, Beauregard T. Shagnasty wrote:
>>> bill wrote:
>>>
>>>> The Natural Philosopher wrote:
>>>>> Álvaro G. Vicario wrote:
>>>>>> The Natural Philosopher wrote:
>>>>>>> Cos I want to make a page slightly different depending... ..I cant
>>>>>>> think of any parameter I might pass that would be affected by
>>>>>>> autorefersh or not tho.
>>>>>>>
>>>>>>> Maybe javsacript and a timer would enable one?
>>>>>>
>>>>>> The "auto-refresh" concept implies some previous work on your side.
>>>>>> It'd help a lot to know what's the code you wrote to accomplish it
>>>>>> (JavaScript,<meta> tag or whatever). Whatever, I have the impression
>>>>>> that it'd help even more to know the problem you want to fix rather
>>>>>> than just the solution you figured out.
>>>>>
>>>>> Well I used a meta tag so that the client refreshes in case new info
>>>>> has come in.
>>>>>
>>>>> However in this case the client can also POST new information, and I
>>>>> don't want it POSTING the same information every 5 minutes or
>>>>> whatever.
>>>>>
>>>>>
>>>>> The idea is to construct a not very real time view (5 minute
>>>>> granularity is good enough) on some data, some of which the user can
>>>>> change.
>>>>>
>>>>> I haven't tested it to see if a refresh is actually different from a
>>>>> submit.
>>>>
>>>> UNTESTED:
>>>> On the original submit, attach a parameter with a random number.
>>>> Keep the sequence number in your database. On every invocation
>>>> of the php script, check the number in the database. If it is the same
>>>> as last time, it is a refresh. bill
>>>
>>> ..unless another visitor views the page in between. This 'database'
>>> would
>>> have to also include at least the IP address and the random number, or
>>> perhaps the IP and the date/time and the random number to ever have a
>>> shot at being close.
>>
>> That's where the concept of a user session comes in handy. I've been
>> doing other things for some time now, but prior to that I was building
>> a text editor and it was able to flawlessly detect re-sends of POST-ed
>> information, etc. The underlying code is doubtless more complex than
>> most people would care to deal with, but it is possible.
>
> I haven't got around to testing this, but it has been interesting
> hearing deas - so thanks for all those.
>
> It occurs to me if I do refresh under Javashite I can always hand set a
> variable to say 'ignore the post variables, if they happen to be set'
>
> BUT I have to say I am attracted to playing with web sockets sim0ply
> because its new and a bit of a challenge. That avoids the need to
> refresh the page ...at all.

I've never been successful in digging around to find out how the few web 
pages I've seen are able to update the page without constant flickering 
and so on, it's my impression (*not* understanding, I lack that) that 
http is a client/server protocol and that once a request has been 
fulfilled the transaction is over.  I'm curious, but not compelled.

On the other hand I have been somewhat successful in creating the same 
appearance by using closely spaced refreshes, most browsers seem not to 
clear the screen prior to rendering so if the next is mostly the same as 
the last it appears to have been partially updated.

I'm not sure what you mean by "web sockets", I've used the kind of 
sockets provided by PHP but if you mean something else I've no clue what 
that might be.

[toc] | [prev] | [next] | [standalone]

#5013 — Re: Is there a way to distinguish an auto-refresh from a manual page load?

crankypuss wrote:
> On 02/26/2012 05:25 AM, The Natural Philosopher wrote:

>> It occurs to me if I do refresh under Javashite I can always hand set a
>> variable to say 'ignore the post variables, if they happen to be set'
>>
>> BUT I have to say I am attracted to playing with web sockets sim0ply
>> because its new and a bit of a challenge. That avoids the need to
>> refresh the page ...at all.
>
> I've never been successful in digging around to find out how the few web pages
> I've seen are able to update the page without constant flickering and so on,
> it's my impression (*not* understanding, I lack that) that http is a
> client/server protocol and that once a request has been fulfilled the
> transaction is over. I'm curious, but not compelled.

Ajax runs in the "background", making a request in intervals and update the 
correct section of the page when there is something to update, a simple way to 
see this is to use something like firebug and see what connections are made 
after the page has been loaded.



> On the other hand I have been somewhat successful in creating the same
> appearance by using closely spaced refreshes, most browsers seem not to clear
> the screen prior to rendering so if the next is mostly the same as the last it
> appears to have been partially updated.
>
> I'm not sure what you mean by "web sockets", I've used the kind of sockets
> provided by PHP but if you mean something else I've no clue what that might be.

Web sockets has been introduced with html 5 (and there are a few diffe3rent 
standards too), which allows the server to push content to the browser instead 
of using ajax which pulls information from the server.

-- 

   //Aho

[toc] | [prev] | [next] | [standalone]

#5016

On 02/26/2012 11:40 AM, J.O. Aho wrote:
> crankypuss wrote:
>> On 02/26/2012 05:25 AM, The Natural Philosopher wrote:
>
>>> It occurs to me if I do refresh under Javashite I can always hand set a
>>> variable to say 'ignore the post variables, if they happen to be set'
>>>
>>> BUT I have to say I am attracted to playing with web sockets sim0ply
>>> because its new and a bit of a challenge. That avoids the need to
>>> refresh the page ...at all.
>>
>> I've never been successful in digging around to find out how the few
>> web pages
>> I've seen are able to update the page without constant flickering and
>> so on,
>> it's my impression (*not* understanding, I lack that) that http is a
>> client/server protocol and that once a request has been fulfilled the
>> transaction is over. I'm curious, but not compelled.
>
> Ajax runs in the "background", making a request in intervals and update
> the correct section of the page when there is something to update, a
> simple way to see this is to use something like firebug and see what
> connections are made after the page has been loaded.

Ajax is client-side js, isn't it?  There's a lot that can be done if one 
is willing to assume that all users have enabled js.  Not all of it 
good, necessarily.  I tend toward the opposite extreme, assuming that js 
is disabled unless the user specifically tells me otherwise.

>> On the other hand I have been somewhat successful in creating the same
>> appearance by using closely spaced refreshes, most browsers seem not
>> to clear
>> the screen prior to rendering so if the next is mostly the same as the
>> last it
>> appears to have been partially updated.
>>
>> I'm not sure what you mean by "web sockets", I've used the kind of
>> sockets
>> provided by PHP but if you mean something else I've no clue what that
>> might be.
>
> Web sockets has been introduced with html 5 (and there are a few
> diffe3rent standards too), which allows the server to push content to
> the browser instead of using ajax which pulls information from the server.

I will studiously avoid this, then; the redeeming graces of html are few 
enough already... I really don't care a whit about conforming to the 
expectations of html conformance freaks, as far as I'm concerned a 
browser is simply a remote rendering device and document source format 
is relevant only insofar that it determines semantics as related to the 
remote rendering device.  It seems impossible to be a purist and an 
html-purist at the same time.  Push is like Jehovah's Witnesses banging 
on the door and should similarly be shot or hanged or simply beaten and 
sent on its way, whichever is more convenient.

[toc] | [prev] | [next] | [standalone]

#5018

crankypuss wrote:
> On 02/26/2012 11:40 AM, J.O. Aho wrote:

>>
>> Web sockets has been introduced with html 5 (and there are a few
>> diffe3rent standards too), which allows the server to push content to
>> the browser instead of using ajax which pulls information from the 
>> server.
> 
> I will studiously avoid this, then; the redeeming graces of html are few 
> enough already... I really don't care a whit about conforming to the 
> expectations of html conformance freaks, as far as I'm concerned a 
> browser is simply a remote rendering device 


Well' that's your view. I see it as a fairly ubiquitous fairly thick 
client  for wep Apps. I am just as interested in it in intranets as on 
the internet.

websockets and javascript are part  of that - and in an intranet 
situation you can insist on a single browser.

and document source format
> is relevant only insofar that it determines semantics as related to the 
> remote rendering device.  It seems impossible to be a purist and an 
> html-purist at the same time.  Push is like Jehovah's Witnesses banging 
> on the door and should similarly be shot or hanged or simply beaten and 
> sent on its way, whichever is more convenient.

Websockets are really nothing more than a persistent two way comms 
channel. I'd guess only of relevance with Javashite (TM) as well.
BUT its a better use of bandwidth to push changes down the channel when 
they happen, rather than constantly polL.

It might save my bandwidth when my wife leaves the weather radar live 
on overnight...

[toc] | [prev] | [next] | [standalone]

#5014

On Sun, 26 Feb 2012 11:08:25 -0700, crankypuss wrote:

> I've never been successful in digging around to find out how the few
> web pages I've seen are able to update the page without constant
> flickering and so on, it's my impression (*not* understanding, I lack
> that) that http is a client/server protocol and that once a request
> has been fulfilled the transaction is over. I'm curious, but not
> compelled.
>
> On the other hand I have been somewhat successful in creating the same
> appearance by using closely spaced refreshes, most browsers seem not
> to clear the screen prior to rendering so if the next is mostly the
> same as the last it appears to have been partially updated.
>
> I'm not sure what you mean by "web sockets", I've used the kind of
> sockets provided by PHP but if you mean something else I've no clue
> what that might be.

javascript does not shut down just because the page is finished
loading. The javascript makes a background request to a specialize "not
generating a web page, just feeding data" script on the server, then
updates its own document (that is, the rendered page) based on the new
data it receives.

-- 
For every subject you can think of there are at least 3 web sites.
The owners of these web sites know each other and at least one of
them hates at least one of the others.
                -- mnlooney's view of Skif's Internet Theorem

[toc] | [prev] | [next] | [standalone]

#5017

On 02/26/2012 11:44 AM, Peter H. Coffin wrote:
> On Sun, 26 Feb 2012 11:08:25 -0700, crankypuss wrote:
>
>> I've never been successful in digging around to find out how the few
>> web pages I've seen are able to update the page without constant
>> flickering and so on, it's my impression (*not* understanding, I lack
>> that) that http is a client/server protocol and that once a request
>> has been fulfilled the transaction is over. I'm curious, but not
>> compelled.
>>
>> On the other hand I have been somewhat successful in creating the same
>> appearance by using closely spaced refreshes, most browsers seem not
>> to clear the screen prior to rendering so if the next is mostly the
>> same as the last it appears to have been partially updated.
>>
>> I'm not sure what you mean by "web sockets", I've used the kind of
>> sockets provided by PHP but if you mean something else I've no clue
>> what that might be.
>
> javascript does not shut down just because the page is finished
> loading. The javascript makes a background request to a specialize "not
> generating a web page, just feeding data" script on the server, then
> updates its own document (that is, the rendered page) based on the new
> data it receives.

Pretty tough to implement when the user has chosen to disable js, but 
then I assume that one of the items on the agenda of those in control is 
to remove that choice from the idiot non-purchasing user's hands while 
working toward stealing from him if he is unwilling to give.

[toc] | [prev] | [next] | [standalone]

#5019

crankypuss wrote:
> On 02/26/2012 11:44 AM, Peter H. Coffin wrote:
>> On Sun, 26 Feb 2012 11:08:25 -0700, crankypuss wrote:
>>
>>> I've never been successful in digging around to find out how the few
>>> web pages I've seen are able to update the page without constant
>>> flickering and so on, it's my impression (*not* understanding, I lack
>>> that) that http is a client/server protocol and that once a request
>>> has been fulfilled the transaction is over. I'm curious, but not
>>> compelled.
>>>
>>> On the other hand I have been somewhat successful in creating the same
>>> appearance by using closely spaced refreshes, most browsers seem not
>>> to clear the screen prior to rendering so if the next is mostly the
>>> same as the last it appears to have been partially updated.
>>>
>>> I'm not sure what you mean by "web sockets", I've used the kind of
>>> sockets provided by PHP but if you mean something else I've no clue
>>> what that might be.
>>
>> javascript does not shut down just because the page is finished
>> loading. The javascript makes a background request to a specialize "not
>> generating a web page, just feeding data" script on the server, then
>> updates its own document (that is, the rendered page) based on the new
>> data it receives.
> 
> Pretty tough to implement when the user has chosen to disable js, but 
> then I assume that one of the items on the agenda of those in control is 
> to remove that choice from the idiot non-purchasing user's hands while 
> working toward stealing from him if he is unwilling to give.

What are you on?

This absolutely incredible and stupid assumption that the only thing PHP 
and web browsers are for is world wide marketing and information 
dissemination?

Some of us are trying to write platform independent apps...for internal use.

Are we not allowed to use PHP?

[toc] | [prev] | [next] | [standalone]

#5024

On 02/26/2012 02:14 PM, The Natural Philosopher wrote:
> crankypuss wrote:
>> On 02/26/2012 11:44 AM, Peter H. Coffin wrote:
>>> On Sun, 26 Feb 2012 11:08:25 -0700, crankypuss wrote:
>>>
>>>> I've never been successful in digging around to find out how the few
>>>> web pages I've seen are able to update the page without constant
>>>> flickering and so on, it's my impression (*not* understanding, I lack
>>>> that) that http is a client/server protocol and that once a request
>>>> has been fulfilled the transaction is over. I'm curious, but not
>>>> compelled.
>>>>
>>>> On the other hand I have been somewhat successful in creating the same
>>>> appearance by using closely spaced refreshes, most browsers seem not
>>>> to clear the screen prior to rendering so if the next is mostly the
>>>> same as the last it appears to have been partially updated.
>>>>
>>>> I'm not sure what you mean by "web sockets", I've used the kind of
>>>> sockets provided by PHP but if you mean something else I've no clue
>>>> what that might be.
>>>
>>> javascript does not shut down just because the page is finished
>>> loading. The javascript makes a background request to a specialize "not
>>> generating a web page, just feeding data" script on the server, then
>>> updates its own document (that is, the rendered page) based on the new
>>> data it receives.
>>
>> Pretty tough to implement when the user has chosen to disable js, but
>> then I assume that one of the items on the agenda of those in control
>> is to remove that choice from the idiot non-purchasing user's hands
>> while working toward stealing from him if he is unwilling to give.
>
> What are you on?
>
> This absolutely incredible and stupid assumption that the only thing PHP
> and web browsers are for is world wide marketing and information
> dissemination?
>
> Some of us are trying to write platform independent apps...for internal
> use.
>
> Are we not allowed to use PHP?

Do what you want, by all means.  I'm not sure where you got the idea 
that stating my views was some attempt to force them upon you.

In fact my main interest at the moment is not web development per-se, 
but rather the use of PHP within a browser within the context of a 
single user's system.  In other words, using PHP to generate the html 
that makes the browser work as a computer control panel, a 
window-manager shell that is the user's primary interface.

PHP is for what it can be used for.  It's isn't the best language ever 
invented or the worst.  But it is fairly widely known, it is good at 
generating html, and html is something that browsers are good at 
rendering, a lowest common denominator that is system-independent and 
fairly easy to work with.

Initially my development efforts were limited to a website, then they 
have moved to a local apache sever, and the next step is to find a 
suitable browser and modify it so that it runs PHP independently of any 
networking while simultaneously writing a separate code layer that 
produces equivalent results through ncurses.  It's a fun project.

[toc] | [prev] | [next] | [standalone]

#5021

El 24/02/2012 14:26, The Natural Philosopher escribió/wrote:
> Álvaro G. Vicario wrote:
>> El 22/02/2012 23:26, The Natural Philosopher escribió/wrote:
>>> Cos I want to make a page slightly different depending...
>>> ..I cant think of any parameter I might pass that would be affected by
>>> autorefersh or not tho.
>>>
>>> Maybe javsacript and a timer would enable one?
>>
>> The "auto-refresh" concept implies some previous work on your side.
>> It'd help a lot to know what's the code you wrote to accomplish it
>> (JavaScript, <meta> tag or whatever). Whatever, I have the impression
>> that it'd help even more to know the problem you want to fix rather
>> than just the solution you figured out.
>>
>>
> Well I used a meta tag so that the client refreshes in case new info has
> come in.
>
> However in this case the client can also POST new information, and I
> don't want it POSTING the same information every 5 minutes or whatever.

Then, it should be enough to use two different URLs, one of the <meta> 
tag and one for the action attribute in the form. Even if they actually 
point to the same file, the browser has no way to know.

> The idea is to construct a not very real time view (5 minute granularity
> is good enough) on some data, some of which the user can change.

Well, that's the prototypical use case for AJAX :)

> I haven't tested it to see if a refresh is actually different from a
> submit.

Oh, I thought you had. If the <meta> tag does not use POST, you don't 
have the problem in the first place.



-- 
-- http://alvaro.es - Álvaro G. Vicario - Burgos, Spain
-- Mi sitio sobre programación web: http://borrame.com
-- Mi web de humor satinado: http://www.demogracia.com
--

[toc] | [prev] | [next] | [standalone]

#5025

Álvaro G. Vicario wrote:
> El 24/02/2012 14:26, The Natural Philosopher escribió/wrote:
>> Álvaro G. Vicario wrote:
>>> El 22/02/2012 23:26, The Natural Philosopher escribió/wrote:
>>>> Cos I want to make a page slightly different depending...
>>>> ..I cant think of any parameter I might pass that would be affected by
>>>> autorefersh or not tho.
>>>>
>>>> Maybe javsacript and a timer would enable one?
>>>
>>> The "auto-refresh" concept implies some previous work on your side.
>>> It'd help a lot to know what's the code you wrote to accomplish it
>>> (JavaScript, <meta> tag or whatever). Whatever, I have the impression
>>> that it'd help even more to know the problem you want to fix rather
>>> than just the solution you figured out.
>>>
>>>
>> Well I used a meta tag so that the client refreshes in case new info has
>> come in.
>>
>> However in this case the client can also POST new information, and I
>> don't want it POSTING the same information every 5 minutes or whatever.
> 
> Then, it should be enough to use two different URLs, one of the <meta> 
> tag and one for the action attribute in the form. Even if they actually 
> point to the same file, the browser has no way to know.
> 

Well that is the problem isn't it? The browser cannot KNOW. If I POST a 
form to mypostingtarget.php and THAT comes back with a 'meta refresh' 
statement THAT is the target that is going to be refreshed?.

I think there is no way out of it at the meta refresh level. The browser 
cant know.

Only if you embed the refresh action within javascript, where you can 
make the refresh action different from a form post.



>> The idea is to construct a not very real time view (5 minute granularity
>> is good enough) on some data, some of which the user can change.
> 
> Well, that's the prototypical use case for AJAX :)
> 

Yes.. but I have a bit of an instinctive dislike for Ajax..it seems to 
be a hack to me, and if I am going that route I might as well use web 
sockets. Which is designed to do this sort of thing. And do it better 
than Ajax would,.


>> I haven't tested it to see if a refresh is actually different from a
>> submit.
> 
> Oh, I thought you had. If the <meta> tag does not use POST, you don't 
> have the problem in the first place.
> 

well yes.

> 
> 

[toc] | [prev] | [next] | [standalone]

#5026

El 27/02/2012 13:00, The Natural Philosopher escribió/wrote:
>>> Well I used a meta tag so that the client refreshes in case new info has
>>> come in.
>>>
>>> However in this case the client can also POST new information, and I
>>> don't want it POSTING the same information every 5 minutes or whatever.
>>
>> Then, it should be enough to use two different URLs, one of the <meta>
>> tag and one for the action attribute in the form. Even if they
>> actually point to the same file, the browser has no way to know.
>>
>
> Well that is the problem isn't it? The browser cannot KNOW. If I POST a
> form to mypostingtarget.php and THAT comes back with a 'meta refresh'
> statement THAT is the target that is going to be refreshed?.

Okay, I think I finally see what the problem is.

The complete syntax for a <meta> direct is this:

https://developer.mozilla.org/en/HTML/Element/meta#attr-http-equiv

In the "refresh" bit we can read:

«This pragma specifies:

- the number of seconds until the page should be reloaded, if the 
content attribute contains only a positive integer number;

- the number of seconds until the page should be redirected to another, 
if the content attribute contains a positive integer number followed by 
the string ';url=' and a valid URL.»

I guess you are using the first feature ("reload") and I thought you 
were using the second one ("redirect"). Just tweak your PHP code to 
generate a <meta> tag with the ";url=" part.



-- 
-- http://alvaro.es - Álvaro G. Vicario - Burgos, Spain
-- Mi sitio sobre programación web: http://borrame.com
-- Mi web de humor satinado: http://www.demogracia.com
--

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.php

csiph-web