Jeff Madsen has a quick post to his site with the "untold story" behind Eloquent's save and create in the Laravel framework.

Over on Laravel Quick Tips we've been looking at a few of these functions and their uses, and I thought it might be helpful to collect all of them together in a single (I hope) coherent post.

Without further preamble, let's get to it. I'm going to use the basic User object and table that ships with a default installation of Laravel so you can follow along if you like.

He starts with the difference between "new" and "create", pointing out the one fundamental difference: one saves, one does not. He then looks at some of the other new/create functions (like findOrNew, firstOrCreate, updateOrCreate), what each of them does in the background and a quick snippet of code showing.

In a recent post Freek Lijten shares a simplified version of a solution he came up with to separate models and their logic between the fetch and save operations.

Basically I am wondering how storing data and retrieving data are different and how you should / could model this. Since we need different information while storing and retrieving information it makes sense to model those actions in different ways. The how is still bothering me and in this post I give a possible solution. I truly hope I can get some reactions and thoughts of other people in on how they would solve these kind of problems.

He introduces the basic structure of the application he's working with and how the concept of "documents" ties in. Then he gets into the problem: the differences in data required for the save versus locate and load. His solution is to split out the different pieces (relations) of the document into separate value objects. These objects then only contain the handling to get only the relations needed on the load. He doesn't like the solution, however, because of the amount of overhead it introduces.

On PHPMaster.com today there's a new tutorial showing you how to store your application's sessions in Redis, a key/value store known for its flexible nature and speed.

PHP’s default handling of session data is probably sufficient for most applications, but sometimes a project will demand a different storage approach. Luckily, the session handling routines can be overridden either by a series of functions (in older versions of PHP) or a class with methods (in newer versions) which handle various aspects of session management. In this article we’ll learn how to create a custom session handler which implements PHP’s SessionHandlerInterface interface and stores the session data in a Redis database.

He talks some about the reasoning behind using something more than just the normal PHP session handling (including the flexibility it provides). He covers some of the basics of the session handling functionality and covers how the data itself is stored. Finally, he gets to the actual class - a Redis-specific handler that implements the SessionHandlerInterface interface.

Kim Rowan has recently posted this helpful hint to the PHPWomen.org site concerning the addition of values between save/serialization in Symfony (1.4) forms.

OK, I have a Comment model and I want to relate Comment objects to several other different model types. So, I need to be able to persist Comment objects in my database that relate to the author of the comment and one of a handful of other tables, for example, a blog post or a licence record, etc.

She includes the contents of her "schema.yml" definition and the code to create and display a basic form. Inside of her "executeCreate", the form's submission is handled and a "processForm" method is called and the overridden "updateObject " is used to inject the new data (a user ID) into the submission.

On DZone.com there's a new tutorial posted (by Jorge Ramon) about hooking together the models of Sencha's Touch 2 with a PHP backend to make saving data to them simpler via a proxy.

Sencha Touch models have the ability to work with a proxy. This feature allows you to save and retrieve model data from the server, memory or local storage, without depending on a Sencha Touch data store. Let’s try it with a very simple scenario where the server side is a PHP page.

The article includes both the Javascript to create the models (along with its proxy and custom API methods defined) as well as the PHP that powers the backend. The PHP just reads from the "php://input" stream and echoes back out JSON, but it gives you an idea of what to expect to receive. For more information on Sencha Touch, check out their documentation.

Robert Basic has a new post to his blog today with an use case for Zend Framework 2's event manager to solve a problem he has with "repetitive code" in some of his models.

Basically, this allows us to have one piece of code to trigger an event and to have one or more listeners listening to this event. When the event gets triggered, the listeners are called and then we can do *something*, like caching or logging. Logging or caching. [...] See, that’s my problem. All the event examples stop at logging and caching. Truly there must be some other example for which this event stuff can be used for.

In his example code, he's used the EventManager in one of his models to add listeners to validate the post and "slugify" the post's title for use on the URL. You can find his code on github if you're interested in the full implementation.

Volker Dusch has a suggestion for all of those developers out there really concerned about the quality of your code - consider running your unit tests every time you save a file with the help of a tool called PyWatch.

At the moment he placed the Idea in my head that i want my testsuite to run every time a file changes anyway, let someone else figure out how that is triggered. Well, someone did figure that out, thank you. It's called "PyWatch" and is a simple python script that monitors files for changes and executes a script if one has changed.

Obviously you wouldn't want to keep this going for larger code bases (the potential for overlap is horrible) but it could be quite useful when doing test-driven development to save yourself some hassle at the outset. He includes the commands you'll need to get things running and a simple PHP script that points the PyWatch instance to the correct files.

Hasin Hayder has a new post talking about the new memcached extension for PHP (memcached from PECL) and how it can be used to store sessions data.

Many of you already know that managing session is a critical task for web applications, specially when you want to avoid I/O hop and also a significant load over your database by writing a custom session handler. [...] This is why a central session manager is very important for your application to scale.

He walks you through the whole process - installation, setting up memcached instances and getting the extension installed and working with your PHP installation. By adding two lines to your php.ini file, the sessions can quickly and easily be stored in memcache instead of on the local server.

Vinu Thomas has a new post to his blog looking at using the MS-Excel Stream Handler class to push your data out to Excel (in more than just a CSV file).

If you’re looking for an easy way to output your data from a PHP script into a Excel file, you’ve got to check out this script which I came across at the PHP Classes site. What this script essentially does is to implement a stream handler interface to write Microsoft Excel spreadsheet files.

Code snippets are included showing how to structure the data for the import and how to push that generated Excel file out to the user's waiting client.

Maarten Balliauw has written up a guide to saving the output of your PHPExcel applications out to the Documents service that Google offers.

As you may know, PHPExcel is built using an extensible model, supporting different input and output formats. The PHPExcel core class library features a spreadsheet engine, which is supported by IReader and IWriter instances used for reading and writing a spreadsheet to/from a file. Currently, PHPExcel supports writers for Excel2007, Excel5 (Excel 97+), CSV, HTML and PDF. Wouldnt it be nice if we could use PHPExcel to store a spreadsheet on Google Documents? Let’s combine some technologies.

The two technologies in question are a standard install of the PHPExcel library and the Zend Framework (with its Zend_Gdata component). Using the component, a save() method is created and hooked into the IWriter interface of PHPExcel. When this save method is called, the Zend_Gdata component connects to the Documents service and uploads the resulting information for the account you supply.