Sam minds

Dependent Select Lists in ZF2

Jan 20

Hey everybody, one need many people have is to make <select>-Lists dependent on each other. No matter what website you’re running, chances are that you use <select>-lists that depend on each other as well. While this is mainly an aspect of proper usage of JavaScript, many people don’t know how to prepare their HTML Elements using ZF2 in a way that they are able to properly being used by their JS-Libraries. This blog-post demonstrates how to achieve this goal.

Different Strategies

There are two common ways to make select lists dependent on each other. The first one would be to make an AJAX-Request against your web-server whenever someone selects an entry within the first list. This request would then return JSON-Data that contains the information for the second, depending, list to populate. You would choose this option when the full range of values for the second list is very large. Since – in my experience – lists are rarely as large as that, we will not cover this option in this blog-post. However rest assured that after reading this blog-post you’ll have all the knowledge you need to make this strategy happen, should you require it.

The other option would be to populate the second list with all possible data that can be selected. You would then simply hide all elements (using JavaScript) that are incompatible with the selection of the first select list. This approach is very handy, very fast and easy to follow. So let’s get it started!

All the magic you need to know

First off we’re going to create a Form that contains two select lists with some dependent data. As you will see shortly, the example will be very simple to follow as we’re mainly just grouping numbers within respective ranges.

class FormWithTwoSelects extends Form
{
    public function init()
    {
        $this->add([
            'type'       => 'select',
            'name'       => 'parent',
            'attributes' => [
                'id'    => 'select-parent',
                'class' => 'form-control'
            ],
            'options'    => [
                'label'         => 'Parent Select',
                'empty_option'  => '-- please make a selection --',
                'value_options' => [
                    ['value' => 1, 'label' => '00 - 09', 'attributes' => ['data-key' => '0x']],
                    ['value' => 2, 'label' => '10 - 19', 'attributes' => ['data-key' => '1x']],
                    ['value' => 3, 'label' => '20 - 29', 'attributes' => ['data-key' => '2x']],
                ]
            ]
        ]);

        $this->add([
            'type'       => 'select',
            'name'       => 'child',
            'attributes' => [
                'id'    => 'select-child',
                'class' => 'form-control'
            ],
            'options'    => [
                'label'         => 'Child Select',
                'empty_option'  => '-- choose parent first --',
                'value_options' => [
                    ['value' => 0, 'attributes' => ['data-key' => '0x'], 'label' => 'zero'],
                    ['value' => 1, 'attributes' => ['data-key' => '0x'], 'label' => 'one'],
                    ['value' => 2, 'attributes' => ['data-key' => '0x'], 'label' => 'two'],
                    ['value' => 3, 'attributes' => ['data-key' => '0x'], 'label' => 'three'],
                    ['value' => 4, 'attributes' => ['data-key' => '0x'], 'label' => 'four'],
                    ['value' => 5, 'attributes' => ['data-key' => '0x'], 'label' => 'five'],
                    ['value' => 6, 'attributes' => ['data-key' => '0x'], 'label' => 'six'],
                    ['value' => 7, 'attributes' => ['data-key' => '0x'], 'label' => 'seven'],
                    ['value' => 8, 'attributes' => ['data-key' => '0x'], 'label' => 'eight'],
                    ['value' => 9, 'attributes' => ['data-key' => '0x'], 'label' => 'nine'],
                    ['value' => 10, 'attributes' => ['data-key' => '1x'], 'label' => 'ten'],
                    ['value' => 11, 'attributes' => ['data-key' => '1x'], 'label' => 'eleven'],
                    ['value' => 12, 'attributes' => ['data-key' => '1x'], 'label' => 'twelve'],
                    ['value' => 13, 'attributes' => ['data-key' => '1x'], 'label' => 'thirteen'],
                    ['value' => 14, 'attributes' => ['data-key' => '1x'], 'label' => 'fourteen'],
                    ['value' => 15, 'attributes' => ['data-key' => '1x'], 'label' => 'fifteen'],
                    ['value' => 16, 'attributes' => ['data-key' => '1x'], 'label' => 'sixteen'],
                    ['value' => 17, 'attributes' => ['data-key' => '1x'], 'label' => 'seventeen'],
                    ['value' => 18, 'attributes' => ['data-key' => '1x'], 'label' => 'eighteen'],
                    ['value' => 19, 'attributes' => ['data-key' => '1x'], 'label' => 'nineteen'],
                    ['value' => 20, 'attributes' => ['data-key' => '2x'], 'label' => 'twenty'],
                    ['value' => 21, 'attributes' => ['data-key' => '2x'], 'label' => 'twenty-one'],
                    ['value' => 22, 'attributes' => ['data-key' => '2x'], 'label' => 'twenty-two'],
                    ['value' => 23, 'attributes' => ['data-key' => '2x'], 'label' => 'twenty-three'],
                    ['value' => 24, 'attributes' => ['data-key' => '2x'], 'label' => 'twenty-four'],
                    ['value' => 25, 'attributes' => ['data-key' => '2x'], 'label' => 'twenty-five'],
                    ['value' => 26, 'attributes' => ['data-key' => '2x'], 'label' => 'twenty-six'],
                    ['value' => 27, 'attributes' => ['data-key' => '2x'], 'label' => 'twenty-seven'],
                    ['value' => 28, 'attributes' => ['data-key' => '2x'], 'label' => 'twenty-eight'],
                    ['value' => 29, 'attributes' => ['data-key' => '2x'], 'label' => 'twenty-nine'],
                ]
            ]
        ]);

        $this->add([
            'type'       => 'submit',
            'name'       => 'submit',
            'attributes' => [
                'value' => 'submit'
            ]
        ]);
    }
}

class FormWithTwoSelects extends Form

{

public function init()

{

$this->add([

'type' => 'select',

'name' => 'parent',

'attributes' => [

'id' => 'select-parent',

'class' => 'form-control'

'options' => [

'label' => 'Parent Select',

'empty_option' => '-- please make a selection --',

'value_options' => [

['value' => 1, 'label' => '00 - 09', 'attributes' => ['data-key' => '0x']],

['value' => 2, 'label' => '10 - 19', 'attributes' => ['data-key' => '1x']],

['value' => 3, 'label' => '20 - 29', 'attributes' => ['data-key' => '2x']],

]

]);

$this->add([

'type' => 'select',

'name' => 'child',

'attributes' => [

'id' => 'select-child',

'class' => 'form-control'

'options' => [

'label' => 'Child Select',

'empty_option' => '-- choose parent first --',

'value_options' => [

['value' => 0, 'attributes' => ['data-key' => '0x'], 'label' => 'zero'],

['value' => 1, 'attributes' => ['data-key' => '0x'], 'label' => 'one'],

['value' => 2, 'attributes' => ['data-key' => '0x'], 'label' => 'two'],

['value' => 3, 'attributes' => ['data-key' => '0x'], 'label' => 'three'],

['value' => 4, 'attributes' => ['data-key' => '0x'], 'label' => 'four'],

['value' => 5, 'attributes' => ['data-key' => '0x'], 'label' => 'five'],

['value' => 6, 'attributes' => ['data-key' => '0x'], 'label' => 'six'],

['value' => 7, 'attributes' => ['data-key' => '0x'], 'label' => 'seven'],

['value' => 8, 'attributes' => ['data-key' => '0x'], 'label' => 'eight'],

['value' => 9, 'attributes' => ['data-key' => '0x'], 'label' => 'nine'],

['value' => 10, 'attributes' => ['data-key' => '1x'], 'label' => 'ten'],

['value' => 11, 'attributes' => ['data-key' => '1x'], 'label' => 'eleven'],

['value' => 12, 'attributes' => ['data-key' => '1x'], 'label' => 'twelve'],

['value' => 13, 'attributes' => ['data-key' => '1x'], 'label' => 'thirteen'],

['value' => 14, 'attributes' => ['data-key' => '1x'], 'label' => 'fourteen'],

['value' => 15, 'attributes' => ['data-key' => '1x'], 'label' => 'fifteen'],

['value' => 16, 'attributes' => ['data-key' => '1x'], 'label' => 'sixteen'],

['value' => 17, 'attributes' => ['data-key' => '1x'], 'label' => 'seventeen'],

['value' => 18, 'attributes' => ['data-key' => '1x'], 'label' => 'eighteen'],

['value' => 19, 'attributes' => ['data-key' => '1x'], 'label' => 'nineteen'],

['value' => 20, 'attributes' => ['data-key' => '2x'], 'label' => 'twenty'],

['value' => 21, 'attributes' => ['data-key' => '2x'], 'label' => 'twenty-one'],

['value' => 22, 'attributes' => ['data-key' => '2x'], 'label' => 'twenty-two'],

['value' => 23, 'attributes' => ['data-key' => '2x'], 'label' => 'twenty-three'],

['value' => 24, 'attributes' => ['data-key' => '2x'], 'label' => 'twenty-four'],

['value' => 25, 'attributes' => ['data-key' => '2x'], 'label' => 'twenty-five'],

['value' => 26, 'attributes' => ['data-key' => '2x'], 'label' => 'twenty-six'],

['value' => 27, 'attributes' => ['data-key' => '2x'], 'label' => 'twenty-seven'],

['value' => 28, 'attributes' => ['data-key' => '2x'], 'label' => 'twenty-eight'],

['value' => 29, 'attributes' => ['data-key' => '2x'], 'label' => 'twenty-nine'],

]

]);

$this->add([

'type' => 'submit',

'name' => 'submit',

'attributes' => [

'value' => 'submit'

]

]);

}

As you can see we’re hard-coding some values here that are tightly grouped together. We have three different ranges of numbers (00-09, 10-19, 20-29) as well as all numbers from zero to twenty-nine in the second list. The magic happening here that many people don’t know about is the assignment of the value_options. Most people only know about value_options like this:

'value_options' => [
    'key1' => 'value1',
    'key2' => 'value2',
    // etc...
]

'value_options' => [

'key1' => 'value1',

'key2' => 'value2',

// etc...

]

However there is a much more powerful way to do this. In essence those value_options are all elements that will be rendered as an <option> element. And as such it is able to hold attributes as well. Therefore, instead of providing an array of key=>value pairs, we’re providing an array of array-elements. Each element defining a single rendered option-element. For example:

'value_options' => [
    ['value' => 1, 'label' => '00 - 09', 'attributes' => ['data-key' => '0x']],
    ['value' => 2, 'label' => '10 - 19', 'attributes' => ['data-key' => '1x']],
    ['value' => 3, 'label' => '20 - 29', 'attributes' => ['data-key' => '2x']],
]

'value_options' => [

['value' => 1, 'label' => '00 - 09', 'attributes' => ['data-key' => '0x']],

['value' => 2, 'label' => '10 - 19', 'attributes' => ['data-key' => '1x']],

['value' => 3, 'label' => '20 - 29', 'attributes' => ['data-key' => '2x']],

]

In the above example we assign value options in the more complex way. Each element has a value and a label like usual. The relation is as simple as key=>value equals value=>label. However as an addition we also add some attributes to each element that contains our wanted data-attribute (data-key). And with this information the rest is simply some small piece of JavaScript to get the front-end working.

Working the front-end

As mentioned previously, most of the work for dependent select lists is done by JavaScript. Here is how you would do it using the provided backend-sample:

$(function() {
    var parent = $('#select-parent');
    var child  = $('#select-child');
    var deps   = child.children('option');

    parent.on('change', function(){
        var selectedKey = $(this).children(':selected').data('key');

        // Hide all Elements
        deps.css('display', 'none');

        // Show empty Element
        $(deps[0]).css('display', 'block');

        // Show all related elements based on selectedKey
        child.children('option[data-key="'+selectedKey+'"]').css('display', 'block');
        //                ^--   ---^
        // There may be a better selector but it works. JS isn't my strongest of suits ;)
    })
})

$(function() {

var parent = $('#select-parent');

var child = $('#select-child');

var deps = child.children('option');

parent.on('change', function(){

var selectedKey = $(this).children(':selected').data('key');

// Hide all Elements

deps.css('display', 'none');

// Show empty Element

$(deps[0]).css('display', 'block');

// Show all related elements based on selectedKey

child.children('option[data-key="'+selectedKey+'"]').css('display', 'block');

// ^-- ---^

// There may be a better selector but it works. JS isn't my strongest of suits ;)

})

What’s happening here is pretty simple. To start out we have two select lists that contain many option-elements. All of those elements are visible. Now whenever someone selects anything from the first list, we then are going to hide all elements on the second list. We re-enable the first element of the second list, which basically is the empty_option and furthermore we enable all elements of the second list where the data-key matches the one selected within the first list. And that’s really all there is to it.

Security Considerations

Now with all beautiful front-end stuff there usually come some security implications. For example what happens if the user has turned off JavaScript? Of course you could make your website absolutely REQUIRE JavaScript but – even today – that’s not the best thing to do. The advantage of this approach here is that the form does work without JavaScript enabled.

However inside our database it would be weird to have an entry for the range “00-09″ with the value “22”. Therefore on the PHP Side of things, or rather within ZF2, we have to find a way to also validate our select list combination. In my experience this is best done using the Zend\Validator\Callback . Here is how you would use the validator in a simplified way:

public function getInputFilterSpecification()
{
    return [
        'child' => [
            'validators' => [
                ['name' => 'callback', 'options' => [
                    'callback' => function ($value, $context) {
                        /**
                         * !!! IMPORTANT !!!
                         * !!! In a real-life-scenario you would likely do a database query here to find out if the
                         * !!! value of the second select-list is allowed within the scope of the first select list.
                         * !!! IMPORTANT !!!
                         *
                         * $value             = Value of #select-child
                         * $context['parent'] = Value of #select-parent
                         *
                         * We simplify this with an inline-array-map
                         */
                        $allowedMapping = [
                            1 => [0, 1, 2, 3, 4, 5, 6, 7, 8, 9],
                            2 => [10, 11, 12, 13, 14, 15, 16, 17, 18, 19],
                            3 => [20, 21, 22, 23, 24, 25, 26, 27, 28, 29],
                        ];

                        return in_array($value, $allowedMapping[$context['parent']]);
                    }
                ]]
            ]
        ]
    ];
}

public function getInputFilterSpecification()

{

return [

'child' => [

'validators' => [

['name' => 'callback', 'options' => [

'callback' => function ($value, $context) {

/**

* !!! IMPORTANT !!!

* !!! In a real-life-scenario you would likely do a database query here to find out if the

* !!! value of the second select-list is allowed within the scope of the first select list.

* !!! IMPORTANT !!!

* $value = Value of #select-child

* $context['parent'] = Value of #select-parent

* We simplify this with an inline-array-map

$allowedMapping = [

1 => [0, 1, 2, 3, 4, 5, 6, 7, 8, 9],

2 => [10, 11, 12, 13, 14, 15, 16, 17, 18, 19],

3 => [20, 21, 22, 23, 24, 25, 26, 27, 28, 29],

];

return in_array($value, $allowedMapping[$context['parent']]);

}

]]

]

];

}

As pointed out within the comment block, there’s no way you would hard-code such validation. Any real-life-scenario will always have a database check of the given combination. Doing this is as simple but the additional dependencies for the form would make this quick tutorial overly complex.

The most interesting aspect of the callback validator is the use of the $context which is basically a reference to the whole form. Using this you’re able to access all element-values from the form and therefore you’re able to validate the selected value against some haystack.

Working Repository

I’ll always welcome any questions or feedback regarding this matter. If you’d like to see a full working example, I have set one up on my GitHub account for you guys to check out.
manuakasam/tutorial-dependent-select-lists @ GitHub

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…

1 2 Next Scroll to top

Some Zend Framework 2 knowledge

Dependent Select Lists in ZF2

Different Strategies

All the magic you need to know

Working the front-end

Security Considerations

Working Repository

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

Recent Posts

Recent Comments

Blogroll

Archives