PHPkitchen » OOP

Class Naming Should Clearly define Object Responsibility

Demian Turner — Sun, 27 May 2007 12:23:23 +0000

Rendering views just got a whole lot easier with the Zend framework If don’t yet have a front controller instance:

$viewRenderer = new Zend_Controller_Action_Helper_ViewRenderer($view); Zend_Controller_Action_HelperBroker::addHelper($viewRenderer);

or if you do:

$viewRenderer = Zend_Controller_Action_HelperBroker::getExistingHelper('viewRenderer');$viewRenderer->setView($view);

Okay, maybe it’s not that easy. Let’s look at how the $viewRenderer object is instantiated, using the Zend_Controller_Action_Helper_ViewRenderer class. Using the PEAR naming convention has proven its worth beyond the point of contest, but how many related concepts are inferred by this class name?

Zend_Controller_Action_Helper_ViewRenderer

Modularising Workflow with an Intercepting Filter

Demian Turner — Fri, 30 Sep 2005 14:35:16 +0000

While we’re on the subject of useful refactorings, I’d like to describe how using an Intercepting Filter helped round up and modularise software setup and initialisation tasks. Before the code could get down to business with the framework’s main task, the SGL_MainProcess, (eg booking a hotel room or editing an FAQ, whatever), a certain amount of setup was necessary.

In the previous version, a number of initialisation tasks were assigned to a single init() method in the AppController, then executed procedurally. The disadvantage of this approach was that the tasks were not testable, they were difficult to reorder, and it was prohibitive to insert custom routines into the pipeline.

Enter the Intercepting Filter, which is basically a chain of decorators. The idea is that you have your main process, then you decorate it with n filters or tasks required to get your system correctly initialised beforehand. The code makes the example clearer:

class SGL_AppController{       function run()    {        $input = &SGL_RequestRegistry::singleton();        $input->setRequest($req = SGL_Request::singleton());

        $process =  new SGL_Init(                    new SGL_DiscoverClientOs(                    new SGL_ManagerResolver(                    new SGL_InitSession(                    new SGL_InitLangSupport(                    new SGL_InitPerms(                    new SGL_AuthenticateRequest(                    new SGL_BuildHeaders(                    new SGL_SetLocale(                    new SGL_DetectDebug(                    new SGL_DetectBlackListing(                    new SGL_MainProcess()                   )))))))))));

        $process->process($input);    }}

From Matt Zandstra’s book:

The model is very extensible. We can add new decorators and components very easily. With lots of decorators we can build very flexible structures at runtime. The component class [in our case SGL_MainProcess] can be significantly modified in very many ways without the need to build the totality of the modifications into the class hierarchy.

Here’s the UML:

Implementing an Output Renderer Strategy

Demian Turner — Thu, 29 Sep 2005 12:16:08 +0000

An interesting design problem became apparent when a
number of folks from the seagull ML recently complained about the lack
of support for web clients other than standard browsers. Because the code
enforces reasonable segregation between the domain modelling and the
html views, I always presumed it would be trivial to implement, ie, an
xml renderer instead of the current Flexy to handle WML output.
Two problems needed to be solved:

the Flexy renderer was hard-coded in the final stage of a validate/process/display workflow
worse, a number of post-processing tasks, mainly assembling of blocks and building of main navigation were also hard-coded

In short, the process was quite tied to producing HTML-only output, clearly n
blocks and involved navigation were unsuitable for PDA output.

I
identified two main refactorings necessary to decouple the view
production from the output type and specific renderer used, thereby
opening the door to running customised post-process tasks based on the current
rendering strategy.

To
allow an arbitrary renderer to be specified at runtime I chose to
compose the View object with a OutputRendererStrategy. This means
if you’re happy with Flexy you can use the standard renderer supplied
with the package, and if you can’t bear the thought of working without
Smarty, it’d be a piece of cake to write a SmartyOutputRenderStrategy
following the Flexy example. The code would look something like
this:

    //  build view    $view = new SGL_HtmlView($output, new SGL_HtmlFlexyRendererStrategy());    echo $view->render();

where the $output object is just a php data structure free of any
presentation information. The next problem was more interesting,
how does producing output for portable devices change the appliation
requirements. The basic data structure sent to the view is
similar, but the following main differences are evident:

any paginated lists sent to the template needed to be a lot shorter, with simpler paging
any superfluous info like that found in left/right column blocks had to go
navigation had to be dramatically simplified

Using the View type but switching implementation as runtime made it
very easy to achieve this, where WmlView implements specialised
minimalist post processing tasks, and uses an xlst renderer to output
WML. The code would look like this:

    //  build view    $view = new SGL_WmlView($output, new SGL_XmlRendererStrategy());    echo $view->render();

The code
is currently only in svn but will make it out in the 0.5.1 devel
release planned shortly. The following UML summarises the idea:

Last PHPlondon meetup and Depedency Injection talk

Demian Turner — Thu, 11 Aug 2005 11:33:50 +0000

I didn’t realise we covered so much territory in last month’s PHPlondon meetup. Thanks to Marc’s gift for total recall there’s a pretty good summary of what was discussed here.

Highlights for me were Marcus Baker’s presentation on Dependency Injection (slides here), discussion of books people had been reading[1], and XP-related development practices.

In other news, we had good progress last night with the PHP conference UK planning meeting, there’ll be a writeup soon but the low-down is it’ll happen probably Feb. 2006 and we should have a site up somewhere inside of two weeks.

[1] books:

"Design Patterns Explained: A New Perspective on Object-Oriented Design"
Alan Shalloway, James J. Trott
ISBN: 0321247140

"Head First Design Patterns"
Elisabeth Freeman, Bert Bates, Kathy Sierra
ISBN: 0596007124

"PHP 5 Objects, Patterns, Practice "
Matt Zandstra
ISBN: 1590593804
GoodBooks: Yes

"Patterns of Enterprise Application Architecture"
Martin Fowler
ISBN: 0321127420
Available for BookExchange by RobertBarbour, AndrewLarssen

"The Pragmatic Programmer"
Andrew Hunt, Davis Thomas
ISBN: 020161622X
GoodBooks: Yes

PEAR::Date issues

Demian Turner — Fri, 15 Jul 2005 09:46:18 +0000

At work we use PEAR::Date all over the place, and while the package is fine for most things, when it comes to timezone handling and daylight savings time offsets, there are some serious bugs that have been open in the PEAR bugtracker for around one year.

Andrew Hill writes in detail about a problem he’s trying to resolve regarding the TZ environment variable not being set in many linux systems and how this causes PEAR::Date to blow up when in DST.

Have similar experiences? Feel free to comment here since his ezPublish comments don’t work for anonymous users.

PHP 5 Objects, Patterns, and Practice

Demian Turner — Mon, 11 Jul 2005 20:17:54 +0000

Ever wanted to post something for over a month and never found the time?

I recently read Matt Zandstra’s PHP 5 Objects, Patterns, and Practice and thought I’d say a few good words about it for those who haven’t been recommended yet. A lot of good PHP5 books have come out recently, eg something like PHP 5 Power Programming is an excellent resource for the finer points of charset issues, utf8 in PHP, timezone gotchas. But it’s quite unusual in PHP circles for a book to come out that gives overall sound advice on application design.

I found Matt, who comes from a Java background, really hit the nail on the head, this book is an enjoyable read. While the first few chapters make allowances for readers who don’t have a lot of exposure to OOP, the rest is quite a stimulating read, helped along in no small part by Matt’s excellent unambiguous writing style.

The book deals not only with all major components of a large application, but has a very nice section on the Composite pattern, and spends time looking at Phing, PEAR, and the Reflection API, among other things. The book finishes off with a parser project that brings together a lot of the concepts introduced in earlier chapters – I think even PHPers who consider themselves advanced will enjoy this. Matt apparently works for Yahoo in London.

HOWTO: working with PEAR

Demian Turner — Tue, 19 Apr 2005 12:13:49 +0000

Hello,

I’m posting this to clear up how to find the PEAR path on most servers, and then at the end are instructions how to use PEAR in your PHP programs.

Editors note: this article is for beginner to intermediate level users, and I think will be useful to many as reported problems installing PEAR are still widespread in the forums, etc. – Demian

DB portability Idea

Demian Turner — Thu, 10 Mar 2005 11:43:52 +0000

There’s quite an interesting article by Daniel Convissor, the maintainer of PEAR DB, on making a database schema portable across DB vendors. His approach is quite interesting, he uses customised meta tags to describe data types, then runs the meta-schema through a regex-replace script to produce native outputs for the target DB.

Advantages of using the PEAR class naming convention

Demian Turner — Wed, 09 Mar 2005 13:59:43 +0000

There are many good reasons for following the PEAR coding standards which I don’t have time to go into now, a slightly elabourated version of the ‘rules’ is available here, mostly borrowed from the Horde project.

But by far the most convincing reason to use the file naming convention, which means that a class located in your include path like Foo/Bar/Baz.php is called Foo_Bar_Baz, is the ability to take advantage of PHP 5’s __autoload magic method.

What this means is that if you instantiate the above class, and forgot to require it, it can be located and loaded automatically, from any of hundreds of classes in your include path. Here’s the code:

function __autoload($class)
{
  $filename = str_replace('_', '/', $class) . '.php';
  @require_once $filename;
}

Getting pearified with the PEAR Package Manager

Demian Turner — Wed, 09 Mar 2005 13:45:33 +0000

Not suprisingly a host of developments have cropped up following Greg Beaver’s successful release of PEAR 1.4, including a number of channels, and now pearified.com, as described by Robert Peake’s article.

If you are one of the majority of people answering ‘I don’t know what the PEAR package manager is’ at the survey below, please read up on this exciting technology and help raise the bar for PHP application deployment.