News Feed
Sections




News Archive
feed this:

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

Matthias Noback:
Decoupling your (event) system
August 26, 2014 @ 11:15:17

Matthias Noback has continued his look at event handling in PHP applications (well, Symfony-related ones at least) in his latest post. In this latest post he focuses more on abstracting out the event handling process and decoupling it from your application as much as possible.

You are creating a nice reusable package. Inside the package you want to use events to allow others to hook into your own code. You look at several event managers that are available. [...] Introducing this dependency is not without any problem: everybody who uses my/package in their project will also pull in the [event dispatcher] package, meaning they will now have yet another event dispatcher available in their project (a Laravel one, a Doctrine one, a Symfony one, etc.). This doesn't make sense, especially because event dispatchers all do (or can do) more or less the same thing.

As mentioned, he focuses in on the Symfony ecosystem and the event handlers commonly used there. He talks about some of the disadvantages of the Symfony EventDispatcher and how its interface can lead to code bloat due to it's verbosity (flexibility?). He talks about its violations of the Interface Segregation Principle and how he would structure the listener setup and handling if he was starting from scratch. To this end, he's created an adapter that wraps around an EventDispatcher interface and works with objects for the different kinds of events rather than the string names.

0 comments voice your opinion now!
decouple event manager dispatch handling symfony adapter object

Link: http://php-and-symfony.matthiasnoback.nl/2014/08/symfony2-decoupling-your-event-system/

Johannes Schlüter:
PHP 5.3 - Thanks for all the Fish
August 15, 2014 @ 09:42:56

Johannes Schlüter has a new post on his site today saying "so long and thanks for all the fish" to the PHP 5.3.x series of releases. With PHP 5.3.29 being released yesterday, that marks the end of the release cycle for the 5.3 series. He takes a bit to look back and reflect on how far things have come during the 5.3.x series, its history and his role as the release master.

PHP 5.3's history starts somewhere in 2005. We knew what a pressure point of PHP was - a language made for solving The Web Problem needs a good Unicode story. [...] As this was a big and pressing issue and the need was obvious and the solution looked promising it was quickly areed on making that the base for a future PHP 6. And then time passed, initial enthusiasm passed and the sheer amount of work became obvious. Two years in we noticed that the ongoing PHP 6 work blocked other work - new features couldn't be added to 5.2, the current version at that time, and adding them to (at that time) CVS's HEAD.

He talks about Lukas Smith getting involved as the "co-release manager" for the series and the contribution he made to the project. He mentions the over five thousand commits and around eighty people that contributed to the releases and the over ten thousand files that were changed. Major features were introduced during this series including namespacing, anonymous functions, goto and late static binding. He also talks more meta about the process the PHP development follows and how things changed over the 29 bugfix releases in the 5.3.x series.

Thank you Johannes and Lukas for all that you've done to get PHP 5.3 to where it is today and your work ensuring the introduction of these major features made it out in a timely manner.

0 comments voice your opinion now!
release manager retrospective php53 language bugfix

Link: http://schlueters.de/blog/archives/178-PHP-5.3-Thanks-for-all-the-Fish.html

SitePoint Web Blog:
From Developer to Product Manager A 3 Stage Plan
August 13, 2014 @ 11:55:34

As some developers move on in their careers, they start to progress more towards a management role. Sometimes this comes in the form of a "product manager" since most of their knowledge is wrapped around the product(s) they've been working on. However, making the move up from developer to product manager can be a difficult transition. In this new post to the SitePoint Web blog, Ernest Sliter tries to help with his own three-stage advice.

It's certainly not uncommon for developers or other employees serving in technical roles to eventually transition to product management. Some developers may find they enjoy managing the product road map and solving customers' problems rather than writing code and building the product themselves. Other seasoned engineers may be searching for a suitable career transition into a management position. If you're interested in moving to product management in the future, here are three critical steps to make the transition.

For each of his steps he provides a summary of what the choice or action entails and includes a few sub-points that can help:

  • Decide Whether You're Right for Product Management
  • Expand Your Knowledge of Product Management
  • Take Action!
0 comments voice your opinion now!
developer product manager advice threestage plan

Link: http://www.sitepoint.com/developer-product-manager-3-stage-plan/

PEAR Blog:
PEAR 1.9.5 is out
July 14, 2014 @ 11:09:24

The PEAR blog has posted a new announcement about the latest release of the PEAR PHP package manager, version 1.9.5.

The PEAR installer version 1.9.5 has been released today. The new version - three years after the last stable 1.9.4 and 2 weeks after the preview - is a bugfix only release. 13 bugs have been fixed.

Fixes include things dealing with broken Windows pathing and a change to report the correct php.ini setting for the installed XDebug.

0 comments voice your opinion now!
pear package manager release bugfix

Link: http://blog.pear.php.net/2014/07/12/pear-1-9-5/

SitePoint PHP Blog:
Building and Processing Forms in Symfony 2
June 06, 2014 @ 13:45:07

The SitePoint PHP blog has a new tutorial posted from author Daniel Sipos about form handling in Symfony2. More specifically, about creating them and handling the results from their submission. This is an introduction to the topic and gets into two examples, one focusing on a view implementation and the other using the form builder.

In this tutorial we will look at two examples of using forms in Symfony 2. In the the first, we will place form elements straight in the View file and then handle the form processing manually in the controller. In the second, we'll use the Symfony form system to declare forms in an object oriented way and have Symfony process and persist the values. We will be working on a simple installation of the Symfony framework.As you may know, it comes with a default bundle called AcmeDemoBundle and we will use that to illustrate working with forms.

In the first example he looks at "non-entity forms" and shows how to create the form from normal HTML elements in the view. The form is just a simple input field and a submit button. He includes the code you'll need to process the form submission too. In the second example he includes an example of how to create the same setup but using the Form Builder instead. It's also links it to a data object, making it simpler to save the submission results.

0 comments voice your opinion now!
symfony2 form processing view builder entity manager tutorial

Link: http://www.sitepoint.com/building-processing-forms-in-symfony-2

Hannes Magnusson:
I have a dream
May 26, 2014 @ 09:23:54

In his latest post Hannes Magnusson describes his "dream" about a future for PHP where things like upgrading and working with extensions would be simpler, faster and more manageable.

Today we will revolutionize PHP. We will make it easier to upgrade the things you care about. We will make it easier to not upgrade things you don't want to upgrade. We will make it easier to distribute your extensions. We will make it easier to release according to your own schedule. We will make it easier to add functionality. We will make it easier to work. Ok, today is a white lie here maybe... I haven't actually implemented this, but bare with me here for a second.

With the introduction and huge growth of Composer, the PEAR package manager is fading in popularity and is slowly being abandoned. Unfortunately, it's still the primary mechanism for deploying and installing PHP extensions (PECL packages). He talks about some of his recent experience reviving a package and issues he had around the use of the packaging manager. He proposes the creation of a new "pecl install" tool - a package manager dedicated to PHP extensions, decoupled from PEAR.

The manager would just install basic PHP then leave it up to you to pick which features you need from there. The idea is still in its early stages, but the idea has taken roots and plans are being worked through to see if this idea will work for the future of the language.

0 comments voice your opinion now!
pear pecl future language package manager extension

Link: http://bjori.blogspot.com/2014/05/i-have-dream.html

Matthias Noback:
Inject a repository instead of an entity manager
May 19, 2014 @ 11:04:30

Matthias Noback has made a recommendation in his latest post about using a repository rather than an entity manager in your classes to inject dependencies.

It appears that I didn't make myself clear while writing about entity managers and manager registries yesterday. People were quick to reply that instead you should inject entity repositories. However, I wasn't talking about entity repositories here. I was talking about classes that get an EntityManager injected because they want to call persist() or flush(). The point of my previous post was that in those cases you should inject the manager registry, because you don't know beforehand which entity manager manages the entities you are trying to persist. By injecting a manager registry you also make your code useful in contexts where another Doctrine persistence library is used.

He suggests that more classes actually need a repository and not an entity manager to work with necessary objects. He also points out how the use of an entity manager can sometimes violate the Law of Demeter. He includes some code showing a refactoring away from an entity manager and towards a repository. He also has an example of a custom repository class based on the domain logic object types. In addition he talks about repository interfaces, resetting closed entity managers and "criteria" objects.

0 comments voice your opinion now!
repository entity manager doctrine refactor example

Link: http://php-and-symfony.matthiasnoback.nl/2014/05/inject-a-repository-instead-of-an-entity-manager/

Master Zend Framework:
Howto Handle External Form Element Dependencies with FormElementManager
April 22, 2014 @ 11:58:07

The Master Zend Framework site has posted a tutorial wanting to help you understand external form element dependencies with help from FormElementManager.

Zend Framework 2, like all great PHP frameworks, provides thorough infrastructure for creating forms in your application. Whether that's form objects, form elements, fieldsets, validation groups or that they interact with so many other components in the Zend Framework 2 default libraries. But how do you handle external dependencies? [...] So what if you need a custom form element in your application, one which will render a list of articles from a database table? [...] In today's post, we're going to look at how to create such a custom element, extending the existing select element.

He walks you through the steps you'll need to make the custom element and hook it into the FormElementManager for correct use:

  • Create a New Form Element
  • Implement the getFormElementConfig Method
  • Create a New Form Object
  • Instantiate the Form Via the FormElementManager

Code is included for each step of the way so you can ensure you end up with a working example.

0 comments voice your opinion now!
external form manager element dependencies external tutorial

Link: http://www.masterzendframework.com/zend-form/handle-external-form-element-dependencies-with-formelementmanager

Wojciech Sznapka:
Injecting repositories to service in Symfony2
October 17, 2013 @ 11:45:54

Wojciech Sznapka has an interesting new post to his site today talking about injecting repositories into services in Symfony2-based applications. By injecting just a single repository instead of the entire EntityManager, you get a cleaner, more clear interface defined in the code.

It is generally a good idea to wrap business logic into services. Often, such services methods uses doctrine's repositories to operate on data storage. Injecting whole EntityManager service is very popular approach, but it isn't the most elegant way I could think of. EntityManager works only as a factory in that case and could lead to usage of other repositories, which might end up with too many responsibilities of given service.

He includes some code to illustrate his point - both a "services.xml" configuration of the related dependency injection container and a custom entity repository (defined in the config). He then shows how this repository (FooRepository) would be injected into the service (FooService) via constructor injection.

0 comments voice your opinion now!
symfony2 repository injection configuration tutorial entity manager

Link: http://blog.sznapka.pl/injecting-repositories-to-service-in-symfony2/

Reddit.com:
Composer still susceptible to remote code execution via MITM
October 03, 2013 @ 11:26:15

In this recent post to Reddit.com, a point is brought up about the popular PHP package manager, Composer about it being susceptible to a common attack called the "Man in the Middle". This issue on the project's Github repository talks more about it:

Composer runs code from HTTP sources without validating the source of the download or the code downloaded. As such, trivial man-in-the-middle attacks through any number of vectors (dns, networking, local server exploit, etc) will result in execution of code of an attackers choosing at the userlevel of the user running composer. (Typically a developer account)

Replace getcomposer.org for a given network perspective by replacing it with a malicious http instance (eg by changing the DNS locally, at the lan, at an isp or hosting provider dns resolver, or globally or equally easily by replacing a route to the legitimate server (eg arpspoof)) . The http server instance is configured to serve a malicious /composer.phar and a /version url that produces random data. When users run self-update, the malicious code will be downloaded and run as the user that is executing the self-update command.

As of yet some patches and ideas have been proposed to correct this issue, but it hasn't been resolved and is currently listed as a "blocker" on the project. One suggestion, signing packages, seems to be the front-runner in the current discussion, something that package managers for other languages have already implemented (like npm for Node.js and pip for Python).

0 comments voice your opinion now!
composer package manager remote code execution attack maninthemiddle mitm

Link: http://www.reddit.com/r/PHP/comments/1nkmw8/composer_still_susceptible_to_remote_code/


Community Events





Don't see your event here?
Let us know!


application deployment laravel zendserver introduction code language conference developer tips framework development api podcast community list interview release series threedevsandamaybe

All content copyright, 2014 PHPDeveloper.org :: info@phpdeveloper.org - Powered by the Solar PHP Framework