Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.php > #7876 > unrolled thread
| Started by | Biju S <biju@pixnnova.com> |
|---|---|
| First post | 2012-12-22 01:18 -0800 |
| Last post | 2012-12-25 11:40 -0500 |
| Articles | 20 on this page of 63 — 15 participants |
Back to article view | Back to comp.lang.php
Pass varible with out URL and SESSION Biju S <biju@pixnnova.com> - 2012-12-22 01:18 -0800
Re: Pass varible with out URL and SESSION "M. Strobel" <sorry_no_mail_here@nowhere.dee> - 2012-12-22 10:24 +0100
Re: Pass varible with out URL and SESSION Luuk <luuk@invalid.lan> - 2012-12-22 11:05 +0100
Re: Pass varible with out URL and SESSION "M. Strobel" <sorry_no_mail_here@nowhere.dee> - 2012-12-22 11:37 +0100
Re: Pass varible with out URL and SESSION "M. Strobel" <sorry_no_mail_here@nowhere.dee> - 2012-12-22 11:40 +0100
Re: Pass varible with out URL and SESSION The Natural Philosopher <tnp@invalid.invalid> - 2012-12-22 12:29 +0000
Re: Pass varible with out URL and SESSION "Twayne" <nobody@devnull.spamcop.net> - 2012-12-22 12:21 -0500
Re: Pass varible with out URL and SESSION The Natural Philosopher <tnp@invalid.invalid> - 2012-12-22 22:55 +0000
Re: Pass varible with out URL and SESSION Jerry Stuckle <jstucklex@attglobal.net> - 2012-12-22 18:03 -0500
Re: Pass varible with out URL and SESSION Luuk <luuk@invalid.lan> - 2012-12-23 08:56 +0100
Re: Pass varible with out URL and SESSION houghi <houghi@houghi.org.invalid> - 2012-12-23 15:25 +0100
Re: Pass varible with out URL and SESSION Jerry Stuckle <jstucklex@attglobal.net> - 2012-12-23 11:21 -0500
Re: Pass varible with out URL and SESSION "Twayne" <nobody@devnull.spamcop.net> - 2012-12-23 12:27 -0500
Re: Pass varible with out URL and SESSION "M. Strobel" <sorry_no_mail_here@nowhere.dee> - 2012-12-23 18:45 +0100
Re: Pass varible with out URL and SESSION Denis McMahon <denismfmcmahon@gmail.com> - 2012-12-22 13:15 +0000
Re: Pass varible with out URL and SESSION Scott Johnson <noonehome@chalupasworld.com> - 2012-12-22 05:26 -0800
Re: Pass varible with out URL and SESSION The Natural Philosopher <tnp@invalid.invalid> - 2012-12-22 14:43 +0000
Re: Pass varible with out URL and SESSION "Twayne" <nobody@devnull.spamcop.net> - 2012-12-22 12:23 -0500
Re: Pass varible with out URL and SESSION "M. Strobel" <sorry_no_mail_here@nowhere.dee> - 2012-12-22 21:55 +0100
Re: Pass varible with out URL and SESSION The Natural Philosopher <tnp@invalid.invalid> - 2012-12-22 22:56 +0000
Re: Pass varible with out URL and SESSION "M. Strobel" <sorry_no_mail_here@nowhere.dee> - 2012-12-23 18:02 +0100
Re: Pass varible with out URL and SESSION Gregor Kofler <usenet@gregorkofler.com> - 2012-12-23 00:43 +0100
Re: Pass varible with out URL and SESSION The Natural Philosopher <tnp@invalid.invalid> - 2012-12-23 00:09 +0000
Re: Pass varible with out URL and SESSION "Andy" <andy@NOSPAMmanyplay.com> - 2012-12-24 09:30 +0000
Re: Pass varible with out URL and SESSION Jerry Stuckle <jstucklex@attglobal.net> - 2012-12-24 08:30 -0500
Re: Pass varible with out URL and SESSION Denis McMahon <denismfmcmahon@gmail.com> - 2012-12-24 16:40 +0000
Re: Pass varible with out URL and SESSION Jerry Stuckle <jstucklex@attglobal.net> - 2012-12-24 13:56 -0500
Re: Pass varible with out URL and SESSION Denis McMahon <denismfmcmahon@gmail.com> - 2012-12-24 22:26 +0000
Re: Pass varible with out URL and SESSION The Natural Philosopher <tnp@invalid.invalid> - 2012-12-24 23:30 +0000
Re: Pass varible with out URL and SESSION Jerry Stuckle <jstucklex@attglobal.net> - 2012-12-24 20:23 -0500
Re: Pass varible with out URL and SESSION Denis McMahon <denismfmcmahon@gmail.com> - 2012-12-25 12:21 +0000
Re: Pass varible with out URL and SESSION Jerry Stuckle <jstucklex@attglobal.net> - 2012-12-25 08:41 -0500
Re: Pass varible with out URL and SESSION "Peter H. Coffin" <hellsop@ninehells.com> - 2012-12-25 10:14 -0600
Re: Pass varible with out URL and SESSION The Natural Philosopher <tnp@invalid.invalid> - 2012-12-25 19:25 +0000
Re: Pass varible with out URL and SESSION Denis McMahon <denismfmcmahon@gmail.com> - 2012-12-26 01:21 +0000
Re: Pass varible with out URL and SESSION Jerry Stuckle <jstucklex@attglobal.net> - 2012-12-25 20:36 -0500
Re: Pass varible with out URL and SESSION Denis McMahon <denismfmcmahon@gmail.com> - 2012-12-26 02:21 +0000
Re: Pass varible with out URL and SESSION Jerry Stuckle <jstucklex@attglobal.net> - 2012-12-25 21:47 -0500
Re: Pass varible with out URL and SESSION "Andy" <andy@NOSPAMmanyplay.com> - 2012-12-25 10:03 +0000
Re: Pass varible with out URL and SESSION The Natural Philosopher <tnp@invalid.invalid> - 2012-12-25 10:31 +0000
Re: Pass varible with out URL and SESSION "J.O. Aho" <user@example.net> - 2012-12-25 13:10 +0100
Re: Pass varible with out URL and SESSION Denis McMahon <denismfmcmahon@gmail.com> - 2012-12-25 13:23 +0000
Re: Pass varible with out URL and SESSION "J.O. Aho" <user@example.net> - 2012-12-25 16:08 +0100
Re: Pass varible with out URL and SESSION Jerry Stuckle <jstucklex@attglobal.net> - 2012-12-25 08:44 -0500
Re: Pass varible with out URL and SESSION "Andy" <andy@NOSPAMmanyplay.com> - 2012-12-27 09:22 +0000
Re: Pass varible with out URL and SESSION Jerry Stuckle <jstucklex@attglobal.net> - 2012-12-25 08:42 -0500
Re: Pass varible with out URL and SESSION adrian@poppyrecords.invalid.invalid (Adrian Tuddenham) - 2012-12-24 13:41 +0000
Re: Pass varible with out URL and SESSION Scott Johnson <noonehome@chalupasworld.com> - 2012-12-24 06:23 -0800
Re: Pass varible with out URL and SESSION adrian@poppyrecords.invalid.invalid (Adrian Tuddenham) - 2012-12-24 15:43 +0000
Re: Pass varible with out URL and SESSION "M. Strobel" <sorry_no_mail_here@nowhere.dee> - 2012-12-24 17:07 +0100
Re: Pass varible with out URL and SESSION "J.O. Aho" <user@example.net> - 2012-12-24 22:36 +0100
Re: Pass varible with out URL and SESSION The Natural Philosopher <tnp@invalid.invalid> - 2012-12-24 23:25 +0000
Re: Pass varible with out URL and SESSION Jerry Stuckle <jstucklex@attglobal.net> - 2012-12-24 20:25 -0500
Re: Pass varible with out URL and SESSION "Twayne" <nobody@devnull.spamcop.net> - 2012-12-23 12:37 -0500
Re: Pass varible with out URL and SESSION Jerry Stuckle <jstucklex@attglobal.net> - 2012-12-23 13:36 -0500
Re: Pass varible with out URL and SESSION Jerry Stuckle <jstucklex@attglobal.net> - 2012-12-22 09:32 -0500
Re: Pass varible with out URL and SESSION Denis McMahon <denismfmcmahon@gmail.com> - 2012-12-22 18:09 +0000
Re: Pass varible with out URL and SESSION Jerry Stuckle <jstucklex@attglobal.net> - 2012-12-22 13:45 -0500
Re: Pass varible with out URL and SESSION Jerry Stuckle <jstucklex@attglobal.net> - 2012-12-22 08:25 -0500
Re: Pass varible with out URL and SESSION Gregor Kofler <usenet@gregorkofler.com> - 2012-12-22 17:35 +0100
Re: Pass varible with out URL and SESSION email.nandkishore@gmail.com - 2012-12-22 09:51 -0800
Re: Pass varible with out URL and SESSION Biju S <biju@pixnnova.com> - 2012-12-25 07:20 -0800
Re: Pass varible with out URL and SESSION Jerry Stuckle <jstucklex@attglobal.net> - 2012-12-25 11:40 -0500
Page 2 of 4 — ← Prev page 1 [2] 3 4 Next page →
| From | "M. Strobel" <sorry_no_mail_here@nowhere.dee> |
|---|---|
| Date | 2012-12-23 18:02 +0100 |
| Message-ID | <ajorq3F4bnaU1@mid.uni-berlin.de> |
| In reply to | #7896 |
Am 22.12.2012 23:56, schrieb The Natural Philosopher: > On 22/12/12 20:55, M. Strobel wrote: >> Am 22.12.2012 18:23, schrieb Twayne: >>> In news:kb4guc$dng$2@news.albasani.net, >>> The Natural Philosopher <tnp@invalid.invalid> typed: >>>> On 22/12/12 13:26, Scott Johnson wrote: >>>>> On 12/22/2012 5:15 AM, Denis McMahon wrote: >>>>>> On Sat, 22 Dec 2012 01:18:53 -0800, Biju S wrote: >>>>>> >>>>>>> Pass varible to One page to other page .... >>>>>>> With out Url varible and session .... >>>>>>> any way >>>>>> >>>>>> Put it in a cookie that gets saved on the client. Use >>>>>> javascript to manipulate the cookie to store / retrieve >>>>>> the value. Ask in a javascript group or forum for more >>>>>> details. Won't work if the client routinely disables >>>>>> javascript from untrusted servers. >>>>> >>>>> Or POST I suppose >>>>> >>>> well, POST is all there is, since session stuff IS >>>> cookies, just in a pretty dress. >>>> >>>> >>>>> Scotty >>> >>> Not quite: Sessions do not put anything on the client side machine. It's all >>> kept on the server if it's wrtten properly. They definitely are NOT cookies; >>> please have a look at the manual. >>> >> >> And how, do you think, the server can identify the client? >> > > Twayne doesn't know a lot. I think he's one of stuckles by blows... > he doesnt do thinking.. > I would like to hear his explanation. This is called education science. /Str.
[toc] | [prev] | [next] | [standalone]
| From | Gregor Kofler <usenet@gregorkofler.com> |
|---|---|
| Date | 2012-12-23 00:43 +0100 |
| Message-ID | <kb5gi4$4fe$1@dont-email.me> |
| In reply to | #7889 |
Am 2012-12-22 18:23, Twayne meinte:
> In news:kb4guc$dng$2@news.albasani.net,
> The Natural Philosopher <tnp@invalid.invalid> typed:
>> On 22/12/12 13:26, Scott Johnson wrote:
>>> On 12/22/2012 5:15 AM, Denis McMahon wrote:
>>>> On Sat, 22 Dec 2012 01:18:53 -0800, Biju S wrote:
>>>>
>>>>> Pass varible to One page to other page ....
>>>>> With out Url varible and session ....
>>>>> any way
>>>>
>>>> Put it in a cookie that gets saved on the client. Use
>>>> javascript to manipulate the cookie to store / retrieve
>>>> the value. Ask in a javascript group or forum for more
>>>> details. Won't work if the client routinely disables
>>>> javascript from untrusted servers.
>>>
>>> Or POST I suppose
>>>
>> well, POST is all there is, since session stuff IS
>> cookies, just in a pretty dress.
>>
>>
>>> Scotty
>
> Not quite: Sessions do not put anything on the client side machine. It's all
> kept on the server if it's wrtten properly. They definitely are NOT cookies;
> please have a look at the manual.
They *frequently* do. Unless one doesn't want to transfer the session id
as URL parameter, it is stored in a session cookie which contains the
session id, which the server then can use to access the server-side
stored actual data.
Since you advise others to read the manual - have a look at:
http://php.net/manual/en/session.idpassing.php
" There are two methods to propagate a session id:
Cookies
URL parameter
"
Gregor
[toc] | [prev] | [next] | [standalone]
| From | The Natural Philosopher <tnp@invalid.invalid> |
|---|---|
| Date | 2012-12-23 00:09 +0000 |
| Message-ID | <kb5i3d$ekf$1@news.albasani.net> |
| In reply to | #7898 |
On 22/12/12 23:43, Gregor Kofler wrote: > Am 2012-12-22 18:23, Twayne meinte: >> In news:kb4guc$dng$2@news.albasani.net, >> The Natural Philosopher <tnp@invalid.invalid> typed: >>> On 22/12/12 13:26, Scott Johnson wrote: >>>> On 12/22/2012 5:15 AM, Denis McMahon wrote: >>>>> On Sat, 22 Dec 2012 01:18:53 -0800, Biju S wrote: >>>>> >>>>>> Pass varible to One page to other page .... >>>>>> With out Url varible and session .... >>>>>> any way >>>>> >>>>> Put it in a cookie that gets saved on the client. Use >>>>> javascript to manipulate the cookie to store / retrieve >>>>> the value. Ask in a javascript group or forum for more >>>>> details. Won't work if the client routinely disables >>>>> javascript from untrusted servers. >>>> >>>> Or POST I suppose >>>> >>> well, POST is all there is, since session stuff IS >>> cookies, just in a pretty dress. >>> >>> >>>> Scotty >> >> Not quite: Sessions do not put anything on the client side machine. >> It's all >> kept on the server if it's wrtten properly. They definitely are NOT >> cookies; >> please have a look at the manual. > > They *frequently* do. Unless one doesn't want to transfer the session id > as URL parameter, it is stored in a session cookie which contains the > session id, which the server then can use to access the server-side > stored actual data. > > Since you advise others to read the manual - have a look at: > > http://php.net/manual/en/session.idpassing.php > > " There are two methods to propagate a session id: > > Cookies > URL parameter > " > > Gregor > > well exactly. There are only three ways to keep track of a browser state between pages: cookie, GET or POST. sessions are just a noob wrapper. -- Ineptocracy (in-ep-toc’-ra-cy) – a system of government where the least capable to lead are elected by the least capable of producing, and where the members of society least likely to sustain themselves or succeed, are rewarded with goods and services paid for by the confiscated wealth of a diminishing number of producers.
[toc] | [prev] | [next] | [standalone]
| From | "Andy" <andy@NOSPAMmanyplay.com> |
|---|---|
| Date | 2012-12-24 09:30 +0000 |
| Message-ID | <TgVBs.744755$9H4.287269@fx17.am4> |
| In reply to | #7899 |
> well exactly. There are only three ways to keep track of a browser state > between pages: cookie, GET or POST. In the words of Yoda "There is another"... You guys won't like it but I thought it worth mentioning that you can also use a hidden frame and store any variable to be passed back to the next content page. Andy
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2012-12-24 08:30 -0500 |
| Message-ID | <kb9le6$34s$1@dont-email.me> |
| In reply to | #7908 |
On 12/24/2012 4:30 AM, Andy wrote: >> well exactly. There are only three ways to keep track of a browser >> state between pages: cookie, GET or POST. > > In the words of Yoda "There is another"... > > You guys won't like it but I thought it worth mentioning that you can > also use a hidden frame and store any variable to be passed back to the > next content page. > > Andy Which still comes back in the GET or POST values, as applicable. -- ================== Remove the "x" from my email address Jerry Stuckle JDS Computer Training Corp. jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | Denis McMahon <denismfmcmahon@gmail.com> |
|---|---|
| Date | 2012-12-24 16:40 +0000 |
| Message-ID | <kba0in$lnb$1@dont-email.me> |
| In reply to | #7909 |
On Mon, 24 Dec 2012 08:30:45 -0500, Jerry Stuckle wrote: > On 12/24/2012 4:30 AM, Andy wrote: >>> well exactly. There are only three ways to keep track of a browser >>> state between pages: cookie, GET or POST. >> >> In the words of Yoda "There is another"... >> >> You guys won't like it but I thought it worth mentioning that you can >> also use a hidden frame and store any variable to be passed back to the >> next content page. > Which still comes back in the GET or POST values, as applicable. I think Andy is suggesting a client side method that uses javascript to store a variable in a higher level frame between page loads. This could be used to pass data between the javascript code running in two pages on a client without passing the data through the server. It's a similar approach to using js to create a cookie on the client side that can be read by js in another page on the client side, to pass data between pages on the client side without relying on the server. However, as we already agreed (I think), until we have more information about what the OP actually wants to do, and specifically whether he's trying to pass state information between pages on the client or on the server, it's a bit pointless debating the ins and outs of the various possible methods. -- Denis McMahon, denismfmcmahon@gmail.com
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2012-12-24 13:56 -0500 |
| Message-ID | <kba8gh$mv3$1@dont-email.me> |
| In reply to | #7914 |
On 12/24/2012 11:40 AM, Denis McMahon wrote: > On Mon, 24 Dec 2012 08:30:45 -0500, Jerry Stuckle wrote: > >> On 12/24/2012 4:30 AM, Andy wrote: >>>> well exactly. There are only three ways to keep track of a browser >>>> state between pages: cookie, GET or POST. >>> >>> In the words of Yoda "There is another"... >>> >>> You guys won't like it but I thought it worth mentioning that you can >>> also use a hidden frame and store any variable to be passed back to the >>> next content page. > >> Which still comes back in the GET or POST values, as applicable. > > I think Andy is suggesting a client side method that uses javascript to > store a variable in a higher level frame between page loads. This could > be used to pass data between the javascript code running in two pages on > a client without passing the data through the server. > > It's a similar approach to using js to create a cookie on the client side > that can be read by js in another page on the client side, to pass data > between pages on the client side without relying on the server. > > However, as we already agreed (I think), until we have more information > about what the OP actually wants to do, and specifically whether he's > trying to pass state information between pages on the client or on the > server, it's a bit pointless debating the ins and outs of the various > possible methods. > But it's still passed back to the server via POST or GET. All he's suggesting is a different way of storing it on the client (i.e. instead of a hidden field in a form). -- ================== Remove the "x" from my email address Jerry Stuckle JDS Computer Training Corp. jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | Denis McMahon <denismfmcmahon@gmail.com> |
|---|---|
| Date | 2012-12-24 22:26 +0000 |
| Message-ID | <kbakra$lmv$1@dont-email.me> |
| In reply to | #7915 |
On Mon, 24 Dec 2012 13:56:17 -0500, Jerry Stuckle wrote: > On 12/24/2012 11:40 AM, Denis McMahon wrote: >> On Mon, 24 Dec 2012 08:30:45 -0500, Jerry Stuckle wrote: >> >>> On 12/24/2012 4:30 AM, Andy wrote: >>>>> well exactly. There are only three ways to keep track of a browser >>>>> state between pages: cookie, GET or POST. >>>> >>>> In the words of Yoda "There is another"... >>>> >>>> You guys won't like it but I thought it worth mentioning that you can >>>> also use a hidden frame and store any variable to be passed back to >>>> the next content page. >> >>> Which still comes back in the GET or POST values, as applicable. >> >> I think Andy is suggesting a client side method that uses javascript to >> store a variable in a higher level frame between page loads. This could >> be used to pass data between the javascript code running in two pages >> on a client without passing the data through the server. >> >> It's a similar approach to using js to create a cookie on the client >> side that can be read by js in another page on the client side, to pass >> data between pages on the client side without relying on the server. >> >> However, as we already agreed (I think), until we have more information >> about what the OP actually wants to do, and specifically whether he's >> trying to pass state information between pages on the client or on the >> server, it's a bit pointless debating the ins and outs of the various >> possible methods. > But it's still passed back to the server via POST or GET. All he's > suggesting is a different way of storing it on the client (i.e. instead > of a hidden field in a form). No, he's suggesting a way to pass data from a client side script running in one page on the client to a client page script running in another page on the client *without* going back through the server at all. Scenario: A frameset has javascript methods set( param, value ) and get(param) Any pages loaded into a subframe of that frameset, from the same host (xss restrictions will apply if the page is from a different host) can call the set and get methods in the parent frameset to store / retrieve values that will never be passed through the server. I once wrote a shopping catalogue that ran 100% in client side javascript doing this, for someone who was running on a hosting provider that only made a basic mailform cgi available. Customers could browse the catalogue, pick out their goods, and then mail their shopping list to the company using the mailform cgi. The (mom & pop) company would then contact the customer, confirm the requirement, put it on their van and deliver it, collecting payment when they delivered. The only time that any "data" apart from plain page requests got sent to the server was after the complete order had been assembled, when it was sent to the mailform cgi on the server, and that could have been avoided by generating a mail uri that would have launched the default mail application on the client computer and populate the message text. The same can be done with a javascript cookie, although the cookie in that case does get sent to the server the server just discards it, but the javascript in different pages from the same host (again security constraints apply) on the client can read and write the cookie and use it to pass data values between themselves. -- Denis McMahon, denismfmcmahon@gmail.com
[toc] | [prev] | [next] | [standalone]
| From | The Natural Philosopher <tnp@invalid.invalid> |
|---|---|
| Date | 2012-12-24 23:30 +0000 |
| Message-ID | <kbaoid$805$3@news.albasani.net> |
| In reply to | #7917 |
On 24/12/12 22:26, Denis McMahon wrote: > On Mon, 24 Dec 2012 13:56:17 -0500, Jerry Stuckle wrote: > >> On 12/24/2012 11:40 AM, Denis McMahon wrote: >>> On Mon, 24 Dec 2012 08:30:45 -0500, Jerry Stuckle wrote: >>> >>>> On 12/24/2012 4:30 AM, Andy wrote: >>>>>> well exactly. There are only three ways to keep track of a browser >>>>>> state between pages: cookie, GET or POST. >>>>> >>>>> In the words of Yoda "There is another"... >>>>> >>>>> You guys won't like it but I thought it worth mentioning that you can >>>>> also use a hidden frame and store any variable to be passed back to >>>>> the next content page. >>> >>>> Which still comes back in the GET or POST values, as applicable. >>> >>> I think Andy is suggesting a client side method that uses javascript to >>> store a variable in a higher level frame between page loads. This could >>> be used to pass data between the javascript code running in two pages >>> on a client without passing the data through the server. >>> >>> It's a similar approach to using js to create a cookie on the client >>> side that can be read by js in another page on the client side, to pass >>> data between pages on the client side without relying on the server. >>> >>> However, as we already agreed (I think), until we have more information >>> about what the OP actually wants to do, and specifically whether he's >>> trying to pass state information between pages on the client or on the >>> server, it's a bit pointless debating the ins and outs of the various >>> possible methods. > >> But it's still passed back to the server via POST or GET. All he's >> suggesting is a different way of storing it on the client (i.e. instead >> of a hidden field in a form). > > No, he's suggesting a way to pass data from a client side script running > in one page on the client to a client page script running in another page > on the client *without* going back through the server at all. > > Scenario: > > A frameset has javascript methods set( param, value ) and get(param) > > Any pages loaded into a subframe of that frameset, from the same host (xss > restrictions will apply if the page is from a different host) can call > the set and get methods in the parent frameset to store / retrieve values > that will never be passed through the server. > > I once wrote a shopping catalogue that ran 100% in client side javascript > doing this, for someone who was running on a hosting provider that only > made a basic mailform cgi available. Customers could browse the > catalogue, pick out their goods, and then mail their shopping list to the > company using the mailform cgi. > > The (mom & pop) company would then contact the customer, confirm the > requirement, put it on their van and deliver it, collecting payment when > they delivered. > > The only time that any "data" apart from plain page requests got sent to > the server was after the complete order had been assembled, when it was > sent to the mailform cgi on the server, and that could have been avoided > by generating a mail uri that would have launched the default mail > application on the client computer and populate the message text. > > The same can be done with a javascript cookie, although the cookie in > that case does get sent to the server the server just discards it, but > the javascript in different pages from the same host (again security > constraints apply) on the client can read and write the cookie and use it > to pass data values between themselves. > which is a rather different matter: for that data to make any difference TO the server it has to be passed TO the server in some way. Unless you are going to send some javascript code whose action is modified by the variables, in which case its scarcely a (server side) PHP issue at all. -- Ineptocracy (in-ep-toc’-ra-cy) – a system of government where the least capable to lead are elected by the least capable of producing, and where the members of society least likely to sustain themselves or succeed, are rewarded with goods and services paid for by the confiscated wealth of a diminishing number of producers.
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2012-12-24 20:23 -0500 |
| Message-ID | <kbav76$ea8$1@dont-email.me> |
| In reply to | #7917 |
On 12/24/2012 5:26 PM, Denis McMahon wrote: > On Mon, 24 Dec 2012 13:56:17 -0500, Jerry Stuckle wrote: > >> On 12/24/2012 11:40 AM, Denis McMahon wrote: >>> On Mon, 24 Dec 2012 08:30:45 -0500, Jerry Stuckle wrote: >>> >>>> On 12/24/2012 4:30 AM, Andy wrote: >>>>>> well exactly. There are only three ways to keep track of a browser >>>>>> state between pages: cookie, GET or POST. >>>>> >>>>> In the words of Yoda "There is another"... >>>>> >>>>> You guys won't like it but I thought it worth mentioning that you can >>>>> also use a hidden frame and store any variable to be passed back to >>>>> the next content page. >>> >>>> Which still comes back in the GET or POST values, as applicable. >>> >>> I think Andy is suggesting a client side method that uses javascript to >>> store a variable in a higher level frame between page loads. This could >>> be used to pass data between the javascript code running in two pages >>> on a client without passing the data through the server. >>> >>> It's a similar approach to using js to create a cookie on the client >>> side that can be read by js in another page on the client side, to pass >>> data between pages on the client side without relying on the server. >>> >>> However, as we already agreed (I think), until we have more information >>> about what the OP actually wants to do, and specifically whether he's >>> trying to pass state information between pages on the client or on the >>> server, it's a bit pointless debating the ins and outs of the various >>> possible methods. > >> But it's still passed back to the server via POST or GET. All he's >> suggesting is a different way of storing it on the client (i.e. instead >> of a hidden field in a form). > > No, he's suggesting a way to pass data from a client side script running > in one page on the client to a client page script running in another page > on the client *without* going back through the server at all. > > Scenario: > > A frameset has javascript methods set( param, value ) and get(param) > > Any pages loaded into a subframe of that frameset, from the same host (xss > restrictions will apply if the page is from a different host) can call > the set and get methods in the parent frameset to store / retrieve values > that will never be passed through the server. > > I once wrote a shopping catalogue that ran 100% in client side javascript > doing this, for someone who was running on a hosting provider that only > made a basic mailform cgi available. Customers could browse the > catalogue, pick out their goods, and then mail their shopping list to the > company using the mailform cgi. > > The (mom & pop) company would then contact the customer, confirm the > requirement, put it on their van and deliver it, collecting payment when > they delivered. > > The only time that any "data" apart from plain page requests got sent to > the server was after the complete order had been assembled, when it was > sent to the mailform cgi on the server, and that could have been avoided > by generating a mail uri that would have launched the default mail > application on the client computer and populate the message text. > > The same can be done with a javascript cookie, although the cookie in > that case does get sent to the server the server just discards it, but > the javascript in different pages from the same host (again security > constraints apply) on the client can read and write the cookie and use it > to pass data values between themselves. > Which is just another way of storing data on the client. It doesn't do a bit of good getting data back to the server so PHP can act on it - cgi or otherwise. -- ================== Remove the "x" from my email address Jerry Stuckle JDS Computer Training Corp. jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | Denis McMahon <denismfmcmahon@gmail.com> |
|---|---|
| Date | 2012-12-25 12:21 +0000 |
| Message-ID | <kbc5nu$4p8$1@dont-email.me> |
| In reply to | #7920 |
On Mon, 24 Dec 2012 20:23:49 -0500, Jerry Stuckle wrote: > On 12/24/2012 5:26 PM, Denis McMahon wrote: >> No, he's suggesting a way to pass data from a client side script >> running in one page on the client to a client page script running in >> another page on the client *without* going back through the server at >> all. > Which is just another way of storing data on the client. It doesn't do > a bit of good getting data back to the server so PHP can act on it - cgi > or otherwise. Sometimes all you want to do is pass data from javascript running in one client page to javascript running in another client page, and sometimes you want to do this in a hosting environment that doesn't support any for of server side scripting. Which is why we need more detail about what the OP is trying to do before we try and give him solutions, because we're all making assumptions about his requirement based on incomplete data. I could assume that he's talking about passing data between php scripts on the server, in which case session / post / get are the obvious methods, but then I start wondering why doesn't he want to use the obvious methods? Are they not available to him? If they're not, then perhaps he's not scripting server side, and so perhaps what he's trying to do, although he's asking both in the wrong place and in a very ambiguously worded way, is to pass values between two client side scripts. -- Denis McMahon, denismfmcmahon@gmail.com
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2012-12-25 08:41 -0500 |
| Message-ID | <kbcade$4mp$1@dont-email.me> |
| In reply to | #7925 |
On 12/25/2012 7:21 AM, Denis McMahon wrote: > On Mon, 24 Dec 2012 20:23:49 -0500, Jerry Stuckle wrote: > >> On 12/24/2012 5:26 PM, Denis McMahon wrote: > >>> No, he's suggesting a way to pass data from a client side script >>> running in one page on the client to a client page script running in >>> another page on the client *without* going back through the server at >>> all. > >> Which is just another way of storing data on the client. It doesn't do >> a bit of good getting data back to the server so PHP can act on it - cgi >> or otherwise. > > Sometimes all you want to do is pass data from javascript running in one > client page to javascript running in another client page, and sometimes > you want to do this in a hosting environment that doesn't support any for > of server side scripting. > If that's what he's wanting, why would he be asking in a PHP newsgroup? > Which is why we need more detail about what the OP is trying to do before > we try and give him solutions, because we're all making assumptions about > his requirement based on incomplete data. I could assume that he's > talking about passing data between php scripts on the server, in which > case session / post / get are the obvious methods, but then I start > wondering why doesn't he want to use the obvious methods? Are they not > available to him? If they're not, then perhaps he's not scripting server > side, and so perhaps what he's trying to do, although he's asking both in > the wrong place and in a very ambiguously worded way, is to pass values > between two client side scripts. > No, you're making assumptions that he wants to do something he never asked for, and is off topic in this newsgroup. -- ================== Remove the "x" from my email address Jerry Stuckle JDS Computer Training Corp. jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | "Peter H. Coffin" <hellsop@ninehells.com> |
|---|---|
| Date | 2012-12-25 10:14 -0600 |
| Message-ID | <slrnkdjk7n.4ja.hellsop@nibelheim.ninehells.com> |
| In reply to | #7925 |
On Tue, 25 Dec 2012 12:21:18 +0000 (UTC), Denis McMahon wrote: > On Mon, 24 Dec 2012 20:23:49 -0500, Jerry Stuckle wrote: > >> On 12/24/2012 5:26 PM, Denis McMahon wrote: > >>> No, he's suggesting a way to pass data from a client side script >>> running in one page on the client to a client page script running in >>> another page on the client *without* going back through the server at >>> all. > >> Which is just another way of storing data on the client. It doesn't do >> a bit of good getting data back to the server so PHP can act on it - cgi >> or otherwise. > > Sometimes all you want to do is pass data from javascript running in one > client page to javascript running in another client page, and sometimes > you want to do this in a hosting environment that doesn't support any for > of server side scripting. So tell me how this works in PHP please? This being comp.lang.php and all... -- Lisa: There's going to be sex, drugs, rock'n'roll. Chips, dips, chains, whips. -- "Weird Science"
[toc] | [prev] | [next] | [standalone]
| From | The Natural Philosopher <tnp@invalid.invalid> |
|---|---|
| Date | 2012-12-25 19:25 +0000 |
| Message-ID | <kbcuie$8rs$1@news.albasani.net> |
| In reply to | #7932 |
On 25/12/12 16:14, Peter H. Coffin wrote: > On Tue, 25 Dec 2012 12:21:18 +0000 (UTC), Denis McMahon wrote: >> On Mon, 24 Dec 2012 20:23:49 -0500, Jerry Stuckle wrote: >> >>> On 12/24/2012 5:26 PM, Denis McMahon wrote: >> >>>> No, he's suggesting a way to pass data from a client side script >>>> running in one page on the client to a client page script running in >>>> another page on the client *without* going back through the server at >>>> all. >> >>> Which is just another way of storing data on the client. It doesn't do >>> a bit of good getting data back to the server so PHP can act on it - cgi >>> or otherwise. >> >> Sometimes all you want to do is pass data from javascript running in one >> client page to javascript running in another client page, and sometimes >> you want to do this in a hosting environment that doesn't support any for >> of server side scripting. > > So tell me how this works in PHP please? > > This being comp.lang.php and all... > You send all the customers' data to the browser and let JavaScript sort out which details apply to this particular browser? -- Ineptocracy (in-ep-toc’-ra-cy) – a system of government where the least capable to lead are elected by the least capable of producing, and where the members of society least likely to sustain themselves or succeed, are rewarded with goods and services paid for by the confiscated wealth of a diminishing number of producers.
[toc] | [prev] | [next] | [standalone]
| From | Denis McMahon <denismfmcmahon@gmail.com> |
|---|---|
| Date | 2012-12-26 01:21 +0000 |
| Message-ID | <kbdje8$qa2$1@dont-email.me> |
| In reply to | #7932 |
On Tue, 25 Dec 2012 10:14:47 -0600, Peter H. Coffin wrote: > On Tue, 25 Dec 2012 12:21:18 +0000 (UTC), Denis McMahon wrote: >> On Mon, 24 Dec 2012 20:23:49 -0500, Jerry Stuckle wrote: >> >>> On 12/24/2012 5:26 PM, Denis McMahon wrote: >> >>>> No, he's suggesting a way to pass data from a client side script >>>> running in one page on the client to a client page script running in >>>> another page on the client *without* going back through the server at >>>> all. >> >>> Which is just another way of storing data on the client. It doesn't >>> do a bit of good getting data back to the server so PHP can act on it >>> - cgi or otherwise. >> >> Sometimes all you want to do is pass data from javascript running in >> one client page to javascript running in another client page, and >> sometimes you want to do this in a hosting environment that doesn't >> support any for of server side scripting. > > So tell me how this works in PHP please? > > This being comp.lang.php and all... It doesn't :) But the fact this is a php group never seems to stop people asking about non php things here. Which is why right at the start I suggested that if this is what he was trying to do, he should be using a javascript forum and not a php one. Which would have been the end of the matter, if it hadn't been for a few people who insisted that what I had suggested, and pointed him to a javascript forum for information about, as a mechanism for passing data between pages on the client side, was either impossible (it's not) or needed server side scripting of some sort (it doesn't). ;) -- Denis McMahon, denismfmcmahon@gmail.com
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2012-12-25 20:36 -0500 |
| Message-ID | <kbdkba$v9l$1@dont-email.me> |
| In reply to | #7935 |
On 12/25/2012 8:21 PM, Denis McMahon wrote: > On Tue, 25 Dec 2012 10:14:47 -0600, Peter H. Coffin wrote: > >> On Tue, 25 Dec 2012 12:21:18 +0000 (UTC), Denis McMahon wrote: >>> On Mon, 24 Dec 2012 20:23:49 -0500, Jerry Stuckle wrote: >>> >>>> On 12/24/2012 5:26 PM, Denis McMahon wrote: >>> >>>>> No, he's suggesting a way to pass data from a client side script >>>>> running in one page on the client to a client page script running in >>>>> another page on the client *without* going back through the server at >>>>> all. >>> >>>> Which is just another way of storing data on the client. It doesn't >>>> do a bit of good getting data back to the server so PHP can act on it >>>> - cgi or otherwise. >>> >>> Sometimes all you want to do is pass data from javascript running in >>> one client page to javascript running in another client page, and >>> sometimes you want to do this in a hosting environment that doesn't >>> support any for of server side scripting. >> >> So tell me how this works in PHP please? >> >> This being comp.lang.php and all... > > It doesn't :) > > But the fact this is a php group never seems to stop people asking about > non php things here. > > Which is why right at the start I suggested that if this is what he was > trying to do, he should be using a javascript forum and not a php one. > > Which would have been the end of the matter, if it hadn't been for a few > people who insisted that what I had suggested, and pointed him to a > javascript forum for information about, as a mechanism for passing data > between pages on the client side, was either impossible (it's not) or > needed server side scripting of some sort (it doesn't). ;) > But the OP never asked about passing data between pages. So your "answer" was completely off-topic - both in this newsgroup and to the OP. You just can't seem to understand that... -- ================== Remove the "x" from my email address Jerry Stuckle JDS Computer Training Corp. jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | Denis McMahon <denismfmcmahon@gmail.com> |
|---|---|
| Date | 2012-12-26 02:21 +0000 |
| Message-ID | <kbdmvo$82e$1@dont-email.me> |
| In reply to | #7936 |
On Tue, 25 Dec 2012 20:36:40 -0500, Jerry Stuckle wrote: > But the OP never asked about passing data between pages. So your > "answer" was completely off-topic - both in this newsgroup and to the > OP. Passing data between pages is *exactly* what he asked about! > Pass varible to One page to other page .... > With out Url varible and session .... > any way I parsed his post as: "Is there any way to pass a variable from one page to another page without using server side php session data or embedding the variable in a url as a fieldname=value pair?" You seem to assume that because he's asking in a php newsgroup, he must be talking in a php context. I am more liberal in interpreting his question, and allow for the fact that even though he's asking in a php group, he may be trying to do something that's outside the scope of php, and in case he is, suggest that if so, he look somewhere else that's more appropriate. Experience has taught me that many people come to this group with non php queries (including html, javascript, sql, xml, css etc), which is why I apply a liberal interpretation of all questions asked of this ng. -- Denis McMahon, denismfmcmahon@gmail.com
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2012-12-25 21:47 -0500 |
| Message-ID | <kbdog3$i6j$2@dont-email.me> |
| In reply to | #7938 |
On 12/25/2012 9:21 PM, Denis McMahon wrote: > On Tue, 25 Dec 2012 20:36:40 -0500, Jerry Stuckle wrote: > >> But the OP never asked about passing data between pages. So your >> "answer" was completely off-topic - both in this newsgroup and to the >> OP. > > Passing data between pages is *exactly* what he asked about! > >> Pass varible to One page to other page .... >> With out Url varible and session .... >> any way > > I parsed his post as: > > "Is there any way to pass a variable from one page to another page > without using server side php session data or embedding the variable in a > url as a fieldname=value pair?" > > You seem to assume that because he's asking in a php newsgroup, he must > be talking in a php context. > > I am more liberal in interpreting his question, and allow for the fact > that even though he's asking in a php group, he may be trying to do > something that's outside the scope of php, and in case he is, suggest > that if so, he look somewhere else that's more appropriate. > > Experience has taught me that many people come to this group with non php > queries (including html, javascript, sql, xml, css etc), which is why I > apply a liberal interpretation of all questions asked of this ng. > Not in a PHP newsgroup. And, as pointed out by others, there are numerous problems with your "solution". -- ================== Remove the "x" from my email address Jerry Stuckle JDS Computer Training Corp. jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | "Andy" <andy@NOSPAMmanyplay.com> |
|---|---|
| Date | 2012-12-25 10:03 +0000 |
| Message-ID | <bTeCs.572436$Xv.61693@fx07.am4> |
| In reply to | #7917 |
"Denis McMahon" <denismfmcmahon@gmail.com> wrote in message
news:kbakra$lmv$1@dont-email.me...
> On Mon, 24 Dec 2012 13:56:17 -0500, Jerry Stuckle wrote:
>
>> On 12/24/2012 11:40 AM, Denis McMahon wrote:
>>> On Mon, 24 Dec 2012 08:30:45 -0500, Jerry Stuckle wrote:
>>>
>>>> On 12/24/2012 4:30 AM, Andy wrote:
>>>>>> well exactly. There are only three ways to keep track of a browser
>>>>>> state between pages: cookie, GET or POST.
>>>>>
>>>>> In the words of Yoda "There is another"...
>>>>>
>>>>> You guys won't like it but I thought it worth mentioning that you can
>>>>> also use a hidden frame and store any variable to be passed back to
>>>>> the next content page.
>>>
>>>> Which still comes back in the GET or POST values, as applicable.
>>>
>>> I think Andy is suggesting a client side method that uses javascript to
>>> store a variable in a higher level frame between page loads. This could
>>> be used to pass data between the javascript code running in two pages
>>> on a client without passing the data through the server.
>>>
>>> It's a similar approach to using js to create a cookie on the client
>>> side that can be read by js in another page on the client side, to pass
>>> data between pages on the client side without relying on the server.
>>>
>>> However, as we already agreed (I think), until we have more information
>>> about what the OP actually wants to do, and specifically whether he's
>>> trying to pass state information between pages on the client or on the
>>> server, it's a bit pointless debating the ins and outs of the various
>>> possible methods.
>
>> But it's still passed back to the server via POST or GET. All he's
>> suggesting is a different way of storing it on the client (i.e. instead
>> of a hidden field in a form).
>
> No, he's suggesting a way to pass data from a client side script running
> in one page on the client to a client page script running in another page
> on the client *without* going back through the server at all.
>
> Scenario:
>
> A frameset has javascript methods set( param, value ) and get(param)
>
> Any pages loaded into a subframe of that frameset, from the same host (xss
> restrictions will apply if the page is from a different host) can call
> the set and get methods in the parent frameset to store / retrieve values
> that will never be passed through the server.
>
> I once wrote a shopping catalogue that ran 100% in client side javascript
> doing this, for someone who was running on a hosting provider that only
> made a basic mailform cgi available. Customers could browse the
> catalogue, pick out their goods, and then mail their shopping list to the
> company using the mailform cgi.
>
> The (mom & pop) company would then contact the customer, confirm the
> requirement, put it on their van and deliver it, collecting payment when
> they delivered.
>
> The only time that any "data" apart from plain page requests got sent to
> the server was after the complete order had been assembled, when it was
> sent to the mailform cgi on the server, and that could have been avoided
> by generating a mail uri that would have launched the default mail
> application on the client computer and populate the message text.
>
> The same can be done with a javascript cookie, although the cookie in
> that case does get sent to the server the server just discards it, but
> the javascript in different pages from the same host (again security
> constraints apply) on the client can read and write the cookie and use it
> to pass data values between themselves.
>
> --
> Denis McMahon, denismfmcmahon@gmail.com
Hi,
Dennis is correct.
In fact, I too use this frame method in an ecommerce site so that if the
customer browses back to the shopping cart after filling in some/all details
on the checkout page, the information is restored when they decide to
proceed to the checkout.
No data is sent to the server other than fetching the checkout page and no
data is stored on the client's computer. The information is stored in the
'header' frame as javascript variables and recalled by the checkout page
loaded into the 'content' frame...
onBlur="parent.HEADING.mydetails_firstname=mydetails_firstname.value;
if (parent.HEADING.mydetails_firstname!=''){
document.getElementById('mydetails_firstname').value=parent.HEADING.mydetails_firstname;
}
If you want to see it in action, visit the following link which will land on
the shopping cart page with a product (a PC) already added to your order...
https://www.microbuild.com/microbuild/catalog/shopping_cart.php?action=buy_now&products_id=181
... Then click the 'Place Order' button to take you to the checkout page and
fill in any test information you like. Click the 'Back to My Order' button
to return to the shopping cart and then click the 'Place Order' button again
to return to the checkout page. You'll see that any information you entered
previously has been magically preserved :)
Andy
Ps Merry Christmas everyone.
[toc] | [prev] | [next] | [standalone]
| From | The Natural Philosopher <tnp@invalid.invalid> |
|---|---|
| Date | 2012-12-25 10:31 +0000 |
| Message-ID | <kbbvaa$bb4$7@news.albasani.net> |
| In reply to | #7922 |
On 25/12/12 10:03, Andy wrote:
>
>
> "Denis McMahon" <denismfmcmahon@gmail.com> wrote in message
> news:kbakra$lmv$1@dont-email.me...
>> On Mon, 24 Dec 2012 13:56:17 -0500, Jerry Stuckle wrote:
>>
>>> On 12/24/2012 11:40 AM, Denis McMahon wrote:
>>>> On Mon, 24 Dec 2012 08:30:45 -0500, Jerry Stuckle wrote:
>>>>
>>>>> On 12/24/2012 4:30 AM, Andy wrote:
>>>>>>> well exactly. There are only three ways to keep track of a browser
>>>>>>> state between pages: cookie, GET or POST.
>>>>>>
>>>>>> In the words of Yoda "There is another"...
>>>>>>
>>>>>> You guys won't like it but I thought it worth mentioning that you can
>>>>>> also use a hidden frame and store any variable to be passed back to
>>>>>> the next content page.
>>>>
>>>>> Which still comes back in the GET or POST values, as applicable.
>>>>
>>>> I think Andy is suggesting a client side method that uses javascript to
>>>> store a variable in a higher level frame between page loads. This could
>>>> be used to pass data between the javascript code running in two pages
>>>> on a client without passing the data through the server.
>>>>
>>>> It's a similar approach to using js to create a cookie on the client
>>>> side that can be read by js in another page on the client side, to pass
>>>> data between pages on the client side without relying on the server.
>>>>
>>>> However, as we already agreed (I think), until we have more information
>>>> about what the OP actually wants to do, and specifically whether he's
>>>> trying to pass state information between pages on the client or on the
>>>> server, it's a bit pointless debating the ins and outs of the various
>>>> possible methods.
>>
>>> But it's still passed back to the server via POST or GET. All he's
>>> suggesting is a different way of storing it on the client (i.e. instead
>>> of a hidden field in a form).
>>
>> No, he's suggesting a way to pass data from a client side script running
>> in one page on the client to a client page script running in another page
>> on the client *without* going back through the server at all.
>>
>> Scenario:
>>
>> A frameset has javascript methods set( param, value ) and get(param)
>>
>> Any pages loaded into a subframe of that frameset, from the same host
>> (xss
>> restrictions will apply if the page is from a different host) can call
>> the set and get methods in the parent frameset to store / retrieve values
>> that will never be passed through the server.
>>
>> I once wrote a shopping catalogue that ran 100% in client side javascript
>> doing this, for someone who was running on a hosting provider that only
>> made a basic mailform cgi available. Customers could browse the
>> catalogue, pick out their goods, and then mail their shopping list to the
>> company using the mailform cgi.
>>
>> The (mom & pop) company would then contact the customer, confirm the
>> requirement, put it on their van and deliver it, collecting payment when
>> they delivered.
>>
>> The only time that any "data" apart from plain page requests got sent to
>> the server was after the complete order had been assembled, when it was
>> sent to the mailform cgi on the server, and that could have been avoided
>> by generating a mail uri that would have launched the default mail
>> application on the client computer and populate the message text.
>>
>> The same can be done with a javascript cookie, although the cookie in
>> that case does get sent to the server the server just discards it, but
>> the javascript in different pages from the same host (again security
>> constraints apply) on the client can read and write the cookie and use it
>> to pass data values between themselves.
>>
>> --
>> Denis McMahon, denismfmcmahon@gmail.com
>
> Hi,
>
> Dennis is correct.
>
> In fact, I too use this frame method in an ecommerce site so that if the
> customer browses back to the shopping cart after filling in some/all
> details on the checkout page, the information is restored when they
> decide to proceed to the checkout.
>
> No data is sent to the server other than fetching the checkout page and
> no data is stored on the client's computer. The information is stored in
> the 'header' frame as javascript variables and recalled by the checkout
> page loaded into the 'content' frame...
>
> onBlur="parent.HEADING.mydetails_firstname=mydetails_firstname.value;
>
> if (parent.HEADING.mydetails_firstname!=''){
> document.getElementById('mydetails_firstname').value=parent.HEADING.mydetails_firstname;
>
> }
>
> If you want to see it in action, visit the following link which will
> land on the shopping cart page with a product (a PC) already added to
> your order...
>
> https://www.microbuild.com/microbuild/catalog/shopping_cart.php?action=buy_now&products_id=181
>
>
> ... Then click the 'Place Order' button to take you to the checkout page
> and fill in any test information you like. Click the 'Back to My Order'
> button to return to the shopping cart and then click the 'Place Order'
> button again to return to the checkout page. You'll see that any
> information you entered previously has been magically preserved :)
>
But not if you switch off the client computer. Or stop and restart its
browser. Which cookies WILL cater for.
> Andy
>
> Ps Merry Christmas everyone.
--
Ineptocracy
(in-ep-toc’-ra-cy) – a system of government where the least capable to
lead are elected by the least capable of producing, and where the
members of society least likely to sustain themselves or succeed, are
rewarded with goods and services paid for by the confiscated wealth of a
diminishing number of producers.
[toc] | [prev] | [next] | [standalone]
Page 2 of 4 — ← Prev page 1 [2] 3 4 Next page →
Back to top | Article view | comp.lang.php
csiph-web