Looking for more information on how to do PHP the right way? Check out PHP: The Right Way

Tillate Blog:
Clientside Cache Control
Nov 14, 2008 @ 13:00:14

On the Tillate Blog today there's a new post from Leo looking at how you can give clients back the control on when your cache refreshes.

We worked hard on the right caching strategy over months now. But there are still caches that do not get invalidated right or are cached too long and we still get complaints from our users. So we decided to integrate a feature that allows certain users to invalidate the cache on the server side. The first idea was to add a link to every page that will append a GET-parameter to the site and then avoid the cache.

He used the apache_request_header function to get the current request's headers and noticed that they included a cache-control header. By changing up this on the client-side, it allows the site visitor to "force" an update to the information if your application pays attention to it.

tagged: clientside control cache request header cachecontrol

Link:

SitePoint Server Side Coding Blog:
Cache it! Solve PHP Performance Problems
Nov 09, 2007 @ 19:16:00

On the SitePoint "Server Side Coding" blog, there's this look at caching to help solve some PHP performance issues.

In the good old days when building web sites was as easy as knocking up a few HTML pages, the delivery of a web page to a browser was a simple matter of having the web server fetch a file. [...] Then dynamic web pages came along and spoiled the party by introducing two problems: a delay for processing and a check of the file's age before it's sent to the browser.

They talk about what caching can do for you, what you can do (both server and client side) to prevent caching, working with the headers sent from and back out to the browser, using output buffering, partial caching and using PEAR::Cache_Lite in your application.

tagged: caching serverside clientside pear cachelite package partial caching serverside clientside pear cachelite package partial

Link:

SitePoint Server Side Coding Blog:
Cache it! Solve PHP Performance Problems
Nov 09, 2007 @ 19:16:00

On the SitePoint "Server Side Coding" blog, there's this look at caching to help solve some PHP performance issues.

In the good old days when building web sites was as easy as knocking up a few HTML pages, the delivery of a web page to a browser was a simple matter of having the web server fetch a file. [...] Then dynamic web pages came along and spoiled the party by introducing two problems: a delay for processing and a check of the file's age before it's sent to the browser.

They talk about what caching can do for you, what you can do (both server and client side) to prevent caching, working with the headers sent from and back out to the browser, using output buffering, partial caching and using PEAR::Cache_Lite in your application.

tagged: caching serverside clientside pear cachelite package partial caching serverside clientside pear cachelite package partial

Link:

Raphael Stolt's Blog:
Handling JSON responses on the client side
Jun 06, 2007 @ 07:41:00

In a previous post, Raphael Stolt showed how to create a simple application that handled the transmission of a JSON-formatted message from the Zend Framework's Zend_Service component (translating XML to JSON in the process). In this new post today he shows the other half of the equation - how to handle the JSON messages on the receiving end.

In this post I'd like to show how to unpack the JSON response and render a visual representation by utilizing the Template class of the Prototype JavaScript library.

The code is all Javascript but it's a good example of how to break down the request and output a simple list format of the contents to the page (record "shelf" and record information).

tagged: json response clientside template prototype javascript json response clientside template prototype javascript

Link:

Raphael Stolt's Blog:
Handling JSON responses on the client side
Jun 06, 2007 @ 07:41:00

In a previous post, Raphael Stolt showed how to create a simple application that handled the transmission of a JSON-formatted message from the Zend Framework's Zend_Service component (translating XML to JSON in the process). In this new post today he shows the other half of the equation - how to handle the JSON messages on the receiving end.

In this post I'd like to show how to unpack the JSON response and render a visual representation by utilizing the Template class of the Prototype JavaScript library.

The code is all Javascript but it's a good example of how to break down the request and output a simple list format of the contents to the page (record "shelf" and record information).

tagged: json response clientside template prototype javascript json response clientside template prototype javascript

Link:

Zend Developer Zone:
PHP Security Tip #14
Mar 21, 2007 @ 16:13:00

The Zend Developer Zone continues their great series of tips today with the latest - #14 - a tip concerning the consideration of the overall security of your application (there's a mouthful).

Almost any application running PHP on the back-end uses web technologies for it's front end. Many developers who think hard on PHP security, don't spend a thought on front-end security for their application.

The specific example they give is a frontend issue, a Javascript cookie. Ensure that any data you put inside a cookie is safe. No matter what, do not put anything sensitive in its contents.

tagged: securitytip clientside application javascript cookie securitytip clientside application javascript cookie

Link:

Zend Developer Zone:
PHP Security Tip #14
Mar 21, 2007 @ 16:13:00

The Zend Developer Zone continues their great series of tips today with the latest - #14 - a tip concerning the consideration of the overall security of your application (there's a mouthful).

Almost any application running PHP on the back-end uses web technologies for it's front end. Many developers who think hard on PHP security, don't spend a thought on front-end security for their application.

The specific example they give is a frontend issue, a Javascript cookie. Ensure that any data you put inside a cookie is safe. No matter what, do not put anything sensitive in its contents.

tagged: securitytip clientside application javascript cookie securitytip clientside application javascript cookie

Link:

SitePoint PHP Blog:
It's official: Javascript sucks harder than PHP
Oct 11, 2006 @ 09:35:00

It's official - Javascript sucks. Well, at least according to Harry Fuecks and the group from the last WebTuesday meeting.

The surprise outcome of last nights webtuesday - Javascript sucks harder than PHP. I still can't quite believe it. Maarten took the PHP corner against me in the Javascript corner, both of us shamelessly advocating each language under various headings.

1 minute max per topic—no outright lies although often bordering on truthiness. Verdicts provided by the audience, based on who could shout loudest from a choice [ranking].

Of course, Harry does comment that the comparison is a bit unfair (server versus client side), but there are alternatives for both (client-side PHP and server-side Javascript) so make a foundation for enough of a comparison. At the end of the night, though, the results of the votes were conclusive - Javascript was in worse shape than PHP, though the winner was "he one that came out hurting less".

tagged: javascript sucks ranking scale serverside clientside javascript sucks ranking scale serverside clientside

Link:

SitePoint PHP Blog:
It's official: Javascript sucks harder than PHP
Oct 11, 2006 @ 09:35:00

It's official - Javascript sucks. Well, at least according to Harry Fuecks and the group from the last WebTuesday meeting.

The surprise outcome of last nights webtuesday - Javascript sucks harder than PHP. I still can't quite believe it. Maarten took the PHP corner against me in the Javascript corner, both of us shamelessly advocating each language under various headings.

1 minute max per topic—no outright lies although often bordering on truthiness. Verdicts provided by the audience, based on who could shout loudest from a choice [ranking].

Of course, Harry does comment that the comparison is a bit unfair (server versus client side), but there are alternatives for both (client-side PHP and server-side Javascript) so make a foundation for enough of a comparison. At the end of the night, though, the results of the votes were conclusive - Javascript was in worse shape than PHP, though the winner was "he one that came out hurting less".

tagged: javascript sucks ranking scale serverside clientside javascript sucks ranking scale serverside clientside

Link: