Printable View
Hiya guys,
I had no idea where to put this question, as it concerns two different coding languages, feel ffree to move it if you want. I'm just getting into PHP coding, and at the moment I'm having a look at cookies and I was wondering whether it is actually better/easier to set and read cookies using PHP or JavaScript? Any opinions are welcomed.
Bernie
It depends what type of cookie. If you're just starting out in PHP, make sure you read up asap on sessions, the $_SESSION[] array quickly becomes a vital tool and you'll spend most of your time passing variables into your session using theJQuery.load()AHAH method.
3rd party cookies will, for the most part, look after themselves and any that you use yourself can either be used wholly within Javascript or passed into the PHP session for further manipulation or storage (via database/xml) there.
Remember that, when writing internal scripts, you can pass PHP variables into it; so the following will work:
PHP Code:$(document).ready(function () {
$('#click-me').click(function () {
alert('<?php echo $_SESSION['username']; ?>');
});
});
In this case, the PHP is written into the script server-side, then sent to the page. The actual source for the code as you would see it in the browser would read:
You can make external scripts behave like this as well, if you add a .htaccess file with some alternate file headers in it to the js folder, then start your scripts with:PHP Code:$(document).ready(function () {
$('#click-me').click(function () {
alert('ApacheTech');
});
});
However, this can screw up with remotely hosted files and with SVN builds like Git.PHP Code:<?php header("Content-type: text/javascript; charset: UTF-8"); ?>
After our epic discussion on the new cookie laws, I'm unsure of what to recommend here. My view of it is that if it is something that only affects the client side, such as css theme or page text size then keep it in JS/JQ. If it's anything that is better handled by PHP, such as username, anything that needs to go in a database, etc; pass it to the $_SESSION using AHAH with JQ.
Hi,
I think a simple and good answer is: If you need cookie on server side, into a php script, set and read cookie using PHP; if you need data from cookie directly into a JavaScript code, use JavaScript.
Because I'm basing my Bespoke Framework on a Norse Gods theme, I havebifrost.phpas my bridge between PHP and Javascript. It's just a simple script that's called with$.load();in JQuery, which asynchronously updates the$_SESSIONarray in PHP. There's also a callback function I can call to grab a json object from the stored server-side data. That way, the Bifrost really is a two way Bridge. :D
An alternative method that will not have that problem is to give the external javascript the .php extension.Quote:
Originally Posted by ApacheTech
Also, although that header will work, I recommend this one:
You can add a charset header separately or within that or use the server default if it's amenable.PHP Code:Header("content-type: application/x-javascript");
So your javascript could be called:
somejs.php
and be incorporated on the page (which can be PHP or an ordinary HTML page) as:
You could even send it GET data if you like. And of course all the other PHP goodies will be available in it.HTML Code:<script type="text/javascript" src="somejs.php"></script>
Yep, I use the same method for CSS. Makes it stupidly easy to create themes and things that use lots of repeated data. :) Although, I'm looking into moving over to LESS soon.
Also, using AHAH, you can create truly dynamic and morphic CSS stylesheets that react to the users input and site environment.
thanks for answering guys, with what i've been reading up on, they suggest that the best way is to use sessions, so that people without cookies enabled can have some benefit, in conjunction with cookies in order to have the best experience.
Yep. If you have a database drivenn site with membership, you can create a table called session_vars that links to each member; that way you can simulate the cookie's main purpose, to allow settings to persist through sessions.
Unless you need specific cookies for anonymous users, you can pretty much get away with using no cookies at all. This is what I meant in the other thread that for too long people have just been throwing information into cookies that doesn't need to be there. Another benefit of persistent server-side sessions over cookies is that they will persist across browsers as well. cookies only exist on that computer in that browser for that user. This way, you can use the same session tokens and adapt them dependent on browser, so a user viewing on IE will see the same if he browses on FF or Opera or Safari or Avant, etc. Any morphisms you need to do will be handled backstage using the same variables.
I don't have the book with me at the moment, but if I remember correctly, the site could correctly function without cookies using simply sessions, but as with storing the choice for the cookie accept or decline bar, it ended up using cookies for that kind of thing.Quote:
Originally Posted by ApacheTech
As I say, the only time you need to use cookies is if you need to cater for anonymous users. I can't see any need to use cookies other than that. With these sorts of cookies, you could pass control of the cookies over to .htaccess or your equivalent (web.config, etc).
That way you can set the initial cookie dependent on User Agent or even Operating System. But having said that, you could just use separate ReWrite Rules if need be to redirect to the relevant initialisation/bootstrapping script.