News Feed

News Archive
feed this:

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

Symfony Blog:
New in Symfony 2.7 Twig as a First-Class Citizen
January 15, 2015 @ 13:16:18

The Symfony blog has a new post about a change coming in the next version of the popular PHP framework - treating Twig as a first-class citizen. This update removes the abstraction layer that was introduced for it to be used in templating.

When I started to work on Symfony2, Twig didn't exist. Anyway, to ease using PHP as a templating engine, I created the Symfony Templating Component. Later on, not very satisfied with using PHP as a templating language, I decided to create a new templating language, Twig, based on the Python Jinja2 language. And Symfony2 became the first popular framework to adopt a non-PHP templating engine in core. [...] But what would Twig as a First-Class Citizen mean in Symfony2 then? To be able to support PHP and Twig in Symfony, we added an abstraction layer. [...] For Symfony 3.0, I'd like to extract the Templating Component into an independent library (for the few people using PHP with Symfony) but I'd also like for Twig to be front and center in the framework. The good news is that most of the work has already been done in Symfony 2.7.

He compares the two methods for using Twig, one in 2.6 and the other in 2.7, showing both the reduction in code needed and the overall speed improvement gained by removing the excess layer. He includes a link to the reports showing the difference in the metrics with a total of 48 classes less to load just by removing this layer.

0 comments voice your opinion now!
symfony twig firstclass citizen templating abstraction performance


Matthew Weier O'Phinney:
On HTTP, Middleware, and PSR-7
January 09, 2015 @ 11:38:17

Matthew Weier O'Phinney has a new post to his site today with a thought about how to make the Zend Framework (both ZF1 & ZF2) easier for developers to get into and use. He suggests that middleware might be the answer.

As I've surveyed the successes and failures of ZF1 and ZF2, I've started considering how we can address usability: how do we make the framework more approachable? One concept I've been researching a ton lately is middleware. Middleware exists in a mature form in Ruby (via Rack), Python (via WSGI), and Node (via Connect / ExpressJS); just about every language has some exemplar. Even PHP has some examples already, in StackPHP and Slim Framework.

[...] The idea is that objects, hashes, or structs representing the HTTP request and HTTP response are passed to a callable, which does something with them. You compose these in a number of ways to build an application.

He gives some examples of current frameworks and libraries that make use of the middleware idea, showing both object and callable methods. He points out that, while middleware is approachable and makes a developer's life easier, it's not something PHP can internally handle. He covers the things a PHP developer would need to access just to get the complete details about a HTTP request and that what's really needed is good HTTP abstraction handling, something the PHP-FIG group has been working on as a part of PSR-7. He includes some examples of how it might be used and where middleware would fit into the picture.

Too often, I feel as PHP developers we focus on the tools we use, and forget that we're working in an HTTP-centric ecosystem. [...] If PSR-7 is ratified, I think we have a strong foot forward towards building framework-agnostic web-focused components that have real re-use capabilities -- not just re-use within our chosen framework fiefdoms.
0 comments voice your opinion now!
middleware http psr7 abstraction language handling


Anthony Ferrara:
A Beginner's Guide To MVC For The Web
November 24, 2014 @ 10:42:41

Anthony Ferrara has posted what he calls a beginners guide to MVC for the web, a tutorial that introduces to you the basic concepts behind the Model-View-Controller design pattern and how it should fit in with the SOLID design principles.

There are a bunch of guides out there that claim to be a guide to MVC. It's almost like writing your own framework in that it's "one of those things" that everyone does. I realized that I never wrote my "beginners guide to MVC". So I've decided to do exactly that. Here's my "beginners guide to MVC for the web".

He starts with his first lesson, his most important one really - you don't need "MVC" (the concept, not the pattern...he notes them differently). He then gets into what the MVC pattern actually is and describes each piece and how they fit together. Following that, he talks about "MVC" as a concept and how it's different from MVC, the design pattern (hint: the pattern describes one implementation of the MVC ideals). He talks about the role of state in the MVC structure and how the implementation of the MVC idea is slightly different in the various "MVC frameworks" out there.

There is a very useful lesson that MVC brings: Separation Of Concerns. Meaning that you should separate different responsibilities into different sections of your application. Separation of Concerns is a necessary step in dealing with Abstraction. Instead of latching on to MVC, latch on to abstraction. Latch on to separation of concerns. Latch on to architecture. There are far better ways to architect and abstract user interaction for server-based applications than MVC.
0 comments voice your opinion now!
beginner guide mvc modelviewcontroller designpattern concept solid abstraction


Mathias Verraes:
Resolving Feature Envy in the Domain
August 12, 2014 @ 11:55:24

Mathias Verraes has a new post today about something he calls "feature envy" in the domain, related to this code smell (based on a definition from Martin Fowler).

Benjamin Eberlei did a really nice job of explaining refactoring the Feature Envy code smell on his blog. I wrote a comment because I felt the example could be taken one step further. You should read the original post. Below are Benjamin's code examples (for reference), followed by a repost of my comment.

The "smell" is defined as "a method that seems more interested in a class other than the one it's in". Mathias includes the code examples from the other post showing a datetime calculation and how it could be abstracted out to another class and method. He talks about the migration and how it relates to the "Whole Value" pattern and integrating some of the logic into a factory, generating a "reporting period" instance. He finishes the post with a brief look at an application of domain-driven design concepts to the problem, suggesting that the reporting be even more abstracted from the datetime data and using the "reporting period" object instead.

0 comments voice your opinion now!
feature envy whole value designpattern class object abstraction domaindriven


Mathias Verraes:
When to Use Static Methods
June 16, 2014 @ 10:20:52

Mathias Verraes has followed up his previous post about named constructors in PHP with a bit more clarification about when to use static methods (as he did in his "multiple constructor" examples previously).

Some of the reactions to my last blog post on Named Constructors in PHP, originate from the notion that static methods are inherently bad and should never be used. This is rather overgeneralized. Static methods are nothing more than namespaced global functions. Namespacing, I think we can all agree on, is great. As for global functions: We use those all the time. The native functions in PHP form our basic building blocks.

He talks about the main problem with their use, the shared global state, and compares it to a more stateful service. His solution is to either move to a normal object state (that allows for internal tracking) or think more about abstractions and how they relate.

0 comments voice your opinion now!
static methods opinion object stateless abstraction


Anthony Ferrara:
Beyond Design Patterns
September 19, 2013 @ 10:43:11

Anthony Ferrara has written up a new post that looks beyond design patterns. He suggests that more emphasis should be put on learning proper methods for abstraction and communication between objects and structures.

Many people teach design patterns as a fundamental step to Object Oriented Programming. They are so universally seen as important that almost every single conference that I have been to has had at least one talk about them. They are quite often used as interview questions to test a candidate's OOP knowledge. However, just like inheritance, they are not needed for OOP. And just like inheritance, they are a distraction rather than a foundation. Instead of focusing on patterns, I suggest focusing on learning about abstraction and communication.

He briefly covers the three types of patterns most people are introduced to - creational, structural and behavioral - and his suggestions of other patterns that answer more of the "what the problem is" question:

  • Shim patterns (Flyweight, Iterator, etc)
  • Compositional patterns (Adapter, Builder, Facade, etc)
  • Decompositional patterns (Bridge, Command, Mediator, etc)

He spends some time later in the post looking a bit more closely at four specific patterns, Adapter, Bridge, Facade and Proxy. He points out that they (essentially) do the same kind of thing and boils it down to a more refined set of implementation patterns and the problems they help solve.

0 comments voice your opinion now!
designpattern communication abstraction implementation problem

Avoid the Original MySQL Extension, Part 2
February 25, 2013 @ 13:40:09 has posted the second part of their "avoid the original MySQL extension" tutorial series (part one is here). In this new part, they share more about another alternative - the PDO extension.

The PDO extension supports twelve drivers, enabling it to connect to a variety of relational databases without the developer having to learn a number of different APIs. It does this by abstracting the database interaction calls behind a common interface, enabling the developer to utilize a consistent interface for different databases. This of course gives it a major advantage over both the MySQL and MySQLi extensions who are limited to only one database.

Included in the post are examples of some of the basics - connecting, executing queries, getting the results - as well as more compelx things like binding parameters and transaction support. There's also a bit about changing the default behavior of the PDO object through config options. He finishes off the article talking some about some of the issues that could come from using an abstraction layer like this and the need to still write good, compatible SQL depending on the database.

0 comments voice your opinion now!
mysql extension avoid pdo tutorial abstraction

Matthew Weier O'Phinney's Blog:
View Layers, Database Abstraction, Configuration, Oh, My!
March 06, 2012 @ 13:18:14

Matthew Weier O'Phinney (of the Zend Framework project) has posted an introduction to some new ZF2 features - view layers, abstraction and configuration updates.

Late last week, the Zend Framework community 2.0.0beta3, the latest iteration of the v2 framework. What have we been busy doing the last couple months? In a nutshell, getting dirty with view layers, database abstraction, and configuration.

He covers each topic well, providing code examples for all three - a simple view layer (more here), database abstraction functionality (inserting, selecting and TableGateway) and the configuration changes that allow for things like key translation, section inheritance and constant substitution.

0 comments voice your opinion now!
zendframework2 view layer database abstraction configuration beta3

Gonzalo Ayuso's Blog:
Database Abstraction Layers in PHP. PDO versus DBAL
July 12, 2011 @ 10:14:29

In this new post to his blog, Gonzalo Ayuso compares two technologies that can make working with databases in your applications simpler - PDO and the Doctrine2 DBAL layer.

In fact DBAL isn't a pure database abstraction layer. It's built over PDO. It's a set of PHP classes we can use that gives us features not available with 'pure' PDO. If we use Doctrine2 we're using DBAL behind the scene, but we don't need to use Doctrine2 to use DBAL. We can use DBAL as a database abstraction layer without any ORM. Obiously this extra PHP layer over our PDO extension needs to pay a fee. I will have a look to this fee in this post.

He includes a few simple benchmarking scripts that compare similar operations done by either, including memory usage and execution time. PDO comes out on top, obviously, because it's an extension versus a set of PHP libraries that need to be included in the application. He does include examples of a few things he likes that DBAL does that PDO doesn't by default - a transactional mode, type conversion, a simpler binding interface and the ability to nest transactions.

0 comments voice your opinion now!
database abstraction doctrine2 dbal pdo layer benchmark feature

Volker Dusch's Blog:
References suck! - Let's fix MySqli prepared statements!
June 14, 2011 @ 11:46:55

Volker Dusch has a new post to his blog looking at the use of references in PHP (or lack there of) and what we, as end users of the language, can do about it. His example looks at mysqli prepared statements.

Even so not every PHP Developers knows WHY we don't use references pretty much every core function and every somewhat modern framework avoids them so people adapted this best practice. The leftovers in the PHP core, like sort() or str_replace(), are exceptions to the rule. So if the common consensus is, or at least 'should be', that we should not use references then maybe we should start looking for places where they hurt and how we could fix them?

He talks about prepared statements and one thing he sees that makes it a "hard sell" to developers needing a good way to query their databases. He points out the difference in code required between the normal MySQL calls and mysqli (hint: it's more) and shows how to use an abstraction layer to make things a bit easier. He points out the downfalls of using this approach, mainly the performance hit you get (from using his fetchAll method).

0 comments voice your opinion now!
references mysqli prepared statement performance abstraction

Community Events

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

language laravel5 series psr7 opinion wordpress framework library conference development release introduction extension interview api community voicesoftheelephpant laravel unittest podcast

All content copyright, 2015 :: - Powered by the Solar PHP Framework