On PHPMaster.com today they've posted the first part of a series spotlighting Openbiz Cubi, a PHP "framework" with a business focus.

Openbiz Cubi is a robust PHP application framework giving developers the ability to create business applications with minimal effort. In this two-part series I'll explain the concepts and steps necessary to create your own business web applications with Cubi. We'll look first at the challenges web developers face and how Openbiz Cubi can help, and then how to install Cubi. In part 2 we'll see how to create our own modules.

They start off by describing the tool and some of the features that come with it (including user management and the XML data object structure). Complete installation instructions are included and a screenshot is included of the end result. They include a "quick tour" of Cubi's features and some of the modules that come with it like the System, Menu and User modules. In part two of the series, they'll show you how to create a custom module.

On PHPMaster.com today there's a new post from Daniel Gafitescu that compares CodeIgniter (an "old standby" in the PHP framework world) and Laravel, a relative newcomer. The article is broken up into a few different categories, with some sample code included to illustrate.

n the beginning of my career I stumble upon CodeIgniter and I love it for its simplicity, small footprint, and good documentation. [...] But last year, because of the Twitter buzz from some in the PHP community, blog posts, and the suggestions of some friends, I give Laravel 3 a try - and since that time I've never looked back. So, in this article I'd like to present a comparison of the two frameworks from my point of view.

He compares the two frameworks based on things like the requirements to get them installed, how they handle creating REST APIs, the general organization of their code (and your code using them) as well as command line support. There's a "miscellaneous" section that talks about some of the smaller differences and a (very) brief mention of the communities for each.

On his site today Lukasz Kujawa has a post that compares some performance benchmarks of several popular PHP frameworks including Slim, CodeIgniter, Laravel, Symfony2 and Zend Framework 2.

There are many assumptions around performance of different PHP frameworks. I frequently hear strong opinions about superiority X over Y in this context. There are companies writing new PHP frameworks from scratch because available solutions are too slow for them. What does it really mean? Does the framework performance matters? Before answering this questions lets check how slow is your framework!

He took the "quick start" projects provided for each of the examples and ran some tests with the Apache Benchmark (ab) tool against EC2 instances, all configured the same way. The results weren't overly surprising with Slim beating the others hands down (it's a micro-framework after all) and Kohana and CodeIgniter coming in second and third. The frameworks with more overhead like Zend Framework and Symfony ranked some of the slowest.

On Reddit's PHP section there's a discussion happening about dependency injection versus service locators in two popular PHP frameworks - Zend Framework 2 and Symfony 2 (and how they're not really DI at all).

Both ZF2 and Symfony 2 offer the same behavior: if I'm in a controller, and I want to use a service, I have to get it from the container with $this->get('my_service'). As such, the controller is not using DI, this is the service locator pattern. Controllers become more difficult to tests because of that, and they depend on the container now. I wonder why both frameworks didn't go further: why not treat controllers like services and use dependency injection on them. In other words: if a controller needs a service "A", then it should get it in the constructor, or through setter/property injection.

The comments talk some about the "controller from the DI container" idea, some other ways around the problem and some clarification as to what the frameworks are actually doing related to the container injection.

Fabien Potencier (of the Symfony framework) has a new post to his site talking about a philosophy that the Symfony framework community should work towards, providing stability over features.

Long story short: in the coming months, the Symfony core contributors should focus their efforts toward stabilizing the existing features instead of working on new ones. At this point, backward compatibility and stability are more important than everything else.

He highlights some of the points that come along with this effort including less refactoring for the sake of refactoring, fixing more bugs/edge cases and writing more tests/documentation. He gets into some of the specifics of this kind of thinking and points out the things that can and can't be changed during this time. He talks more about stability and suggests that not only can it help enhance performance but it could also help motivate more projects/corporate users to start using the framework.

In this recent post to his site, Phil Bennett shares some thoughts about the PHP-FIG, the standards they're proposing and how the shares interfaces might help reduce dependencies in framework-based applications.

[Frameworks] come in several different flavours that all have huge advantages, but also a few disadvantages. Over engineered (because their popularity demands that they be), updated too often, not updated enough. If you decide for example to update your application from using Zend Framework 1 to using Zend Framework 2, this will more than likely require, at least in part, a re-write of your code. This makes scalability difficult.

He talks some about the PSRs that the PHP-FIG group has proposed including the PSR-3 logging interface structure. He points out that, by having this same structure, it makes injecting dependencies easy while still leaving the actual functionality open to interpretation. He also suggests that maybe a framework isn't the right choice for all applications and that possibly using a collection of libraries, tied together by the PSR standards, could be a better answer.

PHPMaster.com has posted a list of six things they think you should think about as you're selecting the framework for your next application.

You've decided that it makes sense to use a framework when writing your next new application, and chances are that if you're already familiar with a specific framework, then you'll probably be leaning towards using that one when you start. But are you sure it's really the most appropriate for the task at hand? In the name of due-diligence, here are some of questions that you should ask yourself before settling on a particular framework to make sure you're not programming "against the grain" and also to make sure it will be able to meet your needs now and in the long-term.

He doesn't get into any specifics of any PHP frameworks out there, but suggests general questions to ask even before getting too deep into the technology:

• What do I need from the framework?
• Do I expect the framework to help manage consistency?
• Is good documentation available?
• Is the framework actively developed, and does it have an active user base?
• Does the framework work in what I run in production?
• What business factors are influencing my decision?

Not every application needs to be written using a framework. But if you've decided that yours does, then it's beneficial to compare your needs against the features and benefits of the various framework offerings.

On the ZFort Group's site today there's a new post sharing an infrographic about frameworks in PHP. The data was gathered from Google Trends and looks at popularity and provides some detail for each.

There is a great deal of frameworks, PHP ones in particular, fighting for developers attention. Zfort Group is an interested party in terms of choosing the best PHP frameworks for our custom PHP projects and internal ones as well. So we are continually investigating trends, developers' voting, forums, reviews, ratings, etc. We collected unique and very interesting information and it could be really helpful to the PHP community.

They pulled in some data from other sources as well. It's interesting to see which of the options came out highest in the numbers. They looked at trends for Yii, CodeIgniter, Zend Framework, CakePHP and Symfony. They detail some of the features of each framework including the required PHP version, complexity and quality of community/documentation.

In his most recent post Lukas Smith suggests that good design isn't an excuse for wasting time. He's basically saying that Symfony2, because of how it's designed and implemented, isn't a RAD (rapid application development) framework and that it's about time for some layers to be added to help get it there.

Symfony 1.x I would put into a category of frameworks focused on RAD, aka rapid application development. [...] So for those people who were happy focusing on the 80% use case Symfony2 is a step back. Suddenly the same features take longer to implement, take longer to modify later on and on top of that the learning curve is steeper.

He suggests that work be put into "RAD layers" that can sit on top of Symfony2 and provide some of the more familiar features people are used to from things like CakePHP, Yii and CodeIgniter. There's been a few tries to accomplish this with only one getting the closest in his opinion - the KnpBundle.

Matthew Weier O'Phinney has a new post to his site today covering the reasons he left the PHP-FIG, the PHP Framework Interoperability Group that was designed to help unify the framework (and PHP) communities with common goals and structure. He talks some about his reasons for leaving and what he hopes the group will, eventually, become.

I had high hopes for the group. It was the culmination of something I've been ruminating on for almost a decade (see post number 12 on my blog, dated to January 2004, for proof). My thoughts have mainly been around coding standards and best practices, helping educate developers around their benefits, and how to leverage both in order to create maintainable code.

He talks about some of the things he sees as shortfalls of the group including the definition of some of the standards (and interface structure), the current thoughts of changing of said standards and some of the "discussion" that happens in the group via the mailing lists and pull requests. He mentions that there were several times that the same discussions would happen all over again, despite people saying it had, and is tired of it.

I have better things to do with my time, things I want to create, software I want to support, hobbies and interests I want to pursue. Debating brace placement, tabs vs spaces (for the umpteenth time), or whether or not annotations have a place in programming in a dynamic language? Not so much.