On the Laravel News site there's a quick tutorial posted showing you how to use Laravel's query cache with query params to help increase the performance of your application by caching query responses.

Laravel provides a very intuitive and useful means of caching the responses of your projects, whatever your project is (RESTful API, Web Platform, etc.). In general, Laravel can store in the cache system whatever data you send (HTML, JSON, collections, Eloquent instances, and similar) accordingly with a provided expiration time.

[...] The question here is “How does Laravel determine when to store data?”

They give an example of saving a "remember" key value to the cache manually using the "remember" method on the Cache facade. He then talks about what happens internally when the "remember" method is called to know if the data was previously cached. It then moves into the caching of data based on URL values and how query params would confuse things and not provide much benefit to the caching. Thanks to some internal handling the caching ignores the query params and returns the same data as before. This is an issue if you want the updated data but is relatively easily solved with a bit of code to sort the params and normalize the URL being used as the "remember" key.

In a post to his site Sebastian de Deyne makes the suggestion that you should normalize your values (input) as soon as possible.

Dynamic languages allow us to pass anything as a parameter without requiring a specific type. In turn, this means we often need to handle some extra validation for the data that comes in to our objects.

This is a lightweight post on handling your incoming values effectively by normalizing them as soon as possible. It's a simple guideline worth keeping in mind which will help you keep your code easier to reason about.

He gives an example of a HtmlClass object instance that can take in either a single string or an array of strings. With this structure he shows the complexity it would add for methods like toArray and toString. Instead he recommends normalizing the value in the constructor, making it an array if it's not already. The the code required in the rest of the class to use/translate it is much simpler.

Jeremy Cook has written up a new post showing you a method for normalizing the date and time information in your application (DateTime) with the help of Doctrine's own event listeners.

The solution we hit on was to leverage Doctrine’s system of event listeners to help us do the work. Doctrine allows you to register listeners with the entity manager that are called whenever certain events occur. We created an event listener that is triggered on the onFlush event.

Code is included for the event listener they created - a simple "onFlush" event that grabs the current entities from the manager, sets the date/time property to allow it to be changed (via Reflection) and updating it with the new cleaned format.

Brian Moon has a "stupid PHP trick" posted to his blog today - normalizing SimpleXML data you've pulled in from just about any external source.

Anyhow, one annoying thing about SimpleXML has to do with caching. When using web services, we often cache the contents we get back. We were having a problem where we would get an error about a SimpleXML node not existing.

They were using memcache to store the information but came across problems when their code tried to use a (sometimes) empty tag. He gives two solutions - one using a recursive function that identifies the empty items and the other that encodes then decodes the object to and from JSON, keeping the values intact.