|
|
| Re: Is there a way to distinguish an auto-refresh from a manual page load? [message #177117 is a reply to message #177114] |
Thu, 23 February 2012 00:27   |
Scott Johnson
Messages: 196
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
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.
|
|
|
|
| Re: Is there a way to distinguish an auto-refresh from a manual page load? [message #177118 is a reply to message #177114] |
Thu, 23 February 2012 03:49 |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
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(at)attglobal(dot)net
==================
|
|
|
|
| Re: Is there a way to distinguish an auto-refresh from a manual page load? [message #177152 is a reply to message #177114] |
Fri, 24 February 2012 12:40 |
alvaro.NOSPAMTHANX
Messages: 277
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
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
--
|
|
|
|
| Re: Is there a way to distinguish an auto-refresh from a manual page load? [message #177155 is a reply to message #177152] |
Fri, 24 February 2012 13:26 |
The Natural Philosoph
Messages: 993
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
Á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.
|
|
|
|
| Re: Is there a way to distinguish an auto-refresh from a manual page load? [message #177183 is a reply to message #177155] |
Sat, 25 February 2012 12:56 |
bill
Messages: 310
Registered: October 2010
Karma: 0
|
Senior Member |
|
|
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
|
|
|
|
| Re: Is there a way to distinguish an auto-refresh from a manual page load? [message #177189 is a reply to message #177183] |
Sat, 25 February 2012 17:21 |
Beauregard T. Shagnas
Messages: 154
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
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
|
|
|
|
| Re: Is there a way to distinguish an auto-refresh from a manual page load? [message #177192 is a reply to message #177189] |
Sun, 26 February 2012 08:31 |
crankypuss
Messages: 147
Registered: March 2011
Karma: 0
|
Senior Member |
|
|
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.
|
|
|
|
| Re: Is there a way to distinguish an auto-refresh from a manual page load? [message #177193 is a reply to message #177192] |
Sun, 26 February 2012 12:25 |
The Natural Philosoph
Messages: 993
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
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.
|
|
|
|
| Re: Is there a way to distinguish an auto-refresh from a manual page load? [message #177194 is a reply to message #177193] |
Sun, 26 February 2012 18:08 |
crankypuss
Messages: 147
Registered: March 2011
Karma: 0
|
Senior Member |
|
|
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.
|
|
|
|
| Re: Is there a way to distinguish an auto-refresh from a manual page load? [message #177195 is a reply to message #177194] |
Sun, 26 February 2012 18:40 |
J.O. Aho
Messages: 194
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
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
|
|
|
|
| Re: Is there a way to distinguish an auto-refresh from a manual page load? [message #177196 is a reply to message #177194] |
Sun, 26 February 2012 18:44 |
Peter H. Coffin
Messages: 245
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
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
|
|
|
|
| Re: Is there a way to distinguish an auto-refresh from a manual page load? [message #177198 is a reply to message #177195] |
Sun, 26 February 2012 20:06 |
crankypuss
Messages: 147
Registered: March 2011
Karma: 0
|
Senior Member |
|
|
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.
|
|
|
|
| Re: Is there a way to distinguish an auto-refresh from a manual page load? [message #177199 is a reply to message #177196] |
Sun, 26 February 2012 20:09 |
crankypuss
Messages: 147
Registered: March 2011
Karma: 0
|
Senior Member |
|
|
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.
|
|
|
|
| Re: Is there a way to distinguish an auto-refresh from a manual page load? [message #177200 is a reply to message #177198] |
Sun, 26 February 2012 21:12 |
The Natural Philosoph
Messages: 993
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
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...
|
|
|
|
| Re: Is there a way to distinguish an auto-refresh from a manual page load? [message #177201 is a reply to message #177199] |
Sun, 26 February 2012 21:14 |
The Natural Philosoph
Messages: 993
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
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?
|
|
|
|
| Re: Is there a way to distinguish an auto-refresh from a manual page load? [message #177203 is a reply to message #177155] |
Mon, 27 February 2012 09:22 |
alvaro.NOSPAMTHANX
Messages: 277
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
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
--
|
|
|
|
| Re: Is there a way to distinguish an auto-refresh from a manual page load? [message #177205 is a reply to message #177201] |
Mon, 27 February 2012 11:02 |
crankypuss
Messages: 147
Registered: March 2011
Karma: 0
|
Senior Member |
|
|
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.
|
|
|
|
| Re: Is there a way to distinguish an auto-refresh from a manual page load? [message #177206 is a reply to message #177203] |
Mon, 27 February 2012 12:00 |
The Natural Philosoph
Messages: 993
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
Á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.
>
>
|
|
|
|
| Re: Is there a way to distinguish an auto-refresh from a manual page load? [message #177207 is a reply to message #177206] |
Mon, 27 February 2012 13:08 |
alvaro.NOSPAMTHANX
Messages: 277
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
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
--
|
|
|
|
| Re: Is there a way to distinguish an auto-refresh from a manual page load? [message #177208 is a reply to message #177207] |
Mon, 27 February 2012 14:12 |
The Natural Philosoph
Messages: 993
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
Álvaro G. Vicario wrote:
> 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.
>
>
Oh, so what you are saying is that a POST operation generates a page
that has a redirect back to the page that produced the POST *request*
not the *result*, but then that *is* the page that if refreshed again
will POST again.. ;-0)
Or is it the other way around..bu that doesn't work either if you DO
want to post.
No. I think the answer lies in the manure heap of Javashite. Take
control of either the refresh process or the updating by another means
like websockets or Ajax.
|
|
|
|
| Re: Is there a way to distinguish an auto-refresh from a manual page load? [message #177209 is a reply to message #177208] |
Mon, 27 February 2012 16:18 |
alvaro.NOSPAMTHANX
Messages: 277
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
El 27/02/2012 15:12, The Natural Philosopher escribió/wrote:
>>> 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.
>>
>>
>
> Oh, so what you are saying is that a POST operation generates a page
> that has a redirect back to the page that produced the POST *request*
> not the *result*, but then that *is* the page that if refreshed again
> will POST again.. ;-0)
I'm just saying that:
1. A redirect always triggers a GET request.
2. It's _your_ page and _you_ control what URL is written into the
<meta> tag.
Honestly, I'm completely lost as about what's not clear so far.
--
-- 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
--
|
|
|
|
| Re: Is there a way to distinguish an auto-refresh from a manual page load? [message #177210 is a reply to message #177209] |
Mon, 27 February 2012 16:59 |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 2/27/2012 11:18 AM, "Álvaro G. Vicario" wrote:
> El 27/02/2012 15:12, The Natural Philosopher escribió/wrote:
>>>> 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.
>>>
>>>
>>
>> Oh, so what you are saying is that a POST operation generates a page
>> that has a redirect back to the page that produced the POST *request*
>> not the *result*, but then that *is* the page that if refreshed again
>> will POST again.. ;-0)
>
> I'm just saying that:
>
> 1. A redirect always triggers a GET request.
> 2. It's _your_ page and _you_ control what URL is written into the
> <meta> tag.
>
> Honestly, I'm completely lost as about what's not clear so far.
>
>
>
You forget who you're talking to, Álvaro.
How about taking this offline? It has nothing to do with PHP.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex(at)attglobal(dot)net
==================
|
|
|
|
Calendar
Search
Help
Members
Register
Login
Home
]