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.

Matt Setter has a new post to his site today about forms in Zend Framework 2 including a full example on how to use them to create a form for user information (first name, last name).

I think it goes without saying, forms are one of the central elements of any web-based application. They're used for everything from logging in, to searching content and managing information. Given that, they should be first-class citizens, able to be developed and reused with relative ease. [...] However, given the amount of options, configurability and flexibility required, this isn't always easy. [...] In today's post, I'm going to assume you have a basic understanding of how forms work now. [...] I'm going to show you how to create flexible, reusable forms in one module and by the power of the ServiceManager reuse them throughout your application.

He starts with the inclusion of a dependency needed for his example - the ZfcUser component (installed via Composer). He then moves on to the actual code for the form creating a reusable module, an entity class for the User and the Fieldset/Form classes for the contents of the form. He also includes the code for the controller action and the view that outputs the form itself and handles the repopulation automagically (and includes a CSRF token).

In this recent post to the Duckout blog, they show you how to hook your PHP-based (and database driven) application into the Google Charting API for chart/graph generation.

I think, whenever we see a chart in a magazine, in books or applications our brain say's to us Yeepie!!! Don't read these stupid texts or tables! Just look at the green or yellow line and hope that they are above the other lines or hope that your opinion is the biggest part of the pie¯. This saves us a lot of work and in my opinion we should concentrate on drawing beautiful colorized pie charts, instead of writing long boring articles. But the question is: ¯How do I draw these beautiful colorized pie charts? The simple answer is: you don't have to, because google will draw them for you and you just have to tell them what to draw via the google charts api.

The sample application is a "breakfast rating" tool that logs the results to a MySQL database via PDO calls. The results are then extracted and formated as JSON to be compatible with the Google Charts API data handling. Some sample Javascript is included showing how to call the Charts API with your data and get back a simple line graphing of the data from the database. You can see the application in action here for reference.

In his most recent post Michelangelo van Dam talks about unit testing and databases and how, to effectively test what should be tested (the code, not "the ability to fetch data") you need to correctly mock your database objects.

When I state "as is", I truly mean the way it's being used in production. So the database call collects real data on which business logic is applied. You can see this is not a healthy situation, especially when you also have services that apply business logic on data and store it back into the database. In "Chris Hartjes wrote this one sentence that says it all: "Unit test suites are meant to be testing code, not the ability of a database server to return results". And he's right, you shouldn't use database connections when your testing business rules and functional logic.

He goes on to show a few code examples that show a pre-mocked state of testing where the Product information is pulled directly from a PDO connection. The more correct version mocks out this object, though, and overrides the "execute" and "fetchAll" methods to return mocked results.

PHPMaster.com 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.

Gonzalo Ayuso has written up a new post about a handling method he's worked up for working with multiple PDO instances (database connections) through the Symfony2 dependency injection container using custom YML definitions and a simple "Db" class.

I'm not a big fan of ORMs, especially in PHP world when all dies at the end of each request. Plain SQL is easy to understand and very powerful. Anyway in PHP we have Doctrine. Doctrine is a amazing project, probably (with permission of Symfony2) the most advanced PHP project, but I normally prefer to work with SQL instead of Doctrine. [...] Due to my daily work I need to connect to different databases (not only one) in my applications.

He shows the normal setup using the "parameters.yml" file to define the multiple database connections but notes that this isn't the most ideal solution. Instead, he walks you through the steps to create the "databases.yml" configuration file and a simple "Db" class that acts as an interface to pull the PDO objects from the container. You can then just call the "get" method on the container to extract the fully configured PDO object, ready for use.

On PHPMaster.com there's a new tutorial from Vito Tardia about using the Mozilla Persona authentication system in your PHP application - an abstracted authentication system that keeps only a token representing the user in your system.

Mozilla Persona is built upon the BrowserID technology also developed by Mozilla. You can find an expanded explanation of the concepts in the article How BrowserID Works by Lloyd Hilaiel. [...] An email address is an identity and it's verified by the email provider [then the] authentication takes place in the browser.

He talks about the three steps in the process (certificate provisioning, assertion generation and assertion verification) and includes some sample code that does the work for you with some PHP, HTML and Javascript. In his example he just authenticates the user and returns the success/fail back to the calling script. You could take it one step further and integrate it with the session handler as well.

Related to a recent discussion on the php.internals mailing list, Chris Jones has posted about moving away from the MySQL extension in favor of the MySQLi functionality and the effort bubbling up to make the old functionality deprecated.

An important discussion on the PHP "internals" development mailing list is taking place. It's one that you should take some note of. It concerns the next step in transitioning PHP applications away from the very old mysql extension and towards adopting the much better mysqli extension or PDO_MYSQL driver for PDO. This would allow the mysql extension to, at some as-yet undetermined time in the future, be removed.

He links to a RFC that's been posted to help promote and push this idea forward with mentions of the "carrot" and "stick" methods for pushing users towards mysqli.

As always, there is a lot of guesswork going on as to what MySQL APIs are in current use by PHP applications, how those applications are deployed, and what their upgrade cycle is. [...] I want to repeat that no time frame for the eventual removal of the mysql extension is set. I expect it to be some years away.

On PHPMaster.com there's a continuance of a previous article about security in PHP applications talking about a few more considerations when trying to make things secure.

In a previous article, I talked about some common security vulnerabilities that can affect your PHP web application. But there are other things besides those ten (okay, seven) attacks to think about when you're developing. And so, this article offers a compendium of miscellaneous things that are security related; things you should do, things you shouldn't do, things that other people might try to do, whatever it takes to make an article long enough for my editor to be satisfied with it.

He talks some about the settings that you might need to tweak in your "php.ini" server-side configuration file, some hints on filtering data (like using filter_input) and what to watch out for with error reporting. He also mentions session fixation and the protection of user data and passwords to keep them out of the hands of would-be attackers.

In this discussion on Reddit, there's talk about the user comments feature on the PHP.net site and the value they provide to the language and community.

The question, however, has always been "how useful is this feature really and does it bring more harm than good?". It's not that easy to answer since there are so many notes submitted by a wide range of users and some will likely go unnoticed while others seem to get undue attention due to their positioning near the top of the user-notes section of a particularly trafficked page.

The poster proposes a few things that could help make them a bit more effective (and useful overall) including voting on the note contents, flagging potential issues and sorting the notes based on popularity/age. He's put together a proof of concept as seen here with some of the new features.