I'm struggling since a few hours with this design question.
In Cocoa for example, a complicated Date Picker is just a View. But it HAS a lot of complicated logic and algorithms to enable picking dates.
In this case, I want to create a form element component for multi-selection of objects (i.e. when defining a relationship Users 1:n Photos the multiselect will allow selecting multiple photos at once). After all, it's just a form field, but a fairly complicated one.
My framework has ViewController classes and View classes. View classes use View Templates and have all the logic to fill their Templates with data and to render them out.
When setting up such an Multiselect Form Input Field, there's some setup to be done: - which class is linked? - which link constraints are there? (i.e. a user may only select his own photos) - which objects/items must be offered for selection (= retrieving them!) - which are already selected? - must the user select at least one, or is none also ok? - many more
What irritates me is, that Apple's Date Picker is really just a View. I believed that Views have to be stupid like bread. But obviously, something that lets you pick a date is damn intelligent. It knows the whole calendar, it knows if a date is valid, it can even show you possible dates or an entire calendar to pick one.
So how do I decide if I need a ViewController or not?
And then, when I do take a ViewController approach here... don't I get some inconsistency then? How about plain boring text input fields? Well, they may have some sophisticated form validation code as well.
Maybe my question title is bad and should be "When to make something a View Controller instead of a plain View"... feel free to edit it, if you don't mind. I'm totally confused now ;)
(I'm developing a little PHP web framework where I try to stick as much with the "feel" of Objective-C / Cocoa design style as possible, so it's all for the web, not for the desktop)