Variables from PHP to JS: Global variables / Cookies?
Michal Charemza
I'm trying to figure out a nice way of sending variables from the
server (in my case PHP), to JS. I wonder what people think the best
way is? I have thought of 1 1/2 methods :-) :
1a. Print out the variable using PHP in the global scope (window), to
then be used in JS below the call:
<script>var myJSVar = <?= $myPhpVar ?>;</script>
1b. Print out the variable in some function within the generated HTML
page, say in a domready handler to be used in something
<script>
window.addEvent('domready', function() {
var myJSVar = <?= $myPhpVar ?> <?= $myPhpVar ?>;
new someClass({someOption: myJSVar});
}
</script>
2. Set the value as a cookie on the server, and read it using the
MooTools Cookie object. I like this method as it avoids any "generated
Javascript", which feels a bit messy.
I guess this isn't that MooTools specific, but I wonder what people
here think...?
Michal.
Christoph Pojer
of <?= because it is deprecated in PHP5.3 and will be removed in PHP6.
I usually do it like this:
<script type="text/javascript">
(function(){
this.Config = <?php echo json_encode(array(...)); ?>
})();
</script>
which creates a global variable "Config".
Michal Charemza
On 2 Aug 2009, at 12:20, Christoph Pojer wrote:
> You should use the first method, although I recommend against the use
> of <?= because it is deprecated in PHP5.3 and will be removed in PHP6.
>
> I usually do it like this:
>
> <script type="text/javascript">
> (function(){
> this.Config = <?php echo json_encode(array(...)); ?>
> })();
> </script>
>
> which creates a global variable "Config".
Thanks: I see that for enough config variable to justify an array, a
cookie would perhaps not be suitable. However, all I'm thinking of is
a single ID-type variable. Why would a cookie not be good?
(Also thanks for the <= tip: I wasn't aware of that)
Michal.
Rolf
afterwards, no?
Also, maybe setting the cookie fails, and then your left with nothing
(or you have to build in a check and re-set it when it failed).
Printing the JS with PHP like you described is what I usually do, or I
return it as JSON if its an ajaxRequest.
Michal Charemza
On 2 Aug 2009, at 13:21, Rolf wrote:
> A cookie is clean, however it requires extra code to clean up stuff
> afterwards, no?
I'm not sure what you my by "clean up stuff", although my experience
with cookies is limited. I'm not setting an expiry time, so the cookie
will only last until the end of the session.
> Also, maybe setting the cookie fails, and then your left with nothing
> (or you have to build in a check and re-set it when it failed).
I'm not sure how actually setting a cookie can fail...? I'm not sure
if this answers your point, but, in my test code I'm setting the
cookie on the server in every request, so on every page request it is
sent to the browser. Is this bad? (yes... if this was a massive cookie
it wouldn't be the best move to be send it to/from the server on every
request, but in my case it is a string < 20 characters long).
Michal.
Christoph Pojer
b) cookies have a maximum size of 4kb
c) there is no advantage of sending a cookie to using the method as
described above
Steve Onnis
should be getting set as part of the session or application scope of the
server side, not the client side and just outputted where needed.
If you need to have a config process for the application then you should
look at using a <script src="jsVars.php"> and use the php process to create
your config js to be used through the client side.
Using cookies is a bad way to go as that is not what cookies are meant to be
used for.
Michal Charemza
I have a query:
On 2 Aug 2009, at 14:48, Christoph Pojer wrote:
> a) cookies can be disabled
I'm assuming you mean by the browser here. I know the browser can
disable sending cookies, but what about just receiving them? Does a
browser disabling cookies mean that JS in the page has no access to
the cookies sent in the HTTP header from the server?
Michal.
Michal Charemza
On 2 Aug 2009, at 15:40, Steve Onnis wrote:
> If you need to have a config process for the application then you
> should
> look at using a <script src="jsVars.php"> and use the php process to
> create
> your config js to be used through the client side.
I will probably end up doing something like this: either in a separate
file or in the HTML page. It just feels "dirty" to be generating code
for one language from another language, rather than some "proper" way
to transfer data. But I completely admit this feeling by itself could
be a bad reason...
Michal.
Ryan Florence
misunderstanding you).
A cookie is a chunk of data that the website tells the browser to
store on the visitors machine.
If the browser has cookies disabled, it will never store a cookie, and
therefore nothing (javascript or otherwise) has access to something
that is nonexistent.
Michal Charemza
On 2 Aug 2009, at 19:52, Ryan Florence wrote:
> I think you're misunderstanding what a cookie is (or I'm
> misunderstanding you).
Well, at least I thought I understood it!
> A cookie is a chunk of data that the website tells the browser to
> store on the visitors machine.
I thought it did this and one thing more: I thought the browser then
resends the cookie on every consecutive request to the domain/path
specified by the initial "set-cookie" http header from the server
(until the specified expire time). I thought that "disabling" cookies
*might* just stop this "resending" stage.
> If the browser has cookies disabled, it will never store a cookie,
> and therefore nothing (javascript or otherwise) has access to
> something that is nonexistent.
Well... this does now make sense I guess :-) I just thought that it
*might* be possible that the browser has the cookie in memory (and
accessible via JS) on the page that has the initial "set-cookie" http
header, but doesn't keep it in memory on any subsequent pages.
Michal.
Sanford Whiteman
> cookie in memory (and accessible via JS) on the page that has the
> initial "set-cookie" http header, but doesn't keep it in memory on
> any subsequent pages.
You're not so wrong about this. The browser gets the original HTTP
header (in serialized form) no matter what. But generic browsers are
under no obligation to keep it around for you to query. From some HTTP
clients, say cURL, you can definitely read the header even if the
client isn't storing and resending cookies. Standard XMLHTTP
implementations should let you read them out, too (see
getAllResponseHeaders).
-- Sandy
Ryan Florence
> request to the domain/path specified by the initial "set-cookie"
> http header from the server
This doesn't happen automatically, in your page you've got to ask for
it.
Still don't know why they call them cookies, notecards or something
similar makes more sense--or bananas.
Sanford Whiteman
>> request to the domain/path specified by the initial "set-cookie"
>> http header from the server
> This doesn't happen automatically, in your page you've got to ask for
> it.
It does happen automatically. By the time, e.g. PHP looks at $_COOKIE,
the data has already been transmitted to the web server with the
request. Unless you mean something else by "ask for it"....
["When it sends a request to an origin server, the user agent sends a
Cookie request header to the origin server if it has cookies that are
applicable to the request based on the request-host, the request-URI,
[and] the cookie's age." (RFC 2109)]
-- Sandy
Michal Charemza
It's good to know know I'm not "so" wrong, but it would be nice to not
be wrong at all!
Thanks for the clarification,
Michal.
Sanford Whiteman
> be wrong at all!
Didn't mean to diminish: your intuition was completely right in that
the Set-Cookie: header is indeed *always* present in client memory for
at least a moment in time. But not only are the response headers not
available from script for the main HTTP-requested page, only for
XMLHTTPRequest-ed content; a client is also free to implement its
"Disable cookies" setting to mean that the header will be completely
discarded -- even when the response comes in over XHR and the cookie
is standard (non-HTTPOnly). So, in practice, unless you know how all
your potential clients behave, when a user has disabled cookies, that
in practice means you don't always have access to the raw response
data, either.
-- Sandy