Model and base interface generators for Zend Framework

Question

After doing some research, one of the drawbacks often reported about the Zend Framework is the amount of work required to get out of the ground. For me, this could be solved if ZF had strong model and backend interface generators like Symfony. I searched for them, and here is what I found:

Model Generators

• http://code.google.com/p/zend-db-model-generator/ : looks like official, based on user feedback, the documentation seems awful though.

• http://code.google.com/p/zend-model-generator/ : seems pretty advanced. updated 3 months ago.

• https://github.com/inxilpro/Galahad-FE/ : not updated after 2 years, looks dead.

• https://github.com/codeinchaos/zend-model-generator/blob/master/generate.php : one php file, it may be interesting to use as a base and expand if necessary.

Backend interfaces

As usual, you can use the database administration tools

• http://www.phpmyadmin.net : with a complete set of new features with 3.5. It’s hard to expand.

• http://www.adminer.org/ : single file interface. Enough enough. Using plugins seems to simplify the extension of functionality.

Backend interface generators

• http://zfdatagrid.com/grid/default/site/crud , which comes from what looks like a very active ZF project: http://code.google.com/p/zfdatagrid/ .

• http://www.koala-framework.org/ : I recently came across this structure, which allows you to create Zend desktop applications that you can use to create an interface.

Setting up the interface seems quite simple, for example, here is how you can display the form for editing contacts on the same page as for editing members:

 <?php class MemberContacts extends Kwf_Model_Db { protected $_table = 'member_contacts'; protected $_referenceMap = array( 'Member' => array( 'column' => 'member_id', 'refModelClass' => 'Members', ) ); } ?> 

Demo of Koala frameworks available . Honestly, it looks pretty impressive.

Q: What model generators and interface (generators) do you use for Zend and why?

Answer 1

I do not use any generator prepared by backoffice or the so-called scaffolding.

Why do not I use them in general?

These tools make a lot of difference depending on how the structured generated user interface is; you no longer have the opportunity to design it exactly the way you want.

They are quite difficult to reuse if you do not know them very well, they introduce a lot of magic, for example, when I create a backoffice using Django, I have to set five parameters, and backoffice works for me. Understanding how this works does require a lot of knowledge about the internal mechanisms of the tool, so updating can be a real pain.

In my opinion, there is a big difference between providing an almost complete backoffice application such as Symfony, Rails and Django and what the Zend Framework does: limiting the overall structure and libraries.

There is a deliberate choice between what works out of the box and something flexible. I think they tend to guide different needs.

I prefer the Zend Framework approach, as I am not satisfied (and have not experienced what I have to admit), with what others offer as an “almost done” user interface.

Why will I never use them in the Zend Framework?

If the Zend Framework does not extend such tools, I will not connect what others tried to build, since nothing can guarantee that there will be no regression on it (and the update can be really good, because Zend always integrates more and more external services ) The strength of the Zend Framework is its flexibility, blocking the tools above it, you go against the philosophy of the product.

This may satisfy your expectations for a really small project, but for more, I really suggest you create your own user interface to suit your needs, a backoffice will only take one or two weeks.