Use Laravel Contracts to Build a Laravel 5 Twig Package

Originally published at: http://www.sitepoint.com/use-laravel-contracts-build-laravel-5-twig-package/

Laravel 5 is finally out, and with all the awesome features it brings. One of the new architectural changes is the new Contracts Package. In this article we are going to understand the reasoning behind this change and try to build a practical use case using the new Contracts.

What Is a Contract

A contract is an interface that defines a behaviour. Let’s take this definition from [Wikipedia](https://en.wikipedia.org/wiki/Interface_(computing)#Software_interfaces_in_object-oriented_languages).

In object-oriented languages, the term interface is often used to define an abstract type that contains no data or code, but defines behaviors as method signatures.

With that being said, we use interfaces to extract the object behaviour from a class to an interface and only depend upon the definition. In Laravel’s IoC container you can bind an interface to an implementation.

$this->app->bind('App\Contracts\EventPusher', 'App\Services\PusherEventPusher');

Now every time you resolve the EventPusher interface from the container, you will receive a Pusher implementation. If you decide to switch to another service like Fanout, you only need to change the binding.

$this->app->bind('App\Contracts\EventPusher', 'App\Services\FanoutEventPusher');

Most of Laravel core services now are extracted to a contract, and if you want for example to override the Illuminate/Mail service, you can implement the Illuminate\Contracts\Mail contract and define the necessary methods and add it a s a provider.

Continue reading this article on SitePoint

Thanks for the informative post. I have some things I am a bit uncertain/ confused about.

If a contract is only the concept of an interface, why give an interface a different name with the term “contract”? Or is that the name given for the easy binding method Laravel offers?

Also the lines of code between the two “contracts” in your example of EventPusher and FanoutPusher(?) would need to be different somehow, wouldn’t they?

You say Blade offers its own methods for extension, then refer to the Twig Bridge. The one has nothing to do with the other, does it? Or does the Twig Bridge just hold one or more examples of a blade extension in it?

And is your use of the ViewFactory and View contracts the better way to build the actual Twig bridge? If yes, does that mean the version 0.7 of the Twig Bridge is a work around?

Last question, one of the strengths of Twig is its ability to compile the templates down to straight PHP files, which in turn can be cached in XCode caches like APC. Would this still be possible with your binding or even the Twig Bridge?

Thanks for any clarification in advance. :smile:

Scott

  • Its called Design by Contract pattern, and can be achieved using interfaces. So I’m using the term Contract when I’m referring to the pattern.
  • The EventPusher is a contract, and the FanoutEventPusher is an implementation (The actual logic for this service).
  • Blade has a mapping for extensions and compilers, so you can attach a view compiler to an extension.
  • .blade.php => Blade view compiler.
  • .twig => Twig view compiler.
    In this article, I’m not trying to extend Blade, I’m trying to replace it! You can read through TwigBridge source code if you still unsure.
  • I didn’t go through the source code of the 0.7 version, but just looking to the service provider you can see that it still extending it. I think changing the view system is a good use case to use contracts, but remember, when using TwigBridge you still have access to Blade.
  • I don’t know about TwigBridge, but its possible this way, because we didn’t change any Twig behavior.

I hope this clarifies your confusion :smile: Thanks

1 Like

This topic was automatically closed 91 days after the last reply. New replies are no longer allowed.