StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
primarykey
Id
3797796
data
AcceptedAnswerId
0
AnswerCount
0
ClosedDate
CommentCount
1
CommunityOwnedDate
CreationDate
2010-09-26T12:37:39.953
FavoriteCount
0
LastActivityDate
2010-09-26T12:37:39.953
LastEditDate
LastEditorUserId
0
OwnerUserId
457589
ParentId
3774768
PostTypeId
2
Score
0
ViewCount
0
LastEditorDisplayName
text
Body
in Zend philosophy, they provide the init() method to avoid the hassle of <pre><code>public class Module_TotoController extends Zend_Action_Controller { public function __construct(Zend_Controller_Request_Abstract $request, Zend_Controller_Response_Abstract $response, array $invokeArgs = array()) parent::__construct($request, $response, invokeArgs); // some init code here } } </code></pre> just use : <pre><code>public class Module_TotoController extends Zend_Action_Controller { public function init () // some init code here } } </code></pre> Now, If you look at the <code>Zend_Controller_Action</code> class source, you will notice that the following methods are empty: <ul> <li><code>init()</code></li> <li><code>preDispatch ()</code></li> <li><code>postDispatch ()</code></li> </ul> This means, it is useless to call <code>parent::</code> in your specific controller <pre><code>public class Module_TotoController extends Zend_Action_Controller { public function init () parent::init(); // useless ;-) but you can go for it // some init code here } } </code></pre> <hr> Now, if you want to put an intermediate class between <code>Module_TotoController</code> and <code>Zend_Action_Controller</code>, you expose yourself to a big hassle as: <ul> <li>Some controllers won't extend your "base" controller (e.g your ErrorController in your question) <ul> <li>so it is not a really a base of your application, is it ?</li> </ul></li> <li>If you put some logic in your init() of that "base", <ul> <li>you must call the <code>parent::</code> in your <code>init()</code>, </li> <li>all the developers in the project need to be aware of that</li> </ul></li> <li>You will ever add another little features to your "Base" controller <ul> <li>This will result to a big bloated file</li> <li>Loading/Initializing plenty of stuff you might not really need in that lambda controller <ul> <li>Do you need you database on every page ? <ul> <li>No: doesn't a <code>$this->_helper->connect();</code> look nice instead ?</li> <li>Yes: use a controller plugin</li> </ul></li> </ul></li> </ul></li> <li>This "Base" controller won't fit your other projects needs, so that class won't be reusable <ul> <li>Action helpers will</li> <li>Controller Plugins will</li> </ul></li> </ul> Hope it makes sense
Tags
Title
singulars
PostAcceptedAnswerId
1. This table or related slice is empty.
PostParentId
1. POHow to handle Zend_Exception's in preDispatch or init of an action when using a base controller?
 singulars
 PostTypePostTypeId
 PTQuestion
PostTypePostTypeId
1. PTAnswer
UserLastEditorUserId
1. This table or related slice is empty.
UserOwnerUserId
1. USJulien
plurals
PostLinksPostIdRelatedPostId
1. This table or related slice is empty.
PostLinksRelatedPostIdPostId
1. This table or related slice is empty.
PostsAcceptedAnswerId
1. This table or related slice is empty.
PostsParentIdCreationDate
1. This table or related slice is empty.
VotesPostIdCreationDate
1. This table or related slice is empty.
CommentsPostId
1. COThanks for your post Julien. Some great points. Just to be clearer, I agree with you. They need to remove that paragraph from the documentation. The new idea of using the helpers is superior. But I just followed the prevailing suggestions when first learning Zend Framework and there's now plenty of legacy code for me to support. That's why I chose to keep the base controller. If I started a new project, the Base would be gone. But changing old code means refactoring a bunch of controllers that currently work just fine....possibly introducing bugs...not to mention investment of time.
 singulars
 PostPostId
 PO
 UserUserId
 USjoedevon

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.