Developing a plugin using DI and TDD 17

Handling the reset all request.

What’s this all about?

This post moves on the step by step development of a simple votes plugin using dependency injection and test-driven development.
The posts alone might not be as interesting without a peek at the plugin code and probably a skim over the first post in the series and the following ones.
Tools of the trade are DI52 to handle PHP 5.2 compatible dependency injection, Codeception and wp-browser to handle the testing.

Reset all

While the front-end side of the post control has been taken care of on the back-end side there is still no piece of code handling any of those requests.
I will start implementing the handler of the request to reset all the votes on a post.
Doing so will require the registration of a new endpoint in the idlikethis_ServiceProviders_Endpoints service provider

class idlikethis_ServiceProviders_Endpoints extends tad_DI52_ServiceProvider
{

    /**
     * Binds and sets up implementations.
     */
    public function register()
    {
        $this->container->set_var('endpoints-namespace', 'idlikethis/v1');

        $this->container->singleton('idlikethis_Endpoints_AuthHandlerInterface', 'idlikethis_Endpoints_AuthHandler');
        $this->container->singleton('idlikethis_Repositories_CommentsRepositoryInterface', 'idlikethis_Repositories_CommentsRepository');
        $this->container->singleton('idlikethis_Endpoints_ButtonClickHandlerInterface', 'idlikethis_Endpoints_ButtonClickHandler');
        $this->container->singleton('idlikethis_Endpoints_ResetAllHandlerInterface', 'idlikethis_Endpoints_ResetAllHandler');

        add_action('rest_api_init', array($this, 'register_endpoints'));
    }

    public function register_endpoints()
    {
        $namespace = $this->container->get_var('endpoints-namespace');

        register_rest_route($namespace, '/button-click', array(
            'methods' => 'POST',
            'callback' => array($this->container->make('idlikethis_Endpoints_ButtonClickHandlerInterface'), 'handle'),
        ));

        register_rest_route($namespace, '/admin/reset-all', array(
            'methods' => 'POST',
            'callback' => array($this->container->make('idlikethis_Endpoints_ResetAllHandlerInterface'), 'handle'),
        ));
    }

    /**
     * Binds and sets up implementations at boot time.
     */
    public function boot()
    {
        // TODO: Implement boot() method.
    }
}

and with it the creation of the handler.
Along with it its unit tests and the functional tests to make sure the chain of classes that will have to handle the request will play along.
It’s nothing completely different from the previously implemented vote click handler and builds on that foundation of code and tests to get the job done.

Extending the comments repository

The “votes” for a post are currently stored as comments associated to the post itself.
An aptly named idlikethis_Repositories_CommentsRepository class abstracts reading and writing operations to an object-oriented layer other classes, handlers typically, will be able to use.
The comments repository, as the name implies, relies on votes being stored as comments and contains, in itself, an implementation binding that’s not posing a limit to the code infrastructure now but might do in the future.
To keep the implementation as flexible as possible I’ve renamed the idlikethis_Repositories_CommentsRepositoryInterface itself to idlikethis_Repositories_VotesRepositoryInterfaceand its methods to “generalize” the approach.
All the while the idlikethis_Repositories_CommentsRepository class has been augmented to accommodate the newly needed method to reset all votes on a post; with it its tests.
I’ve not taken the road to extend, in class inheritance terms, the comments repository class or interface as the functions added, and those that will be added next, still fall fully into its responsibility.

Next

I will handle the votes consolidation request then.

I appreciate your input