PHPDeveloper.orghttp://www.phpdeveloper.org
Up-to-the Minute PHP News, views and communityen-usTue, 31 Mar 2015 13:11:04 -050030http://www.phpdeveloper.org/news/22515http://www.phpdeveloper.org/news/22515
The SitePoint PHP blog has a new post today from Daniel Berman (of Zend) with the top 10 features of Z-Ray to be sure to check out. Disclaimer: Z-Ray is a tool provided by Zend, a part of their Zend Server product.

Necessity is the mother of invention goes the famous saying. For PHP developers, there is no greater need than visibility. But developers today have a tough choice to make as they develop and debug their apps. Either use crude methods such as printing, debugging information, or storing it in a log file, or - use multiple debugging/profiling tools that are awkward and require a lot of work from the developer's side. [...] This article introduces the top 10 features of Z-Ray - an innovative new technology from Zend that makes PHP development a whole lot quicker and easier by giving developers unprecedented insight into their code - and the visibility they need to develop top-notch apps.

Among the items on their Top 10 list are things like:

Viewing information about page requests

Execution time and memory consumption

Showing errors and warnings

Viewing functions called during execution

Debugging features for mobile apps and APIs

Check out the full post for a list of more features and screenshots/detail on each one.

Link: http://www.sitepoint.com/top-10-z-ray-features-check/]]>Thu, 26 Mar 2015 09:50:23 -0500http://www.phpdeveloper.org/news/22459http://www.phpdeveloper.org/news/22459
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.

Link: http://programmingarehard.com/2015/03/05/structing-my-application-contd.html]]>Mon, 09 Mar 2015 12:03:16 -0500http://www.phpdeveloper.org/news/22417http://www.phpdeveloper.org/news/22417
Zend recently introduced their Z-Ray inspection tool that allows you to see inside your application and know what's happening in your code, your database and has support for major PHP projects. In this new post to their blog they show you how to develop a custom extension for the Z-Ray system.

One of the coolest features in Z-Ray is the ability to plug in your own extensions. Meaning, you can customize existing Z-Ray panels or add your own personalized Z-Ray panel for displaying information you think is important for developing your specific application. This short tutorial will describe how to write a basic extension for Z-Ray. More specifically, we'll be writing a Z-Ray extension for WordPress that extracts and displays a list of loaded WordPress plugins.

They give you a list of things you'll need to set up before you can get started including a simple WordPress installation on a Zend Server instance. With these in place they help you create the "zray.php" file to define the extension, how to enable it and setting up a "trace" on a function to hook it into the execution. They then dump the WP plugin information and reformat it a bit to show only the list of names and versions in the output panel. As a last touch, they add a logo to the panel to show in the bottom menubar with the WordPress logo.

Link: http://blog.zend.com/2015/02/25/developing-z-ray-extension]]>Wed, 25 Feb 2015 11:54:41 -0600http://www.phpdeveloper.org/news/22384http://www.phpdeveloper.org/news/22384
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).

Link: http://akrabat.com/slim-framework/routing-to-a-controller-with-slim-framework/]]>Wed, 18 Feb 2015 10:19:08 -0600http://www.phpdeveloper.org/news/21506http://www.phpdeveloper.org/news/21506
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.

Link: http://www.masterzendframework.com/servicemanager/accessing-servicemanager-services-controller-plugins]]>Thu, 31 Jul 2014 09:43:49 -0500http://www.phpdeveloper.org/news/21363http://www.phpdeveloper.org/news/21363
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.

Link: http://www.masterzendframework.com/views/change-layout-controllers-actions-zend-framework-2]]>Fri, 27 Jun 2014 10:07:20 -0500http://www.phpdeveloper.org/news/21323http://www.phpdeveloper.org/news/21323
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.

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".

Link: http://php-and-symfony.matthiasnoback.nl/tags/controller/]]>Thu, 19 Jun 2014 09:45:34 -0500http://www.phpdeveloper.org/news/21317http://www.phpdeveloper.org/news/21317
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.

Link: http://php-and-symfony.matthiasnoback.nl/2014/06/how-to-create-framework-independent-controllers/]]>Wed, 18 Jun 2014 09:15:16 -0500http://www.phpdeveloper.org/news/21284http://www.phpdeveloper.org/news/21284
In his most recent postMatthew 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.

Link: http://mwop.net/blog/2014-06-09-controllers-as-facades.html]]>Tue, 10 Jun 2014 09:53:21 -0500http://www.phpdeveloper.org/news/21188http://www.phpdeveloper.org/news/21188
In this new post to his site Stephan Hochdörfer covers some of his own thoughts about the recently proposed application structure from Paul Jones, the "Action-Domain-Response" pattern. In this post Stephan compares the typical controller classes with an action class.

First of all I do have the feeling that controller classes make it harder to structure your logic. I have seen a lot of "God Controllers" that do a shitload of stuff. Stuff that is not really related to each other. [...] action classes tend to be rather small, typically less than 100 loc for us. That also helps a lot when trying to understand what`s going on. I am aware that there are developers out there who are afraid when it comes to dealing with a lot of classes. [...] That`s another bonus point for action classes: It is easier to search for a class name than a method name in most IDEs.

He goes on to talk more about "God controller" classes, their dependencies and how that compares to action classes only taking in what they need. He touches on the reusability of action classes as opposed to controllers and how they come in handy for storing common logic.