Mail archive

[Acf] On subitting button info to the view

From: Nathan Angelacos <>
Date: Thu, 08 May 2008 16:40:28 -0400

[Ted was asked why he didn't want the "button" cfe to be included in the
   object to the view. After a few discussions, here's a summary he
wrote up for us.]

Unfortunately, the document "Enforcing Strict Model-View Separation in
Template Engines" is not about enforcing strict model-view-controller
separation. It leaves out the controller entirely, except for a brief
section (4) about MVC. So, most of the document takes some reasoning to
apply to our system.

First, note that in section 7 point 5, it says that "data from the model
must not contain display or layout information." So, the model cannot
generate cfe's defining buttons. Then, in section 4, it says that "the
various page code snippets are also part of the controller and should
limit their activities to pulling the appropriate data from the model,
session, or parameters then pushing that data into the view." This does
not leave any room for us to generate cfe's defining buttons in the
controller code either. So, the only place where buttons can be
defined, or created, is in the view.

Logically, this makes sense. The controller's job is to perform any
necessary action and return the resulting data. Why should it tell the
view what to do with that data (which is what buttons do)? The view's
job is to display the data and provide options to the user. In some
views, such as html, buttons make sense. Whereas in others, such as a
text interface, buttons make no sense at all. It should be up to the
view to determine which options (actions) it makes available to the user
and how they are displayed. If a view designer wants to change from
using a button to using a link, should the controller care? No, it
still performs the same action.

So, how does the view determine which of the Start / Stop / Restart
buttons to make active? I think that the status action of the
controller should return a boolean reporting whether or not the daemon
is running. The view can then look at that boolean and determine which
buttons to make active (as well as what text to display).

What about the question of performing logic in the view? In section 7
point 2, it says "the view cannot perform computations upon dependent
data values." Determining which options (actions) to make available to
the user is not a data computation. Even if the decision is based upon
data (such as a boolean) from the controller, there is no computation
(math) involved, simply an 'if' statement. We already have much more
complicated logic (like for loops) in the view to display the data.

So, I don't think it's necessary for the controller to tell the view
which actions are valid. The view designer must know enough about the
controller to know what actions are available and what they do in order
to do his job.

An example to show why the controller shouldn't define buttons: Let's
say we have a nice neat action that handles a form. It takes in a bunch
of client data, validates it, sets it, reports back errors. Now,
someone designing the page decides it would be really nice to have a
completely unrelated button at the bottom of the page. Should you go
back to your action, which does a nice job of handling a form, and add
in code to return the new button? No, that would be implementing your
view in the controller. The new button in the view is entirely a
decision of the view designer and should not affect the controller.
This is just to show that the logic of which buttons to display is
something that is view-specific and should not be in the controller.

So, thatís the explanation of why we should not define buttons in the

Received on Thu May 08 2008 - 16:40:28 UTC