ORM Designer 2

I thought I’ll help plug a tool that looks to be quite useful and that is basing their development on direct community input, I’ve made my suggestions hope you do too 🙂

Martin Kulhavy writes; ORM Designer. It’s primary target is to create ORM Definitions fast and easily with the help of visual diagram instead of manually written text definitions.
Most distinctive features allows you to:
  • Save time and work 4 times faster.
  • Repeatedly export your definition files.
  • Import and visualize existing project schemas.
  • Eliminate errors and the need to look for typos.
Download our 14-day trial version and let us know what you think. If you write a review, we will give you 20% discount off the price of ORM Designer. Either way, let us know, what you think about it. If you found it helpful, and if not, why not. Any feedback is incredibly valuable to us, as we strive to make our product the best we possibly can.

Complete Doctrine 1.2x Integration with Zend Framework 1.10+

To achieve complete Doctrine 1 integration with Zend Framework some glue is required, Benjamin Eberlei has created a complete solution thats straight forward, easy to use and understand.

This project tries to offer a complete Integration of Doctrine 1 with Zend Framework. The following components belong to this Integration:

  • Zend_Application Resource
  • Zend Framework Modular Project Support
  • Zend_Tool Provider for Doctrine Model Generation, Migrations and Fixtures
  • Zend_Paginator Adapter for Doctrine Queries
  • Dynamic Zend_Form generation from Doctrine Models

This integration requires the latest Doctrine version 1.2.2 to work completely

Get it!

SVN Export or Externals

Github offers SVN Read support for a while now, you can either use svn export or svn:externals to include ZFDoctrine into your project or into your PHP Include Path.
svn checkout http://svn.github.com/beberlei/zf-doctrine.git

Git Clone

git clone git://github.com/beberlei/zf-doctrine.git
If you follow the tutorial and installation steps your will get this in ZFTool.

Zend Framework Command Line Console Tool v1.10.4
Actions supported by provider "Doctrine"
zf create-project doctrine dsn zend-project-style library-per-module single-library
zf build-project doctrine force load reload
zf create-database doctrine
zf drop-database doctrine force
zf create-tables doctrine
zf generate-sql doctrine
zf dql doctrine
zf load-data doctrine append
zf dump-data doctrine individual-files
zf generate-models-from-yaml doctrine
zf generate-yaml-from-models doctrine
zf generate-yaml-from-database doctrine
zf generate-migration doctrine class-name from-database from-models
zf excecute-migration doctrine to-version
zf show-migration doctrine
zf show doctrine

Read it ALL at beberlei’s zf-doctrine at master – GitHub.

Akrabat_Db_Schema_Manager: table prefix support

Rob Allen posts; I’ve updated Akrabat_Db_Schema_Manager so that it now supports table prefixes.

It uses the application.ini key of resources.db.table_prefix as I couldn’t think of a better one 🙂 and then uses that for the schema_version table’s name and also makes it available in your change objects.

For example, if application.ini contains resources.db.table_prefix = “myapp”, then the manager will create the table myapp_schema_version to store the current version of the schema. In your change classes, you can then do this:


class Users extends Akrabat_Db_Schema_AbstractChange
function up()
$tableName = $this->_tablePrefix . 'users';
$sql = "
username varchar(50) NOT NULL,
password varchar(75) NOT NULL,
role varchar(200) NOT NULL DEFAULT 'user',

$data = array();
$data['username'] = 'admin';
$data['password'] = sha1('password');
$data['role'] = 'admin';
$this->_db->insert($tableName, $data);

function down()
$tableName = $this->_tablePrefix . 'users';
$sql= "DROP TABLE IF EXISTS $tableName";


which will create a table called myapp_users. Note that you are responsible for using the prefix property as the change classes cannot enforce what you do within the up() and down() methods. It also follows that you’ll have to ensure that your models also use the correct prefix.

I have also made a change to the provider (Akrabat_Tool_DatabaseSchemaProvider) so that it loads the correct application.ini file based on the data in the project’s profile. This shouldn’t affect anyone using Akrabat_Db_Schema_Manager, except that we no longer define APPLICATION_ENV and APPLICATION_PATH for you.


via Rob Allen’s DevNotes.

Zend Framework + Doctrine 1 Integration

Benjamin Eberlei writes; Hello everyone,

I completed a first version of Zend + Doctrine 1 integration today and want to share it with all you. Since currently the status on a 1.11 release is unclear I contacted all the contributors to various Doctrine-related components and combined them into a single release and wrote some documentation on all the different parts and how they relate to each other.


The code is under the New BSD License. There is a comprehensive getting started guide shipped with the Github Project.

The following parts are included in this release:

  • Application Resource contributed by Matt Lurz
  • Dynamic Form Generation contributed by Jani Hartikainen
  • Paginator Adapter contributed by Matt Lurz and Juozas Kaziukenas
  • Zend Tool Provider and modular Zend Project Style Support

Thanks to all the contributors and various other people that contributed ideas and code.

For any feedback regarding this integration, you can use the issue tracker on Github.

This release depends on Doctrine 1.2.2 to allow model code-generation from YAML files that supports Zend Framework Modular projects and their directory structure.

Most of the current glue code out there is made obsolete by generating Models that follow the Zend Framework naming conventions, into Zend Framework models/ directories. Additionally there is also support for modular applications whose model classes should follow the PEAR naming schema.

Additionally the dynamic form support allows to create simple forms that allow to create and edit Doctrine_Record instances and their relations.

This is a great help to rapidly prototype admin forms (however support for more complex forms is not yet included).

Since both projects are currently very focused on their 2.0 releases, this release aims to glue all the existing code for Doctrine 1.x and Zend Framework integration 1.x together, giving them a platform to flourish.


Namespacing ACL resources and Galahad_Acl

Chris Morrell writes; In most of my applications I like to handle authorization (querying the ACL) in one (or more) of three ways:

  • Authorize access to a model’s method
  • Authorize access to a controller action
  • Authorize access to an arbitrary “permission”

In general I find it’s best to keep authorization within the domain (querying the ACL within my models when they’re accessed) as this provides the most consistent behavior. For example, if I eventually add a REST API to my application I don’t have to duplicate all my authorization logic in the new REST controllers. When the application calls something like Default_Model_Post::save() it either saves or throws an ACL exception, no matter where it was called from. This is great in that it saves me from having to duplicate code and keeps my system more secure.

On the other hand, there are times when it’s just a lot easier to handle authorization in the controller. For example, if guests should never access my “Admin” module, it doesn’t make sense to ever let them access /admin/ URLs. Also, if you’re using Zend_Navigation, having ACL resources that match controller actions lets you utilize its ACL integration.

If you’re ever going to mix these two techniques, you’ll eventually bump into the case where a model and a controller share the same name. What if you need to set permissions on a “user” controller and different permissions on a “user” model? This is where namespacing comes into play. As suggested by the Zend Framework manual, I always name my controller action resources in the format mvc:module.controller.action. I name my model resources similarly, in the format model:module.modelName.methodName. In both theses cases, “mvc” and “model” are the namespace, and everything following the colon is the actual resource name. Now I can refer to my “admin” module as mvc:admin and the models within my admin module as model:admin.

This is where things get interesting.

Read on; “Namespacing ACL resources & Galahad_Acl”.

Chris continues; Right now I treat my models as resources with a special exception for the user model which is both a resource and a role. Then I actually make the models responsible for managing their own ACL permissions, both setting them up and querying them. To facilitate that, I have a base model class that does a few things. First it has a way to inject an ACL instance into the model as well as a way to pass an ACL instance as the default ACL for all models (which I do in my bootstrap). Second it automatically adds itself to that ACL (with the resource id model:moduleName.modelName). Finally, I have an _initAcl() method which is called when my model is instantiated which adds the appropriate rules to the ACL if they don’t already exist. Whenever my model is doing something that is access-controlled I check the ACL right then.

Here’s a simple code example:

class Default_Model_Post extends Galahad_Model_Entity
protected function _initAcl($acl)
// Deny permissions to anything on this model unless explicitly allowed
$acl->deny(null, $this);

// Allow guests to fetch the content of posts
$acl->allow('guest', $this, 'fetch');

// Allow admins to save changes to posts
$acl->allow('admin', $this, 'save');

public function save()
if (!$this->getAcl()->isAllowed($this->getRole(), $this, 'save')) {
throw new Galahad_Acl_Exception('Current user is not allowed to save posts.');

$dataMapper = $this->getDataMapper();
return $dataMapper->save($this);

There’s a little bit more happening in there (for example, I also have helper methods like getRole(), which either gets the role ID stored in the model or grabs it from Zend_Auth if available), but you should get the picture.

That way my access control is happening when the access itself is happening. No matter how my model is used, the ACL is always queried right when it matters. I also like setting up the ACL this way because all rules are loaded into the the ACL only when they could potentially apply (you never need the rules for a Post model if the current request never even loads the Post class).

This is something I’ve been thinking about a lot lately, and I’m just settling into this method. I just blogged about it a little over a week ago: “Namespacing ACL resources & Galahad_Acl” — if anyone has any comments I’d love to hear them

Deep Integration between Zend Framework and Doctrine 1.2

There’s been a lot of talk online about finding the best approach for bringing Zend Framework and Doctrine 1.x together. This 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. This video builds on the last Doctrine video, but if you’re familiar with both frameworks, you should be able to follow along. Enjoy!

via Deep Integration between Zend and Doctrine 1.2 | free Zend Framework screencasts – Zendcasts.