Hi. I welcome this initiative!
Why would one need a ini to map modules to models? Matthews resource plugin defines paths in its .ini for each model you wish to create. One is free to point them at a module... I feel I am missing something...
One of the problems that is consistently emerging is modular support. Could someone be a little verbose on expressing the exact problem of modular support? Also (how) does this tie in with autoloading and or PEAR style model organization (Doctrine 1.2+). Should the model class names reflect the module name? (Model_Base_Entity vs CMS_Model_Base_Entity) Ah, questions, tastes and best practices...

And some concrete feedback : Proposed is to put doctrine models in the directory 'module/models'. Personally I have other, none-doctrine, model classes at that location (so these can be used from both controllers and amf-services) and therefore place the doctrine models within a directory called doctrine.

module/models/... (custom model classes)
module/models/doctrine/...

Wouldn't want one to be able to only run commands on a single module? I know I would
example :

I'd suggest grouping all doctrine tasks under one namespace if possible. It's good practise all along ZF.

 zf doctrine build-all

 zf doctrine build-all-reload

etc. This is (at least for me) expected behaviour.

Is it possible to access the code of this proposal? It's all included in the Zym git repository, but it's not accessible at all. Could you point out where we can download the complete Doctrine namespace for Zend Tool? Copy/paste every file from the webinterface is too much work

I have another comment, a bit related to the one Bas K posted at first. I think it's a good idea to have the ability configure paths relative to a module's root. In combination with the module specific commands (zf create doctrine <moduleName>) this component will be very flexible in respect of modular loading and generation of models.

I'd like to have all module specific information inside my module directory. That said, for now I have this set of configuration:

• scheme file: configs/scheme.yml
• fixtures: configs/data/fixtures/
• sql: configs/data/sql/
• migration: configs/migrations/
• models: models/
  This means the scheme file for e.g. a guestbook module is located at application/modules/guestbook/configs/scheme.yml

I took care of the autoloading with the modules application resource (http://juriansluiman.nl/en/blog/article/105/doctrine-modular-loading-of-models). I think the module-based configuration (for both config files and the models/forms) is a more flexible approach to keep the loved ZF modular structure including the Doctrine advantages.

My comment has several implications:

• Mapping (configure doctrine.module & assign-model doctrine.module) isn't required anymore, the module controls itself
• Actions with a module argument are easy and convenient to implement
• Actions without a module argument loops through all modules to perform the selected action (this might be the negative side of my comment)

I think there are several options to configure Doctrine such it's intelligent with loading the models in Zend's modular structure. A lot of information is spread lately about the integration of Doctrine with ZF, but 99% forgets the modular structure because Doctrine doesn't provide such an organized structure. I hope with the integration of Doctrine 1 and Zend_Tool (this proposal) we look more at this problem and provide a better method to keep things inside the module directory (imho the preferred method).
I know my comment doens't only apply to this proposal, but is also meant for the Doctrine resource (http://framework.zend.com/wiki/display/ZFPROP/Zend_Application_Resource_Doctrine+-+Matthew+Lurz). I thought this was the best place to put my ideas down

I committed the first working version of my tooling support for ZF + Doctrine prototype to my user branch:

http://framework.zend.com/svn/framework/standard/branches/user/beberlei/zfdoctrine/

Using it boils down to the following commands:

First you need to modify your .zf.ini to look for the DoctrineProvider in "library/Zend/Doctrine/Tool/DoctrineProvider.php"

Then:

Now you can go to your application/config/schema directory and create a yaml schema, for example:

Plus add the module resource loaders to your Bootstrap:

Here you can see the requirements on the model. ZF and Doctrine Integration only works if you follow it completly:

Your Models have to be called either Model_Foo or Module_Model_Foo

Now you can go generate the models from the YAML file:

The first command generates the Model_User and Addressbook_Model_Contact aswell as their respective Base clases Model_Base_User and Adressbook_Model_Base_Contact. The second command creates the database from the schema and loads a fixture from the "application/configs/fixtures".

What is missing:

• Documentation
• Tool support to create multiple places where a YAML schema can be generated.

Be aware:

This proposal tightly integrates ZF and Doctrine in the default project schema. Any attempt to use it in another way will fail, and you should use the components strengths separately to get where you want to.

I would appreciate feedback from anyone who wants to give it a try.

Hello everyone,

I can't checkout your repository :

C:\Users\MightyDucks\Desktop\zend\library\Zend\Doctrine2\Application\Resource\Entitymanager.php
In directory 'C:\Users\MightyDucks\Desktop\zend\library\Zend\Doctrine2\Application\Resource'
Can't open file
'C:\Users\MightyDucks\Desktop\zend\library\Zend\Doctrine2\Application\Resource\.svn\tmp\text-base\Entitymanager.php.svn-base':
The specified file is not found.

Can you check your repos ?

Thank you

Hi Julien - I had the same problem today. It is because there are two files in that dir (Entitymanager.php and EntityManager.php) which obviously resolve to the same file in windows due to its lack of case sensitivity. There is no way around this at present other than doing the check-out on a non-windows machine. I've sent Benjamin (beberlei) an email asking him to remove the extra file so check-outs work