[johnzabroski]

Also, why does your ampersand-forms code return string objects for error messages? Seems very limiting, and a pain in the butt to extend. If you have a getErrorMessage() method, why aren't you returning an ErrorMessage object, which clients can then extend with error types (hard/soft, failure/warning/information), etc. Technically, it should just be an Error object. This would then lend itself well to advanced composition, where I can write program interactions in terms of signals (raising Error objects and Success objects, etc.)

Just some hopefully helpful advice.

[HenrikJoreteg]

In this case, they're meant to be as simple as possible and the individual field-views can do whatever they prefer, as they're the ones rendering them. The parent form only gets a `valid: true` and a `value` from the child. Since these are error messages meant to be used directly as error messages to users, it didn't seem like a big gain to do anything more.

With regard to "pain in the butt to extend" you could use `extend` and just replace that one method that returns those string, right?

InputView.extend({ getErrorMessage: function () { // return error objects instead? } })

/me shrugs

Forms really are a pain, we tried to create a simple contract between a form-view an it's child field views that was as flexible as possible so you could easily write more input types.

More on that contract here: http://ampersandjs.com/learn/forms#form-input-view-conventio...

But hey, also... easy enough to use something else entirely, it's not like the forms stuff is bundled :)

[johnzabroski]

Just simple advice.

1. The problem of adding more input types, as well as expressing more functions over existing and additional (unbound) input types, is a classical computer science problem called The Expression Problem.

2. It's really not about 'parents'. It is about workflows. "Can you lift 50 lbs?" may be a dependency for another question.

3. It's simple dependency inversion to use a list of Success and Failure objects to determine the state of a Submit button. This way Submit.Enabled = !list.Any(i => i.Failure). Why should Submit be responsible for knowing the structure of a form, such as fragile parent-child relationships that have no basis in reality.

4. There are really two kinds of dependencies. Layout and workflow. It's too easy to commingle these. Spreadsheets, for example, contain no such visual dependency between cells, only flow.