Looking for more information on how to do PHP the right way? Check out PHP: The Right Way

NetTuts.com:
Understand Overriding in Magento: Controllers
Jul 24, 2015 @ 11:19:45

The NetTuts.com site has posted a tutorial (the third and last in their series) showing how to override controller handling in Magento. In the previous posts they showed how to override functionality related to the models and blocks (frontend layout elements).

In Magento, the controller is responsible for handling incoming requests, and it's a backbone of the Magento routing implementation. [...] As I said in the previous tutorial, it's never recommended to change core files directly, as it makes upgrading Magento really difficult. To avoid this, we should follow the standard way of making desired changes to core files: we should either use event observers or override core files with our custom module files. We'll discuss the overriding feature today.

You'll need to be familiar with custom module creation to be able to follow along (see here if not) but other than that they provide everything you'll need. They start by creating the files and folders needed for the custom module including:

  • Module XML definition (Envato_All.xml)
  • Module XML configuration
  • the Envato_Catalog_ProductController controller file (PHP)

The controller extends the pre-existing Product controller but the configuration definitions tell it ti use the "Envato" version instead.

tagged: magento overriding controller tutorial custom xml module

Link: http://code.tutsplus.com/tutorials/understand-overriding-in-magento-controllers--cms-23386

Graze.com Tech Blog:
Sharing Controller Logic with Traits in PHP
Apr 24, 2015 @ 08:53:48

On the Graze.com Tech blog there's a recent post about sharing logic between controllers with the help of traits. He makes use of the traits functionality in PHP to abstract out functionality common to multiple controllers (in his case, common user functionality).

There have been a few times I have come across a situation where I need to share some logic between controllers but it hasn't been as clear cut as abstracting that logic out into a library. I've been pondering the best way to tackle this problem and would like to share my thoughts.

In his example he shows how two different controllers, the Account and Signup controllers, both need to be able to look up an address and perform some simple checks on the results. The logic is duplicated so he first tries to move it out to an abstract controller but notes that it's not the most ideal solution. Next he tries moving the code out into a library but finds issues with separating out the necessary concerns. Finally he moves the logic into a trait (AddAddressTrait) that contains it and allows the direct integration of his "lookupPostalCode" method into the controller without inheritance or other design issues.

tagged: controller logic sharing traits tutorial library inheritance

Link: http://tech.graze.com/2015/04/14/sharing-controller-logic-with-traits-in-php/

Dracony:
Replacing controllers with middleware
Apr 01, 2015 @ 09:53:50

Dracony has a new post to his site that suggests replacing controllers with middleware and how it relates to some of the current controller practices.

Middleware is now a very popular topic in the PHP community, here are some of my thoughts on the subject. [...] The idea behind it is “wrapping” your application logic with additional request processing logic, and then chaining as much of those wrappers as you like. So when your server receives a request, it would be first processed by your middlewares, and then after you generate a response it will also be processed by the same set.

After giving a few examples of what could be a good fit for use as middleware, he makes the suggestion to replace controllers. He talks about some of the problems that middleware brings with it and how to turn things around and write controllers as middleware (and not wrap them in it). He finishes with a mention of the work being done on PSR-7 (the HTTP Request proposal) and some thoughts on how it could fit into his middleware ideas.

tagged: middleware controller replacement opinion psr7 http

Link: http://dracony.org/replacing-controllers-with-middleware/

Programming Are Hard:
Structuring my applications, Cont'd
Mar 09, 2015 @ 12:03:16

The Programming Are Hard site continues its look at structuring Symfony-based applications in part two (it's just two parts) building on the structure and foundation laid out in part one.

It really irks me when I see some design/architecture decisions other developers have made but there's no technical explanation. What packages did they use? What challenges did they face? What trade-offs were made? I'll go over some more specifics in this post.

He recaps some of the things covered in the previous post first, ensuring everyone is on the same page. He then gets into the concept of "bundles" and how they encapsulate functionality. From there he talks about commands, controllers, dependency injection and lots of other topics, each with their own summary and a bit of code where needed for clarification.

tagged: structuring application symfony bundle command controller di form provider repository resource serialize

Link: http://programmingarehard.com/2015/03/05/structing-my-application-contd.html

Rob Allen:
Routing to a controller with Slim
Feb 18, 2015 @ 10:19:08

Rob Allen has a new post today sharing an extension for Slim he's written to make working with controllers easier.

In a couple of projects that I've written using Slim Framework, I've found it beneficial to organise my code into controllers with injected dependencies; probably because that's how I'm used to working with ZF2. To make this easier, I've written an extension to the main Slim class and packaged it into rka-slim-controller which will dynamically instantiate controllers for you for each route.

His library makes it easy to define controller "paths" instead of the typical closures Slim requires to direct the request to a controller file. He gives several example routes, the code that the controller needs and shows how you can inject objects into the constructor of the controller (dependency injection).

tagged: slimframework slim library route controller dependency injection

Link: http://akrabat.com/slim-framework/routing-to-a-controller-with-slim-framework/

Master Zend Framework:
Accessing ServiceManager Services in Controller Plugins
Jul 31, 2014 @ 09:43:49

Matthew Setter has posted another new tutorial to his Master Zend Framework site today showing you how to access ServiceManager services in controller plugins. Controller plugins are a Zend Framework feature that allows certain events to trigger the plugin code during the lifetime of the controller.

I’ve seen some questions on Google+ and StackOverflow of late, regarding how to get access to the Zend Framework 2 database adapter, along with other ServiceManager-defined services, in a custom controller plugin. This type of setup can come in handy for a number of situations. You may want to access services such as caching, logging or databases and want to provide a simple interface for doing so. People seem really interested in how to do it, but how to get access to services from the ServiceManager doesn’t seem to be as clear as it could be. Gladly, there’s not much involved in actually doing it.

He shows you how to create a plugin for an existing module, creating the two needed classes and adding a new function to configure it. He starts with the plugin factory that can be used to generate an instance of the plugin. Next is the plugin class itself that extends the abstract plugin and controller plugin classes. The required database adapter is injected into it via a constructor injection. Finally, in the Module.php configuration, he creates a "getControllerPluginConfig" method that registers the new plugin and points to its class. A screencast is also provided showing the active development of the code.

tagged: servicemanager plugin controller tutorial access zendframework2

Link: http://www.masterzendframework.com/servicemanager/accessing-servicemanager-services-controller-plugins

Master Zend Framework:
Change Layout in Controllers and Actions in Zend Framework 2
Jun 27, 2014 @ 10:07:20

Matthew Setter has a new post to his Master Zend Framework site today showing you how to change layouts in controllers and actions for a Zend Framework v2 based application.

In Zend Framework 2, if you want to change the layout just for one action or for every action in a controller, how do you do it? How do you do it without overriding the layout for every action throughout the entire application? In today’s post, based on an excerpt from Zend Framework 2 for Beginners, we see how to achieve both of these requirements.

He talks about the framework's use of the two-step view pattern and what the "template_map" definition usually looks like in a default ZF2 application. He shows three different ways to do the view switching from the controller or action:

  • Override the default layout in your module
  • Override the layout per/action
  • Override the layout per/controller

Each of these comes with a bit of code showing you how to make it work. They move from simplest to more complex, with the layout per controller being the most complex. It's not that it's difficult, it's just that there's more involved to make it work. You can either do it at the controller level or at the module level.

tagged: tutorial zendframework2 controller action change ayout

Link: http://www.masterzendframework.com/views/change-layout-controllers-actions-zend-framework-2

Matthias Noback:
Symfony2: Framework independent controllers parts 2 & 3
Jun 19, 2014 @ 09:45:34

Matthias Noback has posted the next two parts of his "framework independent controllers" series (it started here) looking at avoiding annotations and tying up some loose ends.

From part two about annotations:

In the previous part of this series we decreased coupling of a Symfony controller to the Symfony2 framework by removing its dependency on the standard Controller class from the FrameworkBundle. Now we take a look at annotations. They were initially introduced for rapid development (no need to create/modify some configuration file, just solve the issues inline!) [...] This might not seem such a big problem at all, but the SensioFrameworkExtraBundle is a bundle, which means it only works in the context of a Symfony2 application. We don't want our controller to be coupled like this to the framework (at least, that is the point of this series!), so we need to remove the dependency.

He shows how to decouple this functionality through a proper routing configuration, fetching the needed data yourself for the request and generating the request object yourself. In part three he covers some of the comments already made about the series and how to take the final steps to abstracting out the controllers: removing bundle names from templates, removing the HttpFoundation dependency and letting go of "action methods".

tagged: controller independent symfony series part2 part3

Link: http://php-and-symfony.matthiasnoback.nl/tags/controller/

Matthias Noback:
Symfony2: How to create framework independent controllers?
Jun 18, 2014 @ 09:15:16

Matthias Noback has a new post to his site today, the first part of a series, looking at making framework-independent controllers for use in a Symfony2 framework-based project.

The general belief is that controllers are the most tightly coupled classes in every application. Most of the time based on the request data, they fetch and/or store persistent data from/in some place, then turn the data into HTML, which serves as the response to the client who initially made the request. [...] In this post I demonstrate that this high level of coupling is definitely not necessary. I will show you how you can decrease coupling a lot by taking some simple steps. We will end with a controller that is reusable in different types of applications, e.g. a Silex application, or even a Drupal application.

In this first part he focuses on a few places where the common practices lead to some unnecessary coupling between the controller and framework:

  • Using the framework helper methods
  • Using dependency injection (manually injecting instead)
  • Making the controller a service instead

The next post in the series will look at the use of annotations and how to refactor them out of the controller to remove yet another coupling point.

tagged: framework independent controller symfony2 tutorial refactor decouple

Link: http://php-and-symfony.matthiasnoback.nl/2014/06/how-to-create-framework-independent-controllers/

Matthew Weier O'Phinney:
Better Understanding Controllers Through Basic Patterns
Jun 10, 2014 @ 09:53:21

In his most recent post Matthew Weier O'Phinney shares his own spin on the Action-Domain-Responder pattern (from Paul Jones): how the controllers in the ARD setup could be explained as facades.

Paul M. Jones has started an interesting discussion rethinking the MVC pattern as applied to the web, which he has dubbed Action-Domain-Responder (ADR). If you haven't given it a read yet, click the link and do that; this page will still be sitting here waiting when you return. I agree with a ton of it - heck, I've contributed to it a fair bit via conversations with Paul. But there's been one thing nagging at me for a bit now, and I was finally able to put it into words recently. Controllers - Actions in ADR - can be explained as facades.

Matthew starts off by defining the Facade design pattern with a quote from the infamous "Gang of Four" book: simply put, a simplified interface to a complex system. He provides a basic example of a facade that wraps some common steps for inserting and logging data with this kind of simplified interface. He applies this to the ADR pattern's controllers, pointing out that it handles a few complex steps "behind the scenes" common to marshaling and managing the request.

For me, thinking of Controllers and Actions as Facades has an additional benefit: it describes rather complex architectural patterns in terms of basic design patterns. I find the more I can reduce the complexity of a definition, the more likely I will understand and use it correctly.
tagged: controller designpattern adr action domain responder facade

Link: http://mwop.net/blog/2014-06-09-controllers-as-facades.html