cute

My motivation with the FormField stuff was to remove the need for the app developer to manage any sort of intermediate framework objects for form data. They would manage their app-specific data struction (e.g. Person) and the framework holds the InputValues and knows how to update the app-specific structure automatically.

My original vision was something that let me do:

  new Input(
    labelText: 'Name',
    mapsTo: person#name
  )

then person.name is the Real Truth for what is shown in the Input, and is updated whenever the Input changes. Dart doesn't quite let us do that, so supplying a setter was the next-best thing. There's a proposal for adding tear-offs to Dart, but AFAIK it isn't official adpoted. If it were, we could do:

  new Input(
    labelText: 'Name',
    setter: person#name=
  )

which seems close enough. IMO that's the direction we should be heading.

Maybe we should have a sub-class of Input that allows you to do the short-hand with conversion between InputValue and String, rather than a separate FormField argument to Input?

One problem is that the value of an Input (an InputValue) has a selection, but the data model is a String, so it can't be the exclusive ground truth.

Another complication is with forms that you prepare and then submit (vs those that are "live"). For example the expansion panel example used to save even if you hit "Cancel"; this patch attempts to fix that.

But yeah, I don't like that you have to have all these FormField objects everywhere.

One problem is that the value of an Input (an InputValue) has a selection, but the data model is a String, so it can't be the exclusive ground truth.

The selection is a property of the editor, not the data model. I think as an app developer, I'd just want the framework to manage that behind the scenes and not tell me about it (in the general case).

Another complication is with forms that you prepare and then submit (vs those that are "live"). For example the expansion panel example used to save even if you hit "Cancel"; this patch attempts to fix that.

I could see that also being fixed by providing a temp object, which gets swapped with the final object on submit. e.g. use tempPerson everywhere, then in onSubmit just do finalPerson = tempPerson;

Yeah, that seems reasonable.

Another issue is how to handle external changes in the model.

I like your original vision but I don't see how to make it work with external changes to the model. It'd need some sort of scaffolding around it.

I'm not sure where to go with my patch here.

The selection is a property of the editor, not the data model.

This is an interesting observation. It's tricky because the selection is tied to the string in many ways. What would one expect to happen if we had two text fields backed by the same string, such that editing one changed the other — should the selection be mirrored in both? What happens if the selection in one becomes invalid because of edits in the other?

I started refactoring Input so that the InputValue was kept there and not in FormField, but that won't work. It would prevent you from changing the selection (e.g. because you want to start the form with a word selected so it can be easily replaced).

If:

• data can't be a plain dart object because otherwise how could it notify the form of changes, and
• we want to have an adapter from string to InputValue

maybe the solution is that the Form holds an object that contains FormFields which have an API for Inputs to read out of an an API for users to write into. I'll have to think more on what that would look like.

Yeah. Some sort of observable view-model.

@mpcomplete the changes in this PR for this file attempt to implement the save/cancel buttons (previously they were bogus). It'd be interesting to see how this would look under your patch (it's not great under this one).

@mpcomplete similarly these changes were to actually implement the "SUBMIT" button which previously was dummy. It also makes the lifeStory be saved (previously it wasn't).