Re: Dynamically modify query string in auto-refresh request URL?
Chris Beall
> Everything goes in cycles, they say, and I wonder if perhaps it's time
> to revive the Refresh header, to give it a new place in Web2.0
> operations.
>
> That would work well for one of my sites IFF some user/visitor state
> could be sent with the browser's automatic-refresh GET request, the one
> that's issued as it periodically honors the page's Refresh header.
>
> Imagine for a moment that AJAX does not exist. Then:
> Consider a site http://www.all-the-headlines.com/. It serves a web page
> full of headlines from three newspapers. These headlines are literally
> current to the minute because the page carries a Refresh header, perhaps
> instigated by:
>
> <meta http-equiv="refresh"
> content="60;url=http://www.all-the-headlines.com?source=nytimes,wallstjournal,washingtonpost">
>
> in the page's <head> section. The effect of the header is that every 60
> seconds the browser automatically, on its own, issues a GET request with
> a query string that I assume (haven't found an example yet) must look
> something like:
>
> source=nytimes,wallstjournal,washingtonpost
>
> Now imagine that a user is tired of seeing Wall Street Journal
> headlines, and he says so by clearing a checkbox on the page.
>
> Script on the page now wants to modify browser's GET-request query
> string such that, instead of
>
> source=nytimes,wallstjournal,washingtonpost
>
> it becomes
>
> source=nytimes,washingtonpost
>
>
> Question: What's a way for the script to change the query string so that
> it reflects the user's new preferences?
>
> Thanks!
Pete,
You said to assume that AJAX does not exist. OK. But AJAX is just a
mashup of several technologies, so I'm also going to assume that HTML and
JavaScript are still available.
The refresh is part of a META element.
That element appears in the DOM, which can be accessed by JavaScript.
Within the element, the url= attribute carries the data you want to
modify. In the DOM, that's a separate node named 'url'. You want to
modify the content of that node.
Documentation on using JavaScipt to modify the DOM in a way that works
cross-browser is scanty. (I would be delighted to be corrected by
someone). In essence, you have to find the node you want to modify and
then change its content.
What isn't clear is WHEN the browser picks up that content. Ideally, it
would be at the end of the current 60-second interval, so the new set of
sources would show up at the next refresh. It is theoretically possible,
however, that the browser picks up the url value when it initially reads
the META statement. In that case, it will use the unmodified version of
the url on the next refresh, ignoring (and overlaying) the change you just
made. The only way I know of to find out is to test it.
Hmmm, I see another issue. Your server initially serves up a page with a
version of the meta refresh that lists all three news sources. Now the
user unchecks a box and you update the url (actually changing just the
query string) in the meta element. Let's assume the browser picks this up
at the instant the refresh interval expires so the new query string is
sent to the server. Now, to keep from getting things out of sync, the
server has to serve a new page that:
- Updates the content of the two remaining news sources, leaving the
space occupied by the third one blank.
- Preserves the UNchecked state of the news source that was deselected.
- Builds a meta refresh element that includes only the two remaining
sources in the query string.
And it has to be able to reverse this if the user checks the box again.
So the server has to have some smarts specific to your application.
Other thoughts:
Your functional requirements sound a lot like the description of what
RSS does. I've never used it.
Suppose your page had an iframe for each news source. Checking and
unchecking boxes would modify the style of those iframes to be display:
none or not. The data from all three sources would still be fetched, but
only the desired data would be visible.
All of this is off-topic for an HTML group. I'd suggest
comp.infosystems.www.authoring.site-design as a better place. I've
attempted to cross-post this and set followups there, but I've never done
that before, so I may have fumbled it.
Chris Beall
Chris Beall
Pete,
then change its content. If you already knew all that and wanted details,
post back and I'll see if I can cobble something together.
pete
> On Mon, 25 Apr 2011 14:57:48 -0400, pete
Yes, HTML, and JavaScript, and CGI (the smarts you mention below) all exist.
> The refresh is part of a META element.
> That element appears in the DOM, which can be accessed by JavaScript.
> Within the element, the url= attribute carries the data you want to
> modify. In the DOM, that's a separate node named 'url'. You want to
> modify the content of that node.
Eureka!
Chris, I can't thank you enough for your generous and thoughtful reply. It was way beyond any of my reasonable hopes: I expected no reply at all, in fact, so it's a huge treat to read.
The actual page shows the user a bunch of current, up-to-the-10-second-interval stock-option data collected by C-language CGI. That program is seeing, parsing, and storing a stream of such data from a data provider; and then serving an updated page on the client-agent's explicit AJAX request.
I believe that the asynchronicity of the AJAX part, what with its data-refresh timeouts and other stuff, will make the client JavaScript fragile, unrobust, and breakable in the real world. I love AJAX, but I'd like to get rid of it in this app.
But all of the user's state, including his username, his preferences, and more, is sent to the server CGI in each AJAX request (currently as POST data).
And all of THAT convoluted design requirement prompted my original question, which was (as you somehow divined, thankfully): how to send ever-new user state in a periodic, Refresh-header-prompted browser GET.
Whew! And now I'll try your test: get the client JS to find and modify the DOM url.
Continuing thanks again, Chris.
-- Pete Wilson
pete
> wrote:
> The refresh is part of a META element.
> That element appears in the DOM, which can be accessed by JavaScript.
> Within the element, the url= attribute carries the data you want to
> modify. In the DOM, that's a separate node named 'url'. You want to
> modify the content of that node.
>
> Documentation on using JavaScipt to modify the DOM in a way that works
> cross-browser is scanty. (I would be delighted to be corrected by
> someone). In essence, you have to find the node you want to modify and
> then change its content. If you already knew all that and wanted details,
> post back and I'll see if I can cobble something together.
>
> What isn't clear is WHEN the browser picks up that content. Ideally, it
> would be at the end of the current 60-second interval, so the new set of
> sources would show up at the next refresh. It is theoretically possible,
> however, that the browser picks up the url value when it initially reads
> the META statement. In that case, it will use the unmodified version of
> the url on the next refresh, ignoring (and overlaying) the change you just
> made. The only way I know of to find out is to test it.
Mozilla DOM has the object window.location, one of whose read/write properties is search, which contains everything after and including the question mark. The browser reloads from window.location whenever any of its properties, including search, gets modified: https://developer.mozilla.org/en/DOM/window.location
IE has something similar: http://msdn.microsoft.com/en-us/library/ms952605.aspx
I'll work with that for a while to see how it goes.
Thanks!
-- Pete Wilson
Chris Beall
Pete,
You are definitely on the right track. The Mozilla doc looks current, the
IE stuff has a 1997 copyright at the bottom, so proceed with caution.
Cheers,
Chris
Thomas 'PointedEars' Lahn
> On Mon, 25 Apr 2011 14:57:48 -0400, pete <pet...@yahoo.com> wrote:
>> Everything goes in cycles, they say, and I wonder if perhaps it's time
>> to revive the Refresh header, to give it a new place in Web2.0
>> operations.
JFTR: "Web 2.0 operations" by definition includes server-side scripting, and
even "AJAX" (as in XHR) as well.
>> That would work well for one of my sites IFF some user/visitor state
>> could be sent with the browser's automatic-refresh GET request, the one
>> that's issued as it periodically honors the page's Refresh header.
No, it would not. But see below.
>> Imagine for a moment that AJAX does not exist. Then:
>> Consider a site http://www.all-the-headlines.com/. It serves a web page
>> full of headlines from three newspapers. These headlines are literally
>> current to the minute because the page carries a Refresh header, perhaps
>> instigated by:
>>
>> <meta http-equiv="refresh"
>> content="60;url=http://www.all-the-
headlines.com?source=nytimes,wallstjournal,washingtonpost">
>>
>> in the page's <head> section. The effect of the header is that every 60
>> seconds the browser automatically, on its own, issues a GET request with
>> a query string that I assume (haven't found an example yet) must look
>> something like:
>>
>> source=nytimes,wallstjournal,washingtonpost
>>
>> Now imagine that a user is tired of seeing Wall Street Journal
>> headlines, and he says so by clearing a checkbox on the page.
>>
>> Script on the page now wants to modify browser's GET-request query
>> string such that, instead of
>>
>> source=nytimes,wallstjournal,washingtonpost
>>
>> it becomes
>>
>> source=nytimes,washingtonpost
>>
>>
>> Question: What's a way for the script to change the query string so that
>> it reflects the user's new preferences?
>
> You said to assume that AJAX does not exist. OK. But AJAX is just a
> mashup of several technologies, so I'm also going to assume that HTML and
> JavaScript are still available.
>
> The refresh is part of a META element.
Or it is not happening at all. META-refresh can be disabled. In
particular, it can be disabled in Opera, the browser which mail plugin you
(Chris) are apparently using to post to Usenet. One reason why it is a
Really Bad Idea to try to revive it (the other is that it breaks navigation
when it works[1]).
[1] <http://www.w3.org/QA/Tips/reback>
> That element appears in the DOM, which can be accessed by JavaScript.
> Within the element, the url= attribute carries the data you want to
> modify.
No, there is no `url' attribute there. There is a `content' attribute,
which value contains a `url' part.
> In the DOM, that's a separate node named 'url'.
There is not. There is an attribute node named `content' though, which
value can be more easily accessed with the `content' property of the element
object (an implementation of the property attribute of the implemented
HTMLMetaElement interface):
<http://www.w3.org/TR/DOM-Level-2-HTML/html.html#ID-37041454>
You have covered the issues with that approach rather well, but you have not
provided any solutions so far. Let me provide one:
As you have noticed, assuming that browsers would evaluate the URI not
before the timeout occurred (I have not tested yet), after the automatic
refresh was done, iff it was done, the markup would be the same as before.
Unless you would store the information in a client-side cookie and the like,
and you would generate the META element with the modified preference
(client-side or server-side).
However, a public Web application should never depend on support for client-
side scripting. So server-side scripting should be used for this in the
first place, and then there is no good reason why "AJAX" (better: XHR) could
not be used (but not be depended on either).
But even with server-side scripting it is still a Really Bad Idea to try to
revive META-refresh (for that).
BTW, presenting external content like original headlines from several
newspapers on one's Web site can easily lead to copyright infringement. If
it is not a public service by an official data provider, getting written
approval from the original author is strongly recommended (IANAL).
> Documentation on using JavaScipt to modify the DOM in a way that works
> cross-browser is scanty. (I would be delighted to be corrected by
> someone).
Both <http://jibbering.com/faq/> (or its cached copy; it is offline again at
the time of writing) and <http://developer.mozilla.org/> can give you some
clue.
> All of this is off-topic for an HTML group.
ACK
> I'd suggest comp.infosystems.www.authoring.site-design as a better place.
It is not; that newsgroup apparently is for reviews of existing Web sites,
not discussions about hypothetical ones (and it appears to be quite dead on
top of that). Please read both the tagline and (if available) the charter
of a newsgroup before you crosspost or set followup-to it.
> I've attempted to cross-post this and set followups there, but I've never
> done that before, so I may have fumbled it.
It worked, but I am ignoring your Followup-To and correcting the crosspost
nevertheless.
Please trim your quotes to the relevant minimum, even when crossposting
(where the minimum would be greater than usual, but still not a full quote).
F'up2 ciwa.misc
PointedEars
--
Anyone who slaps a 'this page is best viewed with Browser X' label on
a Web page appears to be yearning for the bad old days, before the Web,
when you had very little chance of reading a document written on another
computer, another word processor, or another network. -- Tim Berners-Lee