If we don't use an ORM within our projects we need to write SQL statements by hand. I don't mind to write SQL. It's simple and descriptive but sometimes we like to use helpers to avoid write the same code again and again. Today we are going to create a simple library to help use to write simple SQL queries.

It's a lightweight library that'd be good for basic uses, but when you start getting into something a bit more complex, something like Doctrine2 or Propel might be a better solution (or whatever your framework of choice has built in).

For my project I decided to use the Doctrine 2 ORM to manage my data layer. We also use this at work, so the biggest reason I chose this was to be able to learn more about Doctrine to help me in my job. But this decision also makes sense for my project because my entity relationships will likely be fairly straightforward for the most part and using an ORM will allow me to make a lot of progress very quickly without (I hope) causing me lots of trouble later on.

His handy wrapper (Data Manager) makes it simpler to perform the flush and still take transactions into consideration. His simple class includes "flush", "commit" and "startTransaction" methods that don't actually perform the flush until the commit is called.

The legacy code dilemma, however, is always present: you can't refactor the code before putting up some tests on it to avoid regressions and putting your application offline. At the same time, you can't easily unit test the code until some refactoring is introduced.

He suggests making copies of some files to allow you to make small changes where needed to "mock" resources in the application to prevent it from accessing the actual data sources. His method fakes HTTP requests to the script and uses the copy of the script as an internal resource. Don't worry, code is included showing how its done - a basic "ForumPosting" class that includes the needed file and wraps the output in a buffer.

Don't let the definition freak you out, as if you've been using MVC for a while the chances are you've used a service already. Controllers are often called services, as they carry out application logic and additionally are capable of interfacing to several client layers, namely views. Of course in a more demanding environment, plain controllers fail short in handling several clients without the aforementioned duplicating, so that's why the construction of a standalone layer is more suitable in such cases.

He explains the process behind creating a simple domain model (image here) and shows how the Service layer wraps it up into a simpler interface, leaving the model to handle the business logic. He uses the example of an "EncoderInterface" that's implemented in a "JsonEncoder" and "Serializer" to both provide a "setData" method.

On December 21, 2011 Stefan Koopmanschap wrote an excellent article on this blog titled "Painless (well, less painful) migration to Symfony2." [...] We were very much inspired by his passionate elucidation and we were fully convinced of the urge to start migrating to Symfony2 as soon as possible. However, he also provided us with a "A word of caution" about 2 things: performance and authentication/authorization. This might get some people worried, but not us: it challenged us to find a solution for those two open issues.

They explain why these two things are a problem and some of their solutions they've created - a .htaccess for routing and manually replicating the Symfony2 session in the Symfony1 code. Included in the post are the rewrite rules and code to make these two things happen (and a small configuration change to make them work).

Using the memory/temporary stream provided by php:// stream wrapper you can create a stream with read and write access directly to RAM or to a temporary file [using "php://memory"]. This gives you the possibilty to write unit tests that does not rely on a specific file, resource or stream, but rather on data provided by the test itself.

There's no specific code examples here, but you can refer to the stream wrappers section of the PHP manual for more details on this and other handy built-in streams. Once created, it can then be used just as any other stream resource can. This could be useful to provide mocks in your testing, replacing any other stream-able resource with a "memory" or "temp" placeholder.

Microsoft Language translation is an interesting service. Not only can you do language translation, you can also detect the language of a particular text. The given class provides a PHP wrapper which will help developers translate text from one language to another in a easy manner. The library also supports caching, helping you keep your translations fast and simple.

His translation library requires an AppId for configuration and cURL to handle the messaging back and forth. Translation is as easy as calling "translate()" on a string, language fetching with "LanguageNames()" and even converting the text to speech with the "speak()" method.

Thanks to a comment in my last post (many thanks Benjamin) I've discovered that it's possible to create a stream wrapper in PHP (I thought it was only available with a C extension). It's pretty straightforward to create the wrapper. Of course it's only an approach. We can create more functionality to our stram wrapper but at least this example meets my needs.

His wrapper uses a client from his Nov framework to open the stream to the given path and gives read and write methods to work with the data inside the database. Code for the wrapper class is included as well as a bit of example code showing how it can be used with the custom stream protocol. You can find the complete code here.

While the Two Step View pattern creates a reasonable paradigm for seperating layout presentation from page presentation, enabling Three-level Inheritance allows for even better separation. In other words, using 3 Step Layouts is a possible and often necessary investment to make when implementing front-ends in Zend Framework projects; they allow fine grain re-usability that provides for a DRYer presentation layer.

They have a three step process you can follow (complete with code snippets) that'll have you working with their 3 layers easily. The wrapper is a sort of "boostrap" for the layout. The nested layout is then pulled into this wrapper (for example's sake, theirs is called "default") and then the view can be served as normal and placed into the content location. There's also a bit of code showing how to switch out the layout if there's ever a need - like different layouts for the admin, user and main parts of your application.

In a previous tweet about playing with Klout and Twitter I talked about a project I am working on that mines Klout for interesting people. (Well, interesting to me) The main body of code remains procedural because...well because it works and it's not something I'm going to share so why bother cleaning it up. However parts of it may be useful to me in other projects. So I abstracted the Klout API into a class and have posted it for anyone who wants to use it.

His Klout wrapper for PHP (a github project) is largely procedural but gives you a good idea of how to talk to their API. Cal mentions some other things he's wanting to do with the script, but notes that it's ready for use now without any other changes. You can find out more about Klout on their website.