Michael Kimsal has a new post today looking at using Doctrine models in a Zend Framework application and how to get them to autoload when you need them with the help of Zend's Zend_Loader_Autoloader.

I would have expected there to be some explicit reference to how to set this up, but the best I can find are general examples where the Doctrine models directories are appended to the include_path in a ZF index file. Shouldn't there be a way to explicitly have the Doctrine subsystem react to requests for models as well?

He works through the process he followed, including the possibilities of extending the Doctrine Core and accessing the $_modelsDirectory property, but didn't have much luck because of how Doctrine forces the autoloading. He asks for help and gets some good suggestions in the comments on where to look fro documentation and a possibility of skipping the Doctrine loader all together.

The ZendCasts.com site has recently posted a quick video covering logging and Doctrine event listeners in a Zend Framework application.

This short video is going to be the last in my 2009-2010 series on Doctrine 1.2. I'm wrapping it up with a little example of adding timestamps, logging and using Doctrine's event listener architecture.

The tutorial shows you how to pull in the features of Doctrine to make it easier to create a more complex logging system. He shows how to set up the schema file, add in controller functionality and backend models to make things all work together happily. You can get a copy of the project he's building from his subversion repository.

Doctrine allows you to set up relationships to link data in various tables together. Unfortunately, those aren't always in the order they need to be in. In a new post to his blog Chris Hartjes shows you how to sort these relationship results just by adding a simple line to your request.

I started digging around via search engine. Took me about an hour to find the solution. First, it took me half the time to dive deep enough to find out WHERE I can define the default sort order. Surprisingly, it was in an area that made total sense but I could not find before.

You can see an example of it in the "hasMany" call in his code snippet - the addition of the "orderBy" option and the value showing the sorting order. Here's the StackOverflow page that gave him the answer he needed.

The next ZendCast in the user authentication with the Zend Framework's Zend_Auth has been posted to the ZendCasts.com site today. In this new screencast, they look at how to integrate it with Doctrine to automatically validate users against the information in your databases (following up on this first part of the series).

Here's the second part of my Doctrine / Zend_Auth example. In 15 minutes, we create a logout, login and protected area that's reliant on the ZC_Auth_Adapter adapter we created in last week's video. Notice how there's no code in the IndexController exposing the authentication implementation,

You can grab the code to follow along or build it as he goes. You'll need a copy of Doctrine up and working to keep up, though.

New from the ZendCasts.com site today there's this new screencast looking at the integration of the Zend_Auth_Adapter component of the Zend Framework and the Doctrine ORM library to split out the authentication from the persistence layer.

I've been using Doctrine a lot in my own work, and recently found myself itching to have tighter integration between Zend and Doctrine when it comes to user logins. Luckily, Zend provides a very simple interface with regards to Zend_Auth. This way, it's easy to decouple your persistence layer (in my case Doctrine) from the authentication layer.

He also recommends checking out Palo Verede's look at the same topic. You can watch the screencast here and grab the code for it here.

In a new post on the Rdavid.net blog there's some discussion about Zend Framework models, the best approach and a "Service Class" idea.

After some more thought and lots of research on the subject, I've come to a solid point where I actually have something to try out which seems semantic aside from the naming of the class (Service Class) '" but this is derived from what some people are talking about in ZF circles starting from Matthew Weier O'Phinney who was coining it as the "Gateway to the Domain" from early on, then later changing it to "Service Class".

He defines what his service class idea is - a layer between the database and each of the models that allows them to be agnostic about what kind of service they're using. He also breaks down some of the key points around his approach including the fact that the Model Service can create Forms and that the Model Service can use the Zend_Cache component directly for improving performance. Be sure to check out the comments for thought from other Zend Framework developers.

On Rdavid.net there's a post with the results from some tests run on hos much memory the Zend Framework and Doctrine used both with and without the APC caching.

I have decided to run with Doctrine as my Domain Model in Zend Framework projects. The thing is, if I'm going to commit to this, I need to know that applications I build in the future with the Zend Framework while using Doctrine as an integral part of the Model layer will not take performance hits from things like memory usage. With Doctrine doing a _lot_ of magic, I thought that this would be something that I wanted to see for myself. 4MB Memory to execute a simple Query?!?! Ffffff#$#!!!!

He includes the code for his testing procedure - creating a basic Doctrine object and running a "fetchOne" query and measuring the memory consumption with the memory_get_usage function. His results with the APC caching came out faster by about 60-70 percent.

New on the ZendCasts.com site is this recent screencast about the best approach for integration of the popular Doctrine ORM and the Zend Framework.

his video is my humble approach of combining some of the learning brought about over the last few weeks on Zendcasts, as well as suggestions from Doctrine developers. The goal of this video is to show how you leverage the existing resource loading tools in Zend to have a model structure that reflects Zend's best practices.

The code is provided if you'd like to follow along with this (about) twenty-five minute presentation.

The Zend Developer Zone has posted the second part of their look at pagination with the combination of the Zend Framework, Doctrine and PEAR and how the Zend_Paginator component compares to the PEAR and Doctrine alternatives.

In the previous segment of this article, I introduced you to the Zend_Paginator class, which provides a flexible API for paginating any data collection, whether it is expressed as an array or a database result set. [...] This article will explore two such alternatives, the PEAR Pager class and the Doctrine Pager class, and give you a crash course in how you can use them to quickly add paging and sorting features to your PHP application.

The article gives examples for both of the other methods - a simple pagination of database information with the PEAR pager component (and other packages that can make the results more effective) and the creation of a Doctrine instance where the results are handled via a series of built-in method calls.

New from the ZendCasts.com site there's a new screencast looking at the relations you can create between Doctrine and your Zend Framework applications.

This short podcast covers how you can easily build a form using Zend's MVC model via Zend_Controller and using Doctrine for persistence. You can download the source code or browse it online. Enjoy!

This screencast is part of a series they've been doing on Doctrine including Doctrine Relations and Data Fixtures and Writing Doctrine Unit Tests with Zend_Test.