Sam minds Some Zend Framework 2 knowledge

Refactoring Bad Code using ZF2 – AbstractOptions

Jul 24

Hey everyone, it’s been a very long time since I’ve last been able to write something for you. Sorry about that! Today I’ll be talking to you about something that has come up lately. I’ve been working on a big project with a lot of people. We had an API-kinda class that handles soap Requests between an internal and an external Server. This class required many different URLs. Those URLs additionally had to be different for several staging setups. This quickly became very messy and I decided to refactor the configuration aspect of that class using the AbstractOptions class from Zend\Stdlib . Let me show you an example of said service class:

<?php
namespace Foo\Bar;

class WebService
{
    public function __construct(
        SomeService $httpConnectService,
        $validateUrlForX, //string
        $validateUrlForY, //string
        $validateUrlForZ  //string
    ) {
        // doStuff()
    }
}

<?php

namespace Foo\Bar;

class WebService

{

public function __construct(

SomeService $httpConnectService,

$validateUrlForX, //string

$validateUrlForY, //string

$validateUrlForZ //string

) {

// doStuff()

}

In this example we have a Service-Class that requires an instance of SomeService as well as three string parameters that represent several URLs the service will call from separate functions. Now I’ve mentioned that several staging setups required different configurations, so for example we have this setup:

Local:
    $urlX = 'http://foo.dev'
Testing:
    $urlX = 'http://testing.foo.de'
Staging:
    $urlX = 'http://random.whatever.com'
Production:
    $urlX = 'http://foo.org'

Local:

$urlX = 'http://foo.dev'

Testing:

$urlX = 'http://testing.foo.de'

Staging:

$urlX = 'http://random.whatever.com'

Production:

$urlX = 'http://foo.org'

I suppose you get the idea. This was the case for all URLs. Now with just three parameters like that it wouldn’t be too bad. We had 15 once I joined the project. By now we’re above 20… And worse of all, with many people working on one class over GIT we actually had troubles keeping up the correct order of things. It was a simple mistake to make to switch up two variables in the middle of the constructor. You know, adding each new variable to the end of the constructor is far too mainstream

Anyways, we came to the conclusion that this setup is horrible, so what can you do? The answer is as simple as the final implementation. You use an Object that stores all these configuration parameters and you simply inject that Object into the class wherever you need this. ZF2 provides us with a very nice base-class that we can use: AbstractOptions

Build your Options class

The first thing to refactor this messy setup was to create the options class. For the sake of simplicity I will stick to just the three configuration parameters that I’ve used in the example above.

<?php
namespace Foo\Bar;

use Zend\Stdlib\AbstractOptions;

class WebServiceOptions extends AbstractOptions
{
    protected $validateUrlForX;
    protected $validateUrlForY;
    protected $validateUrlForZ;

    public function getValidateUrlForX() { return $this->validateUrlForX; }
    public function getValidateUrlForY() { return $this->validateUrlForY; }
    public function getValidateUrlForZ() { return $this->validateUrlForZ; }

    public function setValidateUrlForX($url) { $this->validateUrlForX = $url; }
    public function setValidateUrlForY($url) { $this->validateUrlForY = $url; }
    public function setValidateUrlForZ($url) { $this->validateUrlForZ = $url; }
}

<?php

namespace Foo\Bar;

use Zend\Stdlib\AbstractOptions;

class WebServiceOptions extends AbstractOptions

{

protected $validateUrlForX;

protected $validateUrlForY;

protected $validateUrlForZ;

public function getValidateUrlForX() { return $this->validateUrlForX; }

public function getValidateUrlForY() { return $this->validateUrlForY; }

public function getValidateUrlForZ() { return $this->validateUrlForZ; }

public function setValidateUrlForX($url) { $this->validateUrlForX = $url; }

public function setValidateUrlForY($url) { $this->validateUrlForY = $url; }

public function setValidateUrlForZ($url) { $this->validateUrlForZ = $url; }

}

The next thing in line would be to properly set-up your configuration. Setting up the config files properly will not only make the implementation of the AbstractOptions much easier, it will also increase the read-ability of your code by a lot. Let’s look at my example:

<?php
// module.config.php
return [
    'foobar' => [
        'validate_url_for_x' => 'http://x.foo.dev',
        'validate_url_for_y' => 'http://y.foo.dev',
        'validate_url_for_z' => 'http://z.foo.dev',
    ]
];

<?php

// module.config.php

return [

'foobar' => [

'validate_url_for_x' => 'http://x.foo.dev',

'validate_url_for_y' => 'http://y.foo.dev',

'validate_url_for_z' => 'http://z.foo.dev',

]

];

As you can see we have set up an config array with the top level namespace of our module. Inside that sub-array are key-value-pairs set up with the key being underscore-separated value names. We do this so that AbstractOptions will have an easy time to match the config-keys to our WebServiceOptions protected properties.

Now we need to find a way to bring those config values into our object. We do this by using a Factory-Class for our WebServiceOptions. Create it like this:

<?php
namespace Foo\Bar;

use Zend\ServiceManager\FactoryInterface;
use Zend\ServiceManager\ServiceLocatorInterface;

class WebServiceOptionsFactory implements FactoryInterface
{
    public function createService(ServiceLocatorInterface $serviceLocator)
    {
        $config = $serviceLocator->get('config');

        if (isset($config['foobar'])) {
            return new WebServiceOptions($config['foobar']);
        }

        return new WebServiceOptions();
    }
}

<?php

namespace Foo\Bar;

use Zend\ServiceManager\FactoryInterface;

use Zend\ServiceManager\ServiceLocatorInterface;

class WebServiceOptionsFactory implements FactoryInterface

{

public function createService(ServiceLocatorInterface $serviceLocator)

{

$config = $serviceLocator->get('config');

if (isset($config['foobar'])) {

return new WebServiceOptions($config['foobar']);

}

return new WebServiceOptions();

}

With this set up the configuration array passed into the WebServiceOptions class will be read from the AbstractOptions base-class which in turn will set the protected properties based on the configuration array. It’s magic, good magic!

Now let’s refactor the Service class and finish the configuration of the factories:

    <?php
    namespace Foo\Bar;

    class WebService
    {
        public function __construct(
            SomeService       $httpConnectService,
            WebServiceOptions $options
        ) {
            // doStuff
        }
    }

<?php

namespace Foo\Bar;

class WebService

{

public function __construct(

SomeService $httpConnectService,

WebServiceOptions $options

) {

// doStuff

}

We also need to modify the factory class for this Service:

<?php
namespace Foo\Bar;

use Zend\ServiceManager\FactoryInterface;
use Zend\ServiceManager\ServiceLocatorInterface;

class WebServiceFactory
{
    public function createService(ServiceLocatorInterface $serviceLocator)
    {
        return new WebService(
            $serviceLocator->get('SomeService'),
            $serviceLocator->get('WebServiceOptions')
        );
    }
}

<?php

namespace Foo\Bar;

use Zend\ServiceManager\FactoryInterface;

use Zend\ServiceManager\ServiceLocatorInterface;

class WebServiceFactory

{

public function createService(ServiceLocatorInterface $serviceLocator)

{

return new WebService(

$serviceLocator->get('SomeService'),

$serviceLocator->get('WebServiceOptions')

);

}

Let’s quickly take a look at the configuration for the factories as well:

<?php
// module.config.php
return [
    'foobar' => [
        'validate_url_for_x' => 'http://x.foo.dev',
        'validate_url_for_y' => 'http://y.foo.dev',
        'validate_url_for_z' => 'http://z.foo.dev',
    ],
    'service_manager' => [
        'factories' => [
            'WebService'        => 'Foo\Bar\WebServiceFactory',
            'WebServiceOptions' => 'Foo\Bar\WebServiceOptionsFactory'
        ]
    ]
];

<?php

// module.config.php

return [

'foobar' => [

'validate_url_for_x' => 'http://x.foo.dev',

'validate_url_for_y' => 'http://y.foo.dev',

'validate_url_for_z' => 'http://z.foo.dev',

'service_manager' => [

'factories' => [

'WebService' => 'Foo\Bar\WebServiceFactory',

'WebServiceOptions' => 'Foo\Bar\WebServiceOptionsFactory'

]

];

Using the AbstractOptions

With all of this set up you’ll now be able to use the configuration you need within your Service-class. Just to mention this, this kind of OptionsClass can be used anywhere you need configuration. It is not restricted solely to services. But let’s see how we will use the config:

<?php
namespace Foo\Bar;

class WebService
{
    protected $httpConnectService;
    protected $options;

    public function __construct(
        SomeService       $httpConnectService,
        WebServiceOptions $options
    ){
        $this->httpConnectService = $httpConnectService;
        $this->options            = $options;
    }

    public function doSomethingCrazy()
    {
        $this->httpConnectService->connect(
            $this->options->getValidateUrlForX()
        );

        $this->httpConnectService->connect(
            $this->options->getValidateUrlForY()
        );

        $this->httpConnectService->connect(
            $this->options->getValidateUrlForZ()
        );
    }
}

<?php

namespace Foo\Bar;

class WebService

{

protected $httpConnectService;

protected $options;

public function __construct(

SomeService $httpConnectService,

WebServiceOptions $options

){

$this->httpConnectService = $httpConnectService;

$this->options = $options;

}

public function doSomethingCrazy()

{

$this->httpConnectService->connect(

$this->options->getValidateUrlForX()

);

$this->httpConnectService->connect(

$this->options->getValidateUrlForY()

);

$this->httpConnectService->connect(

$this->options->getValidateUrlForZ()

);

}

And just like this we have cleaned up the class and have a super useful options class that we cna inject anywhere we need this configuration. One thing however isn’t very optimal yet. It may happen that no proper configuration is provided. You have two ways to make sure there’s always config available. The first one would be to make sure that default values are always provided within your modules module.config.php, this is what we have done in this example here.

The other way would be to set the default values inside the Options class itself. This is the approach that personally I do prefer. You’d do it as simple as this:

<?php
namespace Foo\Bar;

use Zend\Stdlib\AbstractOptions;

class WebServiceOptions extends AbstractOptions
{
    protected $validateUrlForX = 'http://foo.dev';
    protected $validateUrlForY = 'http://y.foo.de';
    protected $validateUrlForZ = 'http://foo.org';

    public function getValidateUrlForX() { return $this->validateUrlForX; }
    public function getValidateUrlForY() { return $this->validateUrlForY; }
    public function getValidateUrlForZ() { return $this->validateUrlForZ; }

    public function setValidateUrlForX($url) { $this->validateUrlForX = $url; }
    public function setValidateUrlForY($url) { $this->validateUrlForY = $url; }
    public function setValidateUrlForZ($url) { $this->validateUrlForZ = $url; }
}

<?php

namespace Foo\Bar;

use Zend\Stdlib\AbstractOptions;

class WebServiceOptions extends AbstractOptions

{

protected $validateUrlForX = 'http://foo.dev';

protected $validateUrlForY = 'http://y.foo.de';

protected $validateUrlForZ = 'http://foo.org';

public function getValidateUrlForX() { return $this->validateUrlForX; }

public function getValidateUrlForY() { return $this->validateUrlForY; }

public function getValidateUrlForZ() { return $this->validateUrlForZ; }

public function setValidateUrlForX($url) { $this->validateUrlForX = $url; }

public function setValidateUrlForY($url) { $this->validateUrlForY = $url; }

public function setValidateUrlForZ($url) { $this->validateUrlForZ = $url; }

}

And that’s it. Whenever you have new options available, all you need to do is write a new protected property within the Options class, add setter and getter functions for it and you’re done. No more messing around with constructors is required. When UnitTesting the class, you won’t ever have to inject 20+ configuration options into the class just to get the test working.

Even if this may not have been the only problems with said class, this little change already improved the life of everyone working with the class. We have improved the consistency of our configuration and cleaned up the constructor of this one class. And all that took was 10 Minutes of time which in the future will safe us hours. And could have saved many hours if we would have done so from the start.

Anyways, I hope that you’ll be able to make use of this information in the future and I promise to be writing a little bit more in the near future again! Until then, take care everyone, happy coding!

Setting up a development-environment on Windows

Apr 12

Ever since I posted my first installation tutorial for Zend Framework 2 a lot of things have changed. Composer has become much more awesome and PHP 5.4s internal webserver has become widely known. Due to all these changes I’ve wanted to do a video tutorial for quite a while now which finally I managed to do. Please leave me lots of feedback so I can improve for future video guites.

ZF3 Status Update Hangout #1 – Wrap Up

Nov 06

The first Hangout from the Roave team is done and the guys have given some great insight into the thoughts behind Zend Framework 3 (ZF3). In case you missed the talk – or if you just want to get a quick overview about what has been talked about – you’re at the right place. I am going to wrap up the whole talk and try to sum it up in a few lines what the keynotes have been.
Read More…

Understanding Zend Framework 3 … before it’s out!

Oct 30

Hey guys! Everyone knows how important it is to understand the concepts of a framework to truly use it at it’s best. With Zend Framework 2 (ZF2) a lot of people coming from Zend Framework 1 (ZF1) were shocked at first. So many new concepts, so many new buzzwords and more importantly what’s the need behind all those. ZF2 was a big step forward and by now a lot of people have gotten accustomed to the way ZF2 works and why it does so.

While ZF2 is a great Framework there are still a couple of things that are just not ideal. A little example would be that a lot of people use $this->getServiceLocator() inside their Controllers. While this is OK, it’s actually considered bad practice. The way things are looking right now, this feature will be removed in Zend Framework 3 (ZF3) to basically force people to use proper dependency injection using the ServiceManager.

And that’s what this post is all about actually. ZF3 is not close around the corner. It’s still many, many months ahead. But there are reasons why you should bother and get information about ZF3 as soon as possible. If you understand why changes are introduced – and most of them are explained, some will be explained at a later point i guess – then you can spot errors in todays code already! You can improve your current code by knowing what’s going to be “in” a couple of months away.

Zend Framework 3 on Google Moderator

One way to follow the development is to keep track of the discussions for Zend Framework 3 Ideas on Google Moderator. Not only will you be able to keep track and understand coming changes, you can actually do something against it! Does something sound just not right to you? Counter-Argument and downvote! ZF3 as much as ZF2 is a Community-Project and if the absolute majority of the community is against a change, chances are quite high that a change won’t happen.

ZF3 Tagged Issues on GitHub + Wiki

Probably the most technical information you can get is available right inside the ZF2-Repository over at GitHub. All Issues / PRs with the Tag ZF3 are about the very topic of introducing or debate about changes happening within the development of Zend Framework 3. This would be the ideal place for you to get involved with the actual ZF3-Development.

Aside from the issues on GitHub, there’s also a Wiki-Entry which lists a lot of the changes in a little more comprehensive format. More specifically, it lists up all the bc-breaks that are happening, so wisely read those! Thanks to Bakura for pointing that out.

Google Hangouts for Zend Framework 3

This actually is the core of this Blogpost. Just today i learned about a great Project that some of the great minds behind Zend Framework started. Marco <Ocramius> Pivetta, Evan <EvanDotPro> Coury and Ben <DaspriD> Scholzen will be holding a regular series of Live-Videos / Hangouts where the will be talking about the current status of development of ZF3. They will be highlighting some of the core changes and give reasons for why they are doing so. In addition to that you will be able to ask live-questions via chat at #zftalk.dev @freenode.net

I can only suggest to you guys to follow at least those hangouts. This will be roughly an hour worth of your time to understand Zend Framework 3 before it’s even out!

Follow the Hangouts here: Zend Framework 3 Status Hangouts. The first one will be held at November 6th at 15:00 UTC. Mark you calendars guys!

Understanding ZF2 Configuration

Apr 08

In Zend Framework 2 we no longer have the commanding application.ini, instead we got the option to configure our website or rather the modules on a per-module-basis. Furthermore, the modules are able to overwrite each others configuration. With this in mind, it makes it even more important to understand how ZF2 manages the configuration files of several modules internally. In this blog i will guide you guys through the internal process of the framework.
Read More…

Zend\Form\Element\Select and Database Values

Mar 22

One of the most common questions currently is how one is able to populate a Zend\Form\Element\Select with data from the database. In this blog I am going to demonstrate to you guys how you can achieve this using three different ways. First will be the very barebone way using Zend\Db\Adapter\AdapterInterface, another way will be using the Zend\Db\TableGateway\TableGatewayInterface and the third option to make this possible using a Doctrine\Common\Persistence\ObjectManager.
Read More…

ZfcUser, BjyAuthorize and Doctrine working together

Mar 16

Hey there, this will be the starting blog of my series for developing a full application. In this part i will cover one of the core features of basically every application there is: Authentication, Authorization and DB-Connectivity. Since with ZF2 the wheel doesn’t have to get re-invented over and over again, there already are great modules out there, that do the job. They may not be applicable 100% to even my current needs, but they can be extended. And that’s what we’ll be going to do at a later time. For now, all we’re going to do is make these modules work well together.
Read More…

Coming content for this blog

Feb 23

Everyone, I’m back! I wasn’t able to write a lot of post in those past three months due to personal reasons, but I’m back and I’ve brought some goodies. I have something nice planned for the coming months and I’m here to let you guys know. I have planned for teaching you guys a couple of basic stuff for ZF2-Projects, providing sources from a real application. Please read the full article if you’re interested in the detailled topics that will be posted within the next weeks.
Read More…

ZF2 Performance QuickTipp #2 – Classmap Autoloading

Nov 11

When it comes to any framework, the autoloading of classes is a huge concern. One of the first goals on ZF2s roadmap has been to get rid of all those require_once() statements inside the code to improve the overall performance. Taking a look at the ZendSkelettonApplication we can see inside Module.php, that the autoloading is done by several classes. The default approach most developers are using is with using Zend\Loader\StandardAutoloader. This is good and fine and serves it’s purpose, but if we take a closer look at the performance, a huge increase in speed can be achieved. In this blog i will tell you about the Zend\Loader\ClassMapAutoloader and what massive speed increase you can account with it.
Read More…

Using the ZF2 classmap_generator utility

Nov 11

In this blogpost i will give you a quick introduction of how to make use of the classmap_generator.php / classmap_generator.php.bat shipped within Zend Framework 2s bin directory. This handy little tool will safe you a lot of time and help to increase your applications performance quite a bit.
Read More…

1 2 Next Scroll to top

Sam minds

Some Zend Framework 2 knowledge

Refactoring Bad Code using ZF2 – AbstractOptions

Build your Options class

Using the AbstractOptions

Setting up a development-environment on Windows

ZF3 Status Update Hangout #1 – Wrap Up

Understanding Zend Framework 3 … before it’s out!

Zend Framework 3 on Google Moderator

ZF3 Tagged Issues on GitHub + Wiki

Google Hangouts for Zend Framework 3

Understanding ZF2 Configuration

Zend\Form\Element\Select and Database Values

ZfcUser, BjyAuthorize and Doctrine working together

Coming content for this blog

ZF2 Performance QuickTipp #2 – Classmap Autoloading

Using the ZF2 classmap_generator utility

Recent Posts

Recent Comments

Blogroll

Archives