Question

Rather than use a full-blown PHP MVC, I’m designing one that will best-fit my uses. I have the basic framework done, and have coded the models and controllers I’ll need to run my website.

Now I’m moving onto the Views, and I’ve encountered a small dilemma. My approach is working fine for me, but for future reference, I want to know if what I’m doing is a bad habit to get into.

What I’m trying to do:

In my View, I’m calling a Model that runs my authentication system, and requesting the login status of a user. I then use that boolean to decide whether to show certain elements within the view, and where to place others.

Should I be designing separate views for each login status, or is this approach fine? However, if I’m going to be implementing this MVC into the work I’m doing for my clients, I need to use the best practices.

Any advice would be appreciated!

Answer 1

Can I call the model from the View?

Yes, you can. As long as you maintain the separation of concerns between M,V and C, you are free to call upon the Model (or the Controller) from the View. Most MVC diagrams show a bidirectional connection at least between View and Model. What you don’t want to do though, is place logic/code from the Model (or the controller) into the View and you don’t want to modify the model from there.

For example, you might have a widget on your page that aggregates the latest ten blog posts headlines from your favorite blogs on each page of your website. You get the headlines by calling, say MyFavFeeds::getLatest(); in your model. What are your options now?

1. You could add the code to fetch the headlines into the controller, but that would require you to replicate it in each and every controller action, which is against the DRY principle. Also, the controller’s concern is handling user input for specific actions and fetching the headlines on each call is likely not even related to these actions.
2. If your architecture supports it, you could fetch that data in some sort of preDispatch hook, that is, the headlines get loaded and injected into the View from a plugin or callback. That would be DRY, but a second developer might not be aware of that plugin and accidently overwrite the variable holding the headlines from his controller action. And there might be cases in which you wouldn’t want to load the headlines, e.g. when just rendering confirmation pages for form submissions, so you’d have to have mechanism for disabling the plugin then. That’s a lot to consider.
3. You place the call to (not the code of) MyFavFeeds::getLatest() into the View or Layout template or, better, a ViewHelper, that encapsulates the call to your model class and renders the widget. This way you don’t have to worry about overwriting any variables or repetition. And when you don’t need the headlines on your view, you simply don’t include it.

About your other question:

In my View, I’m calling a Model that
runs my authentication system, and
requesting the login status of a user.
I then use that boolean to decide
whether to show certain elements
within the view, and where to place
others.

Authentication is something you will want to do early in the application flow, before any controller actions are called. Thus, you should not run your (entire) authentication system in the View. The actual authentication is not View-related logic. Just requesting the user status after authentication, on the other hand, is okay. For instance, if you want to render a widget showing the user name and giving a login/logout button, it would be fine to do something like

<?php //UserHelper
class UserMenuHelper
{
    public function getUserMenu()
    {
        $link = '<a href="/user/logout">Logout</a>';
        if(MyAuth::userHasIdentity()) {
           $link = sprintf('<a href="/user/logout">Logout %s</a>',
                            MyAuth::getUsername());
        }
        return $link;
    }
}

If you got larger portions of your GUI to be modified by a User’s role, you might want to break your View apart into partial blocks and include them based on the status, instead of writing all the HTML into a View Helper.

If you are only looking to render a navigation based on the user role, have a look at Zend Framework’s Zend_Navigation and Zend_Acl to see how they do it.