Passing information to another page.

[vbMark]

Hello,

I am doing this:

window.location="page2.php?subj="+subj+"&body="+bo dy;

to send information to another page.

However, I don't want that second page to show up or display in any way.
There is only behind-the-scenes work going on in that page.

How do I pass the information to that page so that it is only processed and
does not launch a window?

Thanks!
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Get freeware
http://www.vbmark.com
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

[Zoe Brown]

"vbMark" <[e-mail]> wrote in message
news:Xn********************@199.45.49.11...

Hello,

I am doing this:

window.location="page2.php?subj="+subj+"&body="+bo dy;

to send information to another page.

However, I don't want that second page to show up or display in any way.
There is only behind-the-scenes work going on in that page.

How do I pass the information to that page so that it is only processed
and
does not launch a window?

use an iframe or frame to process a page server side.

[Dag Sunde]

"Zoe Brown" <zo***********@N-O-S-P-A-A-Mtesco.net> wrote in message
news:U_******************@newsfe1-gui.ntli.net...

"vbMark" <[e-mail]> wrote in message
news:Xn********************@199.45.49.11...

Hello,

I am doing this:

window.location="page2.php?subj="+subj+"&body="+bo dy;

to send information to another page.

However, I don't want that second page to show up or display in any way.
There is only behind-the-scenes work going on in that page.

How do I pass the information to that page so that it is only processed
and
does not launch a window?

use an iframe or frame to process a page server side.

Or Ajax...

--
Dag.

[David Dorward]

Dag Sunde wrote:

How do I pass the information to that page so that it is only processed
and does not launch a window?

use an iframe or frame to process a page server side.

Or Ajax...

The joy of buzzwords. That is an Ajax technique. (Not so common as using
XMLHttpRequest, but better supported).

--
David Dorward <http://blog.dorward.me.uk/> <http://dorward.me.uk/>
Home is where the ~/.bashrc is

[Dag Sunde]

"David Dorward" <do*****@yahoo.com> wrote in message
news:df*******************@news.demon.co.uk...

Dag Sunde wrote:

How do I pass the information to that page so that it is only processed
and does not launch a window? use an iframe or frame to process a page server side.

Or Ajax...

The joy of buzzwords. That is an Ajax technique. (Not so common as using
XMLHttpRequest, but better supported).

Er... And the difference is?

;-)

Using an iframe or frame is in my world a predecessor to what we call
Ajax today.

Ajax is just an acronym for " Asynchronous JavaScript and XML", and a name
for a concept, while "XMLHttpRequest" is the practical implementation of
one of its parts...

So when I said Ajax, It involves setting up an "XMLHttpRequest" object and
use it to call the said server page. Heeding the response is then optional.

--
Dag.

[Richard Cornford]

Dag Sunde wrote:

David Dorward wrote:

Dag Sunde wrote: <snip>

use an iframe or frame to process a page server side.

Or Ajax...

The joy of buzzwords. That is an Ajax technique. (Not so
common as using XMLHttpRequest, but better supported).

Er... And the difference is?

;-)

Using an iframe or frame is in my world a predecessor to what
we call Ajax today.

Ajax is just an acronym for " Asynchronous JavaScript and XML",

So something that could be done with a frame or an iframe, though XML
would probably not be the best choice of data representation in that
context.
and a name for a concept,
And an interesting concept, that has become almost entirely submerged in
the blurring of the term into a buzzword for any use of xml http
requests. (When you see "AJAX" libraries that include the (theoretically
redundant) option to configure for synchronous loading you know that the
term has lost most of its meaning.)
while "XMLHttpRequest" is the practical
implementation of one of its parts...

So when I said Ajax, It involves setting up an
"XMLHttpRequest" object and use it to call the said
server page.
So your say that XMLHttpRequest is just part of the process (and only
one of many possibilities as a data transfer method) and then directly
equate Ajax with the use of the XMLHttpRequest object?

Given that only specific configurations of IE 5+ (the most common
browser in use) support xml http requests in a general Internet context
(those with ActiveX enabled for the Internet security zone) I would
recommend exercising extreme caution in opting for the use of xml http
request on general web sites.
Heeding the response is then optional.

If it is one-way transmission of data to the server that is required (so
the response doesn't matter and can be any nominal data), and the data
transmitted is sufficiently small to be placed on a query string for a
GET request, the assigning a new URL to the - src - of an Image object,
or IMG element, probably has the widest general support. (returning a
one pixel transparent GIF makes the process safe, invisible and
lightweight).

Richard.

[bgulian]

Well, besides an HttpRequest, what are the other possibilities of data
transmission and specifically, what other possibilities did not exist
before the AJAX buzzword was invented? I would really like to know
because to me, it seems like incredible overkill to install Ruby and
Ruby on Rails on your server just to do something you can already do
anywhere with javascript and whatever you already have on your server.

BobG

[ASM]

bg*****@gmail.com wrote:

Well, besides an HttpRequest, what are the other possibilities of data
transmission and specifically, what other possibilities did not exist
before the AJAX buzzword was invented? I would really like to know
because to me, it seems like incredible overkill to install Ruby and
Ruby on Rails on your server just to do something you can already do
anywhere with javascript and whatever you already have on your server.

url of called page :
htpp:/foo.org/p.htm?var1=hello&var2=sir

<html>
<script type"text/javascript">
function getInfo(){
var uri = this.location.href
uri = uri.substring(uri.lastIndexOf('?')+1).toString();
uri = uri.split('=');
uri = uri.join('=\"');
uri = uri.split('&');
uri = uri.join('\"&');
uri = uri+'"';
alert('new infos spelling :\n'+uri)
uri = uri.split('&');
for(var i=0;i<uri.length;i++)
eval(uri[i]);
}
</script>
<a href="#"
onclick="getInfo();
alert('message =\n'+var1+' '+var2);">test</a>
</html>

--
Stephane Moriaux et son [moins] vieux Mac

[David Dorward]

Dag Sunde wrote:

use an iframe or frame to process a page server side. Or Ajax...

The joy of buzzwords. That is an Ajax technique. (Not so common as using
XMLHttpRequest, but better supported).

Er... And the difference is?
The difference between what?
Using an iframe or frame is in my world a predecessor to what we call
Ajax today.
And it others it IS what we call Ajax today. That's the problem with
buzzwords, they are usually not very clearly defined ... like DHTML.
Ajax is just an acronym for " Asynchronous JavaScript and XML", and a name
for a concept, while "XMLHttpRequest" is the practical implementation of
one of its parts...

And an iframe with some script to change its location and read its content,
is another practical implementation of one of its parts.

--
David Dorward <http://blog.dorward.me.uk/> <http://dorward.me.uk/>
Home is where the ~/.bashrc is

[Dag Sunde]

"David Dorward" <do*****@yahoo.com> wrote in message
news:df*******************@news.demon.co.uk...

Dag Sunde wrote:

> use an iframe or frame to process a page server side. Or Ajax... The joy of buzzwords. That is an Ajax technique. (Not so common as using
XMLHttpRequest, but better supported).

Er... And the difference is?

The difference between what?

Using an iframe or frame is in my world a predecessor to what we call
Ajax today.

And it others it IS what we call Ajax today. That's the problem with
buzzwords, they are usually not very clearly defined ... like DHTML.

Ajax is just an acronym for " Asynchronous JavaScript and XML", and a
name
for a concept, while "XMLHttpRequest" is the practical implementation of
one of its parts...

And an iframe with some script to change its location and read its
content,
is another practical implementation of one of its parts.

Ah... sorry!

I misunderstood your first sentence. Didn't meant it to be lecturing...

:-)

--
Dag.

[Jim Davis]

<bg*****@gmail.com> wrote in message
news:11**********************@g14g2000cwa.googlegr oups.com...

Well, besides an HttpRequest, what are the other possibilities of data
transmission and specifically, what other possibilities did not exist
before the AJAX buzzword was invented?

There were several. I'm assuming you're talking about bi-directional
communication between a server and client (browser) without refreshing the
currently displayed page. I'm not sure what you mean by "did not exist
before" - all of these existed before the word "AJAX" was coined as well as
the techniques commonly associated with AJAX. There isn't anything new
about AJAX except the name.

Off the top of my head:

+) Iframe/frame communication (communication would take place in a tiny
iframe or frame whose only purpose, generally, was bi-directional
communication with the server).

+) Java/ActiveX/Flash: These active client-side elements (and several
others) all have the capability of doing a "background" request from a
server and passing data, as an intermediary, between server-side code and
client-side script.

+) Inline Image Requests/Cookies. Since the early days JavaScript has had
the capability to manipulate the src value of and img tag. By passing URL
values on this call and receiving data back via cookies you could set up
bi-directional communication.

+) Both Netscape and IE had custom solutions in the very early days for what
they called the "push" metaphor which allowed information to be pumped
continuously into the open page without explicit refreshes. Since there
have been many browser-specific methods (I think IE's "remote scripting
toolkit" may have been the last major one).

There are others. There've been ways to do this stuff for years and lots of
people have come up with lots of clever solutions.

All AJAX really did was give a label to the idea and, in my opinion, a label
designed more for it's acronym that for it's application. While the label
specifically indicates "asynchronous" and "XML" for example the same tasks
can be done synchronously and with other encoding techniques (for example
JSON is a popular non-XML "AJAX" tool).

We really need a neat little buzzword to describe just plain
behind-the-scenes server-to-client communication. Then we'd stop seeing so
much overuse of the word "AJAX". The real revolution is that, not
specifically asynchronous XML.

That's just my opinion of course.

Jim Davis