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 🙂
- 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.
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
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://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.
Elink Media posts a followup;
I’ve created a new branch on my Github project “zf1-doctrine2″. The “modular_setup” branch shows how we could setup Zend Framework with the modular approach, while still be able to use Doctrine 2 as the ORM for each module.
Oh well, the idea is to make each module decoupled with the rest of the application, so really, you could use whatever database handling mechanism in each module.
Check it out from my Github project here.
Elink Media posts; Doctrine 2 is in beta. It is for sure one of the most exciting things that caught my attention recently.
As a Zend Framework user, I started looking into ways to integrate Doctrine 2 with Zend Framework (currently in version 1).
The same as any other times, the solutions are already out there. The integration’s already been done by Giorgio Sironi’s nakedphp project.
So … I borrowed code from nakedphp and put up a skeleton ZF projects myself.
My sample project is available on Github. You can find it here.
Have a play, let me know if anything. Hope it’ll help people like myself, who cannot wait to try out new and cool things.
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.
Jon Lebensold shows you how to use the Zend Tool in useful ways; This screencast should help you setup Zend_Tool in your Zend Framework application. Zend_Tool is a command line entry point into your application. Currently, Zend_Tool is used to scaffold (build generic files) the Zend Framework project structure, modules, controllers, database table classes and other tedious processes. The goal of this video is to start looking at how we can generate our own Manifest and Provider classes so that custom command line tools can be integrated into the Zend Framework application.
The advantage of such integration is far reaching: deployable web applications using the Zend Framework can have “installers” and other frameworks, like Doctrine, can easily become first class citizens within the Zend Framework eco-system.
John Wage writes; At ConFoo 2010 during my presentation, someone asked about the constructor of entities in Doctrine 2 and whether or not it could be used. I think this is something worth writing about since in Doctrine 1 this was not possible. The constructor was hi-jacked from you and used internally by Doctrine.
In Doctrine 2 it is possible to define the constructor in your entity classes and is not required to be a zero argument constructor! That's right, Doctrine 2 never instantiates the constructor of your entities so you have complete control!
This is possible due to a small trick which is used by two other projects, php-object-freezer and Flow3. The gist of it is we store a prototype class instance that is unserialized from a hand crafted serialized string where the class name is concatenated into the string. The result when we unserialize the string is an instance of the class which is stored as a prototype and cloned everytime we need a new instance during hydration.
Have a look at the method responsible for this:
Read the full article at; Doctrine – Doctrine 2: Give me my constructor back.
Jon Lebensold publishes another screen cast on the Doctrine topic;
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.
view screencast; Logging with Timestamps and Doctrine Event Listeners
While pouring over some posts about Doctrine I stumbled upon a very nice solution to the Cascading Delete issue when using the SoftDelete behaviour on an Doctrine Model. Here is what the guys at Elink Media writes;
I have been using Doctrine ORM for a while now. Here I want to discuss 2 tricky issues I have encountered and resolved.
First, I’m paranoid of deleting records from the database. Things like registered users, I would rather have them marked as “DELETED”, but still keep the record in the database, just in case …
With Doctrine, the SoftDelete behaviour is perfect for this purpose. When a model is enabled with the SoftDelete behaviour, an extra field “deleted_at” is automatically added to the corresponding database table by default. So, when you call the delete() function on a model object, the corresponding data row in the database receives a timestamp on the “deleted_at” field. Data having values on the “deleted_at” field will not be returned by any find methods in the future.
It all sounds good, right? Not until you start trying to cascade “delete” on associations. Since we are not really deleting the record, DBMS level delete cascading will simply not work (In Doctrine YAML schema term, the “onDelete: CASCADE” will not work). Now, I’ll illustrate the problem and the solution with a typical blog example.
Click for Solution 🙂