Panda PHP Components

I just committed a nifty update to the Panda_Loader package: Panda_Loader_Singleton. Essentially, this update just wraps the existing loader with a singleton; but don’t be fooled by the simplicity: this makes for a wicked-simple autoloading mechanism.

Implementing this component in your code is useful only when one style of code organization is used — fortunately, this is the case for most projects. The autoloader simply wraps the existing load() method — but calls it from an instance returned from a static singleton() call.

When bootstrapping your project, simply register the autoload() method and you never have to worry about including dependencies again.

spl_autoload_register(array('Panda_Loader_Singleton', 'autoload'));

Check it out yourself: http://code.google.com/p/panda-php/source/browse/trunk/Panda/Loader/Singleton.php

As promised previously, I have committed many interesting view components into the repository. I’ve written an overview of the package on my personal blog which discusses each part individually.

In summary, Panda_View is a simple package which provides an API for rendering data across various output formats. At the time of this writing, Panda_View can render PHP, JSON, XML, and HTML. New new classes for rendering data is trivial — in most cases, all that needs to be done is write a render() in a class which extends Panda_View_Abstract.

More info:

• I have started a wiki page for the Panda_View package
• API documentation is available for all libraries:
  • Panda_View_Interface
  • Panda_View_Abstract
  • Panda_View_PHP
  • Panda_View_JSON
  • Panda_View_XML
  • Panda_View_HTML

After getting an idea, I decided to update the structure of the SVN trunk. Up until now, packages were listed directly into the trunk directory. Now, packages are found within a Panda directory which is in the trunk.

This leaves the option available to put other projects at the SVN root which are closely related to the Panda project. For example, I have been considering releasing a product with every major release of Panda. So 1.0 could get a blog, 2.0 could be a shopping cart, etc. Each project would get their own directory at the root of the trunk which would also act as that project’s namespace.

This also makes including Panda source less error prone. For example, if I were to say:

require 'View/HTML.php';

What library did that just come from? Was View a PEAR package or was it a Panda package? The problem is that the above require statement is too ambiguous. Granted, the chance that multiple View libraries in one project would be rare, but it’s never a good idea to assume that.

Panda libraries should be store in a Panda directory and your require statements should also reflect that:

require 'Panda/View/HTML.php';

There. Much better.

I’ve been exploring MVC framework development on my personal blog in a series of posts called Rolling Your Own MVC. At the time of this writing, I’m wrapping up the code for my view library which will be immediately rolled into the next update.

As always, an interface and an abstract class is provided but several concrete classes are provided. They are:

• Panda_View_Interface
• Panda_View_Abstract
• Panda_View_PHP
• Panda_View_JSON
• Panda_View_XML
• Panda_View_HTML

Panda_Loader was written to provide a normalized API to loading source code into applications. An abstract class is provided to offer a base level of functionality, or if you prefer to roll your own, an abstract class is also provided. All Panda libraries with dependencies will use the Panda_Loader API.

More info:

• There is a page in the wiki that gives a quick overview of how the library is used.
• API documentation is available for Panda_Loader_Interface and Panda_Loader_Abstract