In a new post to his site Bob Majdak looks at using SQL in PHP and some of the challenges he's come across (some of them with his own tools). He talks about things line inline SQL, loading SQL by unique key or creating a "build object".

There is no right or wrong way, but no matter what there is no *pretty* way to do SQL inside of a PHP application. I have been having a personal debate with myself all week about how to make SQL statements nicer in an application without going to a huge DBAL package like Doctrine.

He looks at each idea and provides some of the pros and cons about each of them, noting that he hasn't quite decided on which is the best method. Some sample code is included to help clarify the points, showing the "find by unique key" version and how a more complex query might be created with the "builder object."

In this new post to his blog Kevin Schroeder suggests that there's something even better than doing the typical caching inline (request, write to cache) - pre-caching.

I just had an epiphany. I've talked about pre-caching content before and the benefits thereof before. But this is the first time I realized not only that there are benefits, but that doing it is BETTER than caching inline. Let me sum up... no, there is to much. Let me explain.

He gives an example of how a typical application might cache - when it finds a "miss" for the data it's trying to pull. A simple cache is easy, but what happens if it uses a configuration value that could change (like the username/password in his second example). Pre-caching would eliminate the risk since the setting would be known to be valid when the cache is generated.

On the ThinkingPHP Blog today, there's a look at how to handle inline links to dynamic resources - specifically allowing users to create links in their own content to dynamic content elsewhere on the site.

I thought of something that would be both, easy to implement and easy to use. What I finally came up with is tightly coupled to my new url system that I'm using, so make sure to check it out in case you've missed it.

The basic idea of the system is that the URL of the page (made up partly of the title) would be the unique identifier for the page. For example, "[page 12]" would be expanded out to "/pages/12:my-title". Felix takes this idea and runs with it, showing how to implement it in a CakePHP project inside of a Model and a Component. The sample usage code is, of course, also included in the post.

On the ThinkingPHP Blog today, there's a look at how to handle inline links to dynamic resources - specifically allowing users to create links in their own content to dynamic content elsewhere on the site.

I thought of something that would be both, easy to implement and easy to use. What I finally came up with is tightly coupled to my new url system that I'm using, so make sure to check it out in case you've missed it.

The basic idea of the system is that the URL of the page (made up partly of the title) would be the unique identifier for the page. For example, "[page 12]" would be expanded out to "/pages/12:my-title". Felix takes this idea and runs with it, showing how to implement it in a CakePHP project inside of a Model and a Component. The sample usage code is, of course, also included in the post.

More and more talk is being given to testing applications these days. For some, that just means going through the functionality and ensuring that things seem to be working okay. That's one way to find problems in an application, but not the best way. A better way it through unit testing, a system of writing up various tests for the functions making up your application to ensure they're 100% working. Not familiar with it? That's what this new tutorial from DevShed is for - another excerpt from the Sams Publishing book "Advanced PHP Programming".

All code is tested at some point—perhaps during its implementation, during a dedicated testing phase, or when it goes live. Any developer who has launched broken code live knows that it is easier to test and debug code during development than after it goes into production.

Unit testing helps with finding these problems before they get into the hands of live users. The tutorial gives you a basic overview of how to work with this handy tool, specifically with the PHPUnit package. They help you write a simple test, expand on this base with more elaborate tests, and how to package your tests right in with your libraries to make installation/packaging simpler.

More and more talk is being given to testing applications these days. For some, that just means going through the functionality and ensuring that things seem to be working okay. That's one way to find problems in an application, but not the best way. A better way it through unit testing, a system of writing up various tests for the functions making up your application to ensure they're 100% working. Not familiar with it? That's what this new tutorial from DevShed is for - another excerpt from the Sams Publishing book "Advanced PHP Programming".

All code is tested at some point—perhaps during its implementation, during a dedicated testing phase, or when it goes live. Any developer who has launched broken code live knows that it is easier to test and debug code during development than after it goes into production.

Unit testing helps with finding these problems before they get into the hands of live users. The tutorial gives you a basic overview of how to work with this handy tool, specifically with the PHPUnit package. They help you write a simple test, expand on this base with more elaborate tests, and how to package your tests right in with your libraries to make installation/packaging simpler.