derickbailey/backbone.modelbinding — Issue #57: Restructuring / Simplifying / Encapsulating
Author: derickbailey
Created: 2012-01-25 18:25:34+00:00
State: open

Issue #56 brings to light a series of problems in the current code base: extensibility and flexibility.

Right now, it takes a lot of work to add a new element type / control type to the code and it's not really possible to do this without making changes to the underlying source code.

The better solution would be to provide an extensibility mechanism that all of our element / control bindings use, which would allow 3rd party components to be configured easily, without having to include them as part of the shipping code. Plugins, basically.

There are a number of other problems in the code that would benefit from this as well. I think we're at a point where this needs to happen or the code is just going to get more and more bloated, and become a useless pile of junk.

I've been thinking about this from a number of other perspectives for a while, as well.

* The current configuration system is out of control and pieced together in a spaghetti-code fashion
* The inclusion of both data-bind and form binding tends to cause confusion and problems, because people only expect one or the other to be used when both always are.
* A better separation between the different facets of the system should exist, so that only data-bind or form binding are used, explicitly, when needed
* The code needed for handling dot-notation to get data out of child objects (in a separate fork on github) is also getting out of hand.

In general, I feel like the code base has outgrown it's intended use and it needs to be re-architected. It's so bad, in fact, that I've all but resorted to writing the basic form binding conventions in my apps, manually, again. I miss the days when the form binding code was only 15 or 20 lines and easily understood.

We need to re-think a lot of what's going on here, or this project will die from complexity and implode upon itself.