Pragmatism in the real world

Questions regarding the latest tutorial (1.3.0)

I’ve been asked a couple of questions via email that I think are probably worth answering here, just in case others are wondering the same thing!

1) Why did you change the functionality of the BaseURL? You moved the BaseURL to the IndexController and in the previous version it was in the Bootstrap.

The main reason I did this is that the new MVC code works out the base URL for us in the request object, so use it rather than do our own. Also, in previous versions of the tutorial, I had hard coded the URLs in all the templates, so I took the opportunity of the reworking to fix that too.

2) In the previous version the template files were called filename.tpl.php. Now they are called filename.phtml. Why did you do this? I think the first option is better, the reason being that if something goes wrong with the .htaccess file, visitors see the source code if the webserver does not know of .phtml files. In case of the filename.tpl.php method, nothing bad happens since the .php files will be processed by the webserver and will probably just give errors on the screen instead of the source code.

The .phtml extension is the default used in the new view integration code in Zend_Controller_Action, so I used it too. On the proposal, Mathew Weier O’Phinney stated:

Suffixes are a developer preference, really; you don’t need to use .tpl with Smarty, nor .php with Zend_View. I actually chose .phtml as (a) most apache configurations specify it as an alternate extension associated with the PHP engine, (b) most IDEs and text editors will identify .phtml as PHP + HTML for syntax highlighting, and (c) it visually separates template scripts from other PHP files in the directory tree.

Personally, I quite like .phtml as it reinforces the idea that the template files are HTML files with PHP in them. It’s easy enough to get render() to use .tpl.php: just set $this->viewSuffix in your init() function.

I hope that makes sense. If anyone’s got any questions, please ask away!

14 thoughts on “Questions regarding the latest tutorial (1.3.0)

  1. Calling your template .phtml also limits your template to contain HTML. At least it would be strange to save somthing that's not HTML in a file called *.phtml.

    That's what I like about .tpl – it's neutral.

  2. Good point Nico. It would be odd to have a template that created a plain text email with an extension of ".phtml".



  3. Hi Rob, I have a question regarding your directory structure. Reading your tutorial, it seems that your document root is set to zf-tutorial/, correct ? The question is, why not setting it to zf-tutorial/public/ ?

    writing my question, a possible answer came to me: would it be for people not able to edit their apache configuration ?

  4. Maybe my brain get tied of work, but I still can't find where you set path_to_templates in your tutorial?

    " It also sets up the Zend_View object to look in
    views/scripts/{controller name} for the view scripts to be rendered

    I've tried use: $this->view->setScriptPath('../user/templates');

    But it didn't work.

  5. Denis,

    What I mean is that the call to $this->initView() in the action's init() handles setting up the path to the view templates.

    I don't see why you can't override it with a call to $this->view->setScriptPath() after the call to $this->initView() though.



  6. use route ena $this->url(array(),"routeName") to make the path on link instead of $this->baseUrl."controller/action"

  7. Rob,

    Seems It will not work.

    Part of code from initView() method:
    $baseDir = dirname($dirs[$module]) . DIRECTORY_SEPARATOR . 'views';
    if (!file_exists($baseDir) || !is_dir($baseDir)) {
    throw new Zend_Controller_Exception('Missing base view directory ("' . $baseDir . '")');

    So, Zend expect that the view directory must by in subdirectory 'view' in the same directory where controller placed(and it generates exception in other case). It can be a little bit inconveniently in some projects, I think.

  8. There is an error here :


    become :

  9. Rob, I came across your noroute plugin AkCom_Controller_Plugin_NoRoute.

    Is there an easy way to make this work with non existent actions as well, rather than a __call in every controller?

    Instead of using a plugin I've thought about catching exceptions from dispatch() but that's just not as nice.

  10. Hi Kyle,

    You could probably do some reflection to work out if the action function exists in the controller class.

    It's easier to catch the exception to be honest :)



  11. Hi,

    I mashed together your NoRoute and's and I did end up using ReflectionClass. Do you have any idea what kind of performance hit this may have in big projects? With catching the exception, the 404 code would only be executed if it doesn't exist in the first place, but using reflection it's done every time. It is, however, nice to have all the 404 stuff contained in one nice plugin.

    Sometimes I put private functions in my controllers, like little helpers that really don't deserve to go elsewhere (e.g. filtering and validating the same post/get data on multiple actions). To display a 404 for private functions you have to then also use ReflectionMethod. But, although this may have been obvious, I noticed a better way to hide protected functions in controllers.

    Don't do:
    private function validateAction()

    private function validate()

    Because there's no Action at the end, to the dispatcher (and how I used ReflectionClass) it looks like it doesn't exist at all. Now I just need to make sure that I don't add "Action" to the end of method names out of habit (which is why it took me so long to notice this feature in the first place).

Comments are closed.