Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>The great thing about Zend Framework is that it is use-at-will which means you can use a single component or you can use them all. Most components are also very flexible either via configuration or extension (inheritance or composition, with ZF favoring the latter).</p> <p>Zend Framework MVC is extremely flexible...even to the point where many have accused it of being over-engineered or bloated itself. This is subjective. </p> <p>Sure, you probably won't want to use Zend Framework for a simple contact form; however, there is nothing stopping you from utilizing just Zend_Mail and Zend_Form without Zend MVC/Application. With flexibility in mind, there is currently no single methodology which is touted as the best in terms of organizing an application into modules. This is a task best left up to the implementer.</p> <p>This brings us to the tutorial at hand. The tutorial writer has come up with a strategy for re-use. This is a good thing; however, there are some flaws with his approach.</p> <ol> <li><p><strong>A library per module.</strong> This is not necessarily bad; however, it is in most cases not necessary. Lets explore what options we have just in case such a structure <em>is</em> needed for some reason.</p> <p><strong>a</strong>. Build a general library (you most likely already do this) namespaced (pseudo if &lt; 5.3 or actual namespaces if >= 5.3).</p> <p><strong>b</strong>. Utilize the intrinsic "Resource Autoloader" <a href="http://framework.zend.com/manual/en/zend.loader.autoloader-resource.html" rel="noreferrer">http://framework.zend.com/manual/en/zend.loader.autoloader-resource.html</a></p> <p>NOTE: I personally haven't used the resource autoloading much. The one time that I did use it, I found that I could have just moved those items to my library. That being said, there are uses for this. It seems to shine when you expect to mix and match modules across projects or for distribution. ZF2 will address this in a less hacky way IMHO.</p></li> <li><p><strong>Base controllers for re-use</strong>. Again, reuse is great; however, Zend Framework provides better alternatives to sub-classing (inheritance) controllers. First, here are some reasons NOT to use controller inheritance:</p> <p><strong>a</strong>. Keeping things DRY is defeated when you have multiple modules that differ enough to need a base-class per module but functionality is copied/pasted across each module's base controller class.</p> <p><strong>b</strong>. It becomes hard to manage inherited properties as it is harder to visualize what inherited functionality is being utilized by each controller/action</p> <p><strong>c</strong>. With PHP allowing only single class inheritance, you blow your one chance at inheritance here -- use this only if there are no other options left</p> <p><strong>Alternatives</strong>:</p> <p><strong>a</strong>. Front-Controller Plug-ins Use these when the functionality/logic needs to run on every request regardless of module/controller/action</p> <p><strong>b</strong>. Action helpers As mentioned by the ZF project lead, "They're a built-in mechanism in Zend Framework to allow you to extend your action controllers in a way that uses composition instead of inheritance." There isn't anything that you can do in a controller that you can't do via an action helper. Use these when the functionality needs to happen on a per controller and/or action basis.</p></li> </ol> <p>So, was the example in the tutorial over-engineered? <strong>Not necessarily</strong>; however, it is certainly a candidate for <strong>incorrectly-engineered</strong> as it relates to best practices and provisions given by Zend Framework.</p> <p><strong>I need to digress for a moment and discuss the terms <em>over-engineered</em> and <em>bloated</em> for just a moment</strong></p> <p>When someone tells you that something is <strong>over-engineered</strong> and/or <strong>bloated</strong> without stating a context please take it with a grain of salt.</p> <p>The Wikipedia article - <a href="http://en.wikipedia.org/wiki/Overengineering" rel="noreferrer">http://en.wikipedia.org/wiki/Overengineering</a> reads in part "...when a product is more robust or complicated than necessary for its <strong>application</strong>...".</p> <p>So, when referring to something as Over-engineered/bloated one should be careful to qualify the <em>context</em> or <strong>application</strong> at hand. Blanket statements should be taken with a grain of salt and in most cases, not taken at all. This is akin to saying something like "I'd never use a 'Circular Saw' for woodworking since it has way too many features and those features confuse me". Sure, this tool may be over-kill for small home/side projects; however, since it is super flexible you will be happy you have this tool when you find yourself in situations where you never thought you'd find yourself.</p> <p>Yes, <strong>most</strong> web frameworks are over-kill for a simple CRUD application such as a contact page or even a simple blogging application. It is unfortunate that most web frameworks use the blog example as their introductory example - go figure.</p> <p><strong>Extra Info</strong>:</p> <ol> <li><p>If you wanted to switch layouts based on the module/controller/action, you could write a Front-Controller Plug-in. Just call "Zend_Layout::startMvc" and pass it a layout name and a path.</p></li> <li><p>Switching the actual view script based on the Accept header (or URL parameter or X-HTTP-METHOD-OVERRIDE header) can be done with the context switch action helper (intrinsic to Zend Framework) - <a href="http://framework.zend.com/manual/en/zend.controller.actionhelpers.html" rel="noreferrer">http://framework.zend.com/manual/en/zend.controller.actionhelpers.html</a></p></li> <li><p>Feel free to pass a model instance to an action helper. You can also configure your action helpers with configuration from the bootstrap. This way, there is no need to store things in the global registry which is just a glorified global variable. This is a hidden dependency that you don't need. For the best re-use, you can create your own custom plug-in resources by extending Zend_Application_Resource_ResourceAbstract - <a href="http://framework.zend.com/manual/en/zend.application.core-functionality.html#zend.application.core-functionality.resource-resourceabstract" rel="noreferrer">http://framework.zend.com/manual/en/zend.application.core-functionality.html#zend.application.core-functionality.resource-resourceabstract</a></p></li> </ol>
    singulars
    1. This table or related slice is empty.
    1. POIs this code insane?
      singulars
      1. PTQuestion
    1. PTAnswer
    1. USWil Moore III
    1. USWil Moore III
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. POIs this code insane?
      singulars
      1. PTQuestion
    1. This table or related slice is empty.
    1. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    2. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    3. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    1. This table or related slice is empty.
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload