I am getting confused between domain/application logic and User Interface logic. To illustrate what I am trying to nail down, I will describe an imaginary program below for illustration purposes:
(1)
Imagine a small application with a set of 3 cascading drop-downs. As you select one dropdown it triggers a jQuery Ajax GET which ends up hitting a MVC controller, supplying the selected value of the previously selected drop-down. The controller returns the allowable choices for the next drop-down. The javacript (in the view) arranges these results into a drop-down. and so on. So each time you select a drop-down, the next one gets populated.
(2)
Now throwing in a wrench.. There are some exceptions. Lets say if the user selects “FOO” or “BAR” in the first dropdown, then the behavor changes, so that the second dropdown is disabled, and the thrid dropdown will show a texbox instead.
My questions is, in the context of MVC, what is the appropriate place for this “decision” logic? Such as the code that is responsible for making these decisions like I explained in (2). The most convenient place that I have been putting this was right in the javascript of the view. I simply wrote javascript to test if the first box is “FOO” or “BAR” then, disable the second dropwdown, and swap out the third dropdown for a textbox. But this does not feel quite right to me. Because It seems like it should be business logic therefore the code should belong in a domain layer some place. But that does not feel quite right either.
And so I feel like I am going in circles. Can some one shed some light on this little design?
Without splitting too many hairs or getting too fanatical on WHAT MUST BE DONE TO KEEP THE PATTERN PURE…
Obviously the Controller knows that this change must occur, as it will be handling both resulting cases (drop down selections or text entry). So putting logic relating to this in the Controller is not a sin.
It is also equally as obvious that the View must change how it displays depending on the contents of the first dropdown. While this mixing of behaviors isn’t exactly the best UI experience I could imagine, if requirements must, then the logic for this must exist to some extent in the UI. But, jeez guys, this is a website we’re talking about here. Do you really want to remove all logic from javascript and move it into a controller method? The View is deciding on how to display data, which is its job, and so cannot be a sin.
The real way to avoid getting burnt at the stake is to redesign to avoid the controversy in the first place. Or, just code it and bitch about your lousy design requirements over a beer.