I think it took me (or us) a couple attempts to get this right - let me introduce you to Zf_Crud, a CRUD controller for the Zend Framework. [...] Zf_Crud aims to provide you with an interface for any table possible - think of it as a phpMyAdmin more tailored towards your data and (thanks to Twitter Bootstrap and the Easybib_Form_Decorator) prettier!

He shows how to install and use it (via PEAR or Composer) and an example of a controller extending it. You can find the code here on github, ready to clone and try out.

In fact, it is the advised best practice for controllers in shared bundles. When you do, you will no longer have access to these useful methods, in this post I am going to look at how to accomplish the same tasks without them. I have created a simple controller for some basic form interaction with a model which uses the base controllers methods. I am going to go through how to change this to a service which does not extend the base controller.

He starts with his "TestimonialController" that does some of the basic CRUD operations on the testimonial information. He shows you, step-by-step, the refactoring needed to stop using things like the default controller helpers (each with replacement code). With those removed, he can move to extend "ContainerAware" instead of "Controller", make the controller a service and doing some dependency injection for needed resources.

In my last post I created a small (and very personal) test of different templating engines in PHP (Smarty, Haanga and Twiw). Someone posted a comment asking for the comparison between those template engines and old school phtml. OK I've done some tests. It's a bit difficult to create the template inheritance (without cloning one of the template engines and creating a new one) so I have one approximation with a simple include. It's not the same but it's similar.

He tries to recreate a similar scenario as in the three other templating tools by setting up a base template (with inline PHP), a class to populate the contents of it and a sample template with "inheritance". He stacks up the execution times and memory usage against the results from the other three with interesting results, specifically compared to Haanga.

The idea is that most of your controllers share something in common with each other. For example: All admin controllers need to make sure a logged in user is present and that they are an administrator. A public controller may want to load a theme for your application and load default user data, navigation links or anything else frontend related.

The problem is solved by creating a base controller - in his example its one called MY_Controller that follows the CodeIgniter naming convention and allows you to easily make other controllers that extend it. You'll also need to make a small addition to your config.php file to get the base controllers working correctly and make them able to be found.

I was asked many times how I organize my config files, and my response was always the same, until some time ago when I switched began refactoring the codebase of my blog. [...] Looking at [the advantages of PHP config files], you may ask now why not everbody is using them. Well the problem mostly is that you cannot create extend-sections (when working with Zend_Config for example).

He compares an example of a method that, using a base config file with some "smarts", you can have it automatically pull in certain files and overwrite settings from the array inside. A sample "other config" file is also included, showing the definition of some PHP settings, resources and database information.

While I like the Singleton pattern every now and then, I prefer the flexibility that the Multiton potentially offers, and well it's just an extended version of the Singleton, so it's "compatible" with the Singleton model. Anyway, to the point, PHP5.3 is coming, and with Late Static Binding you can do a base Multiton (or Singleton if you insist), which wasn't possible before. Now I like this very much because you can simply extend it rather than rewriting those (few, I know, but still) lines each time.

Included in the post is an example of the design pattern showing how to create its structure in the class and use it to grab the same or unique instances (defined with an ID).

David Otton posted a short but thought-provoking post about stdClass, which many think is the "base class" all PHP classes automatically inherit from. I have to admit that I had this misconception as well. [...] This [difference in PHP from other OOP languages] presents some room for analysis in how things are handled in dynamic and static languages, and how those differences affect things...

Jani talks about dynamic and static typing in languages and how that effects the base types things are extended from as well as some of the benefits that having a standard base class affords developers.

Going to go through a quick walk through of how to use a hacked together version of my old jquery library with solar. You can find the class source files here.

He sets up a callback in the Base controller (that all other controllers extend) for the jQuery calls so that any of the "child" controllers can just call "/controller/jquery" to make jQuery requests.

In talking about the Firephp support:

There has been a flurry of work around Firebug recently including announcements that Zend Framework and Symfony both now have Firebug logging support through the use of the Firephp. As of this weekend Solar can be added to the list with its own support.

A quick example is included.

In the second post he looks at a simpler way to share information between all of your controllers without code duplication - adding it to the constructor of the Base controller your application is built on.

I stumbled across a blog post on how to implement Enums in PHP via userland code written by Jonathan Hohle. I liked the concept he had, but the implementation was a bit unappealing because it used eval() among other more minor issues. You shouldn't need to generate Enums at runtime, so I took that as a challenge to find a way to do it at compile time, thus making the code much more efficient.

His enums would support type hinting and would, ideally, be iterable. He gives the code he's worked up - a base class, another than extends it to make a basic enum structure and some handy changes to support comparisons. A few more changes (and a few other extended classes later) he has some pretty well functioning enums that can even bee iterated through.