On the Refulz.com blog there's a new post looking at some of the new features in CakePHP 2.0 including its use of lazy loading, the CakeEmail library and the new class loader.

With CakePHP 2.0, they have dropped support for PHP 4 and have refactored the library code to make it strictly complaint with PHP 5.2+. Modeled on Ruby on Rails (RoR), CakePHP is a tough competition to Zend framework, Symfony and CodeIgniter.

Besides the topics mentioned above, he also goes into the details of the new CakeRequest and CakeResponse models (to access information about teh current request/response). Summaries of all of the new functionality are provided along with some sample code where needed to illustrate.

NetTuts.com has posted a second tutorial in their series focusing on the Zend Framework today. In this latest article they focus on integrating the powerful Doctrine ORM with a Zend Framework application.

Ready to take your PHP skills to the next level? In this new "From Scratch" series, we'll focus exclusively on Zend Framework, a full-stack PHP framework created by Zend Technologies. This second tutorial on our series is entitled "Models and Integrating Doctrine ORM".

They continue on from their previous tutorial to talk about what models are (with an example involving "bankers"). They also show how to use the Zend Framework "zf" command line tool to configure your database settings, set up the tables and download/bootstrap the Doctrine code. The include the code to create some simple models and how to use them to create and update records in your database. You can grab all of the sample code for their examples from The Next Social's github repository.

Continuing on from the first part of their series, DevShed has posted part two of their "Building an ORM in PHP" series. This latest tutorial focuses on domain modeling (and collection handling).

In that first part, I implemented the ORM's data access and mapping layers. And as you'll surely recall, the entire implementation process was pretty straightforward and easy to follow. Of course, in its current state the ORM is still far from a fully-functional structure. We need to add some additional components to it, such as a domain model and the classes responsible for handling collections of entities (remember that the ORM relies heavily on the data mapper pattern to do its business properly).

He stays with his "simple blog" example and shows domain models (based on an abstract entity) for Entries, Comments and Authors. His containers extend the Countable, IteratorAggregate and ArrayAccess interfaces to give them some extra abilities.

On the Ibuildings techPortal today there's a new post from Robert Raszczynski about domain modeling and how a good knowledge of it can help your application's architecture.

Architectural and design patterns help software architects to break systems in to smaller, more maintainable sections organised by their functionality and usage. [...] There are three major layers in software architecture: presentation, domain and data source. [...] Now that we know what types of layers we can find in software architecture, let's have a look at how we can organize domain logic and data sources layers.

He looks at three patterns that can help organize your domain logic - a transactional script (one file that does one thing), a table module (logic lives in the tables) and his focus, the domain model. He shows (via a graph) how the domain logic approach can cut through some of the effort it could take to improve on the other two. He gives a two suggestions of how to access the data in your domain layer - a Gateway or a Data Mapper. To reinforce the ideas he's presented, he includes some code snippets of a basic domain model for a Store, Customer and Product and uses them in both Gateway and Data Mapper examples.

Robert Basic has a new post to his blog today with an use case for Zend Framework 2's event manager to solve a problem he has with "repetitive code" in some of his models.

Basically, this allows us to have one piece of code to trigger an event and to have one or more listeners listening to this event. When the event gets triggered, the listeners are called and then we can do *something*, like caching or logging. Logging or caching. [...] See, that's my problem. All the event examples stop at logging and caching. Truly there must be some other example for which this event stuff can be used for.

In his example code, he's used the EventManager in one of his models to add listeners to validate the post and "slugify" the post's title for use on the URL. You can find his code on github if you're interested in the full implementation.

On PHPBuilder.com today they have another tutorial that involves the Fuel PHP framework (previously mentioned here). This time, though, they dive in a bit deeper and look at how to create a database-driven application using the database/ORM tools the framework comes bundled with.

In a recent article I introduced the Fuel PHP framework, which shows great promise despite its status as a relative newcomer to the crowded PHP framework market. While hopefully this introductory tutorial helped to acquaint you with fundamental Fuel concepts, it barely scratched the surface in terms of its impressive capabilities, so I thought it would be worthwhile to pen a follow-up article which examines a feature fundamental to almost any web application no matter how small: database integration.

He shows you how to configure your database connection settings, create your first model and work with the "oil" command line application to scaffold out the CRUD of interacting with the model.

On the Leaseweb Labs blog there's a recent post looking and some of the things you can do to optimize Zend Framework and Doctrine when used together for database access.

In principle, the combination of Zend Framework with Doctrine is not too difficult. But first let's talk about the preparations. According to the author of Zend Framework, the default file structure of project can be a bit more optimal.

They start by describing this optimized file structure (moving the models out of the modules and into the library) and what you'll need to change in Doctrine's configuration to make this work. The post also includes examples of what the larger config should look like when the changes are made. They show how to extend the default Doctrine CLI tool to make a custom "sandbox" instance and show some tuning you can do on the Zend Framework side so it can optimally work with the new models.

On the Ibuildings techPortal, there's a new tutorial posted from Barney Hanlon looking at a new method that developers can use in their applications to give MVC apps a better way to handle their presentation logic - ViewModel.

This provides MVC applications a natural location for presentation logic and lazy functionality while maintaining the segregation between the layers of responsibility within the code. It allows designers access to data and methods they need, while hiding aspects that aren't needed at view level. [...] Indeed, pretty much any modern Web framework has an understanding of the important segregation of duties inherent within MVC. It is precisely this segregation that leads to a certain greyness around the all-important View, particularly on sites where multiple content items are displayed in different ways.

The tutorial he includes shows how to set up a site with multiple articles per page that can be shown as either headlines or just title text. He talks about three ways to accomplish this - the usual injection of all data into the view and having it handle it there, injecting a model directly and extracting data from it and the ViewModel approach (a combination of the Decorator and Adapter design patterns).

New from ZendCasts.com there's a webcast about testing models in your Zend Framework applications.

A walkthrough on how to build up a simple model layer using a test-driven development approach.

You'll need a project already set up to follow along (he doesn't walk you through the creation of one or the setup of PHPUnit) but the process is pretty simple. He shows how to create some unit tests with the TDD method to help create better code through anticipated feature testing.

On the Zend Developer Zone today there's a new post from Vic Cherubini about a new PHP 5.3 only framework - Jolt.

Since [I wrote a previous framework], PHP5.3 was released and added a whole slew of features. Wanting to take advantage of them, I rewrote (and renamed) the entire framework from Artisan System to Jolt. The interesting thing about Jolt is that it intentionally doesn't come with any type of ORM or ActiveRecord classes. Because I believe that Models should be fat, and controllers skinny, the model framework is left entirely up to the developer.

The README on the github repository talks about why he decided to make his own framework, some of the features and functionality it includes and an example of it in action (a boostrap file).