Re[4]: What's the path when setting cookie via an exec cgi include?

The only problem with using Javascript, though, is that more and more people have turned it off to prevent "browsing annoyances" (pop-up windows and the like), and also because of it opening a whole can of worms with respect to security.

Not only that, the implementation of Javascript differs from browser-to-browser (and even between different implementations of the same browser on different OSs), though I'm not sure that'd make any difference with what you have there. A good, high profile, example of this is the new Opodo website: it's written entirely in Javascript, and while it works perfectly in IE, it won't work in anything else.

I think that it's important to point out that a Javascript solution certainly won't work for everyone out there, whereas the original Perl solution to set the cookie probably would have.

-- Foxcub
#include www.liquidfusion.org.uk

Comment on Re[4]: What's the path when setting cookie via an exec cgi include?

Replies are listed 'Best First'.
Re: Re[4]: What's the path when setting cookie via an exec cgi include? by Cody Pendant (Prior) on May 15, 2003 at 23:32 UTC
Thank you both, for suggesting JavaScript and reminding me of its pitfalls. I'm quite experienced with JS issues, in fact to my shame have coded a lot more JS than Perl. The version of Best Practice at my work is that no site should require JS for navigation or function. That there should always be a fallback position. This code, for instance: `<a href="#" onclick="somefunction()"> // not allowed. Leaves some users clicking in vain.` [download] But this... `<a href="fallback.html" onclick="somefunction();return false;"> /* ...is kosher. JS people get the function, non-JS people get something else. A popup window for instance, might navigate for the non JS user into a regular-sized page. It might look a little weird, but that's better than inviting them to click and frustrating the hell out of them. And the return false prevents JS people from calling both the function and the regular click. /` [download] In my case, the cookies serve the purpose of letting users know that a certain thing has been "updated since last visit". As this is a bonus feature, rather than an essential one, it passes the test of something that may be implemented in JS, as long as, in the absence of JS, the user experience is not compromised in any way. -- “Every bit of code is either naturally related to the problem at hand, or else it's an accidental side effect of the fact that you happened to solve the problem using a digital computer.”* M-J D	[reply] [d/l] [select]

Replies are listed 'Best First'.

Re: Re[4]: What's the path when setting cookie via an exec cgi include?
by Cody Pendant (Prior) on May 15, 2003 at 23:32 UTC

I'm quite experienced with JS issues, in fact to my shame have coded a lot more JS than Perl.

The version of Best Practice at my work is that no site should require JS for navigation or function. That there should always be a fallback position.

This code, for instance:

<a href="#" onclick="somefunction()">

// not allowed. Leaves some users clicking in vain.
[download]

But this...

<a href="fallback.html" onclick="somefunction();return false;">

/* 

...is kosher. JS people get the function, non-JS people
get something else. A popup window for instance, might
navigate for the non JS user into a regular-sized page. It 
might look a little weird, but that's better than
inviting them to click and frustrating the hell out of 
them.
And the return false prevents JS people from calling both
the function and the regular click.

*/
[download]

In my case, the cookies serve the purpose of letting users know that a certain thing has been "updated since last visit".

As this is a bonus feature, rather than an essential one, it passes the test of something that may be implemented in JS, as long as, in the absence of JS, the user experience is not compromised in any way.
--

“Every bit of code is either naturally related to the problem at hand, or else it's an accidental side effect of the fact that you happened to solve the problem using a digital computer.”
M-J D

[reply]
[d/l]
[select]