superMap should allow overriding behaviors to be added at config time.

[bmomberger-bitovi]

Condensed conversation motivating this:

[Client] How can we override save() when using a superMap
[Client] I tried adding a create(), update(), createData() and updateData() methods in myModel = DefineMap.extend({ here }). Then use superMap to map myModel
[Me] That’s a common mistake when moving from can.Model to can-connect
[Me] createData() and updateData() (or even save()) have to be overridden on the connection, not on the map.
[Me] But superMap() is unhelpful because it doesn’t expose the chain of connections.  It only lets you set the configuration object, on which you can specify *some* (but not *all*) functions to be overridden.
[Me] The steps to take are:
1) put updateData() and createData() (or save()) on the config object for superMap() and see if they are hit when saving.
[Me] If so great.  If not,
2) replace superMap with a call to connect that specifies the same set of connections as superMap does, but add your own connection to the *end* of the list.

It would be nice if we could just extend superMaps with an extra behavior when creating them. Something like:

superMap({
  name: "foo",
  url: "/api/foo",
  Map: Foo,
  List: Foo.List,
  extraBehaviors: [connect.behave(function(base) {
    return {
      save: function(map) {
         return map.validate().then(base.save.bind(this, map));
      }
   }
  })]
})

[justinbmeyer]

Thanks. I'm pretty sure there is another issue just like this in here.

[bmomberger-bitovi]

#87 is related but focused on manipulating the cache connection. We could address both in one effort.

[bmomberger-bitovi]

In addition to this it would be helpful to standardize or formalize which functions can be overridden on the config. Some can be, like parseListData and serializeInstance. Some can't, like save and updateData.

[justinbmeyer]

Closing for #288