AMD and other feedback etc.

[nevf]

I've read through the docs and tried the examples and GDB looks good. I am currently using http://weepy.github.io/o_O/ in an app and it has several shortcomings, including the lack of as you type model updates. I've also spent a lot of time searching for simple 2-way binding code and there isn't much around unless of course you use larger MVC, MVVM etc, frameworks. Other that o_O the other lib I've considered is rivets.js

A few things I'd welcome in GDB include AMD support, a non-jQuery implementation and moving the pollyfills to a separate module.

Also do you have any plans / thoughts on publishing a 'change' style event when content changes.

-Neville

[JohnLouderback]

Hi Neville, It has been said that necessity is the mother of invention. I built GDB because there was a gap that needed filling. Prior to making it, I could not find anything that quite fit my needs. Like you said, you're pretty much left with big frameworks. My issue with frameworks is that, as the name suggests, you have to learn them and then build around them. GDB is a drop in of sorts. Rivets.js had previously caught my eye, along with a couple other possibilities like buckling down with Angular.js. The problem I personally experienced was that there was no out of the box binding capabilites for "contenteditable" elements and thus I was being limited to form elements. GDB works with zero configuration on any element. I'm glad to see that you appreciate this quality of GDB and I greatly appreciate the time you took to post feedback, as it is more than welcome.

1) I think AMD support is a great idea. I will investigate what I need to do to make this a compatible module.

2) A non-jQuery implementation is something I would like to do as well. I'm glad to see there is interest in this. I will need to investigate alternatives to the jQuery methods I've used here, as some are more complex. I highly suspect this is will increase the file size a good bit, so I think I may want to maintain a jQuery version side-by-side with it for people who are already using jQuery in their project. Managing two code bases for this may seem a bit daunting, but it seems like it should be worth the extra effort.

3) Moving the polyfills to a separate module may be beneficial. Alternatively, I may scratch the "forEach" polyfill all together, since it's on the very edge of supported browsers, anyway. As for the Object Observe polyfill, I'm not sure I should make this separate at all for the time being since the native alternative is only available as an experimental feature in Chrome's canary build currently.

4) As for a "change" event, currently there is a callback function referenced in the documentation for when the model changes. The function is called every time the model changes. This means if the data is changed in the model directly, or if an element changes the model, the function gets called. Currently, there is no information passed to the function about what changes. In the near future, I would like to add this information for the callback function. If, perhaps, you meant something different, please let me know. I love hearing people's thoughts and cool ideas. I'd be happy to enhance the plugin in such a way that it is better suited to your work-flow.

Thanks, -John

[nevf]

HI John, Thanks for taking the time to write a detailed reply. Sorry for my delay replying but apart from a busy Easter I hadn't notice you'd replied until now.

A non-jQuery version would be nice but I wouldn't rush to do it unless you get more interest. I'm trying to use jQuery less and less over time and just using the common native browser functions for dom access etc.

I wasn't aware of the change event. It needs to specify what model propery and/or dom element changed and what the new value is. I suspect knowing the old value could be of use on occasion.

It could also be handy to have a function that you pass a model property and it return the element bound to it and vice-versa.

-Neville

[JohnLouderback]

Hi Neville,

I will definitely be adding AMD module support and possibly even CommonJS support as well. This should be online in a day or so.

I've added a few new features as per your suggestions. I have not yet commit them to this repository because I wanted to know if you would like to test them first and offer your feedback. The beta can be had here: http://gdb.thewebdev.guru/betas/jquery.gdb.v1.1.2-beta.zip

I've added a few new features to this beta.

Methods:

GDB.getBoundElementFromModelPath( path ) - this get will return a jQuery collection of elements bound to a property based on a string representing the path in the model. Example: "teacher.name" or "teachers[3].email" will return the elements bound to these properties.

GDB.getModelPathFromBoundElement( element ) - given a selector string or DOM element, this method will return path to which it is bound to in the model. It will return false if no matches are found.

GDB.getValueFromModelPath( path ) - given a path to a property in the model, this method will return the value of the specified property.

Callbacks:

modelChangeCallback is now passed an object as an argument whose properties are: ->locationPathStringThe location in the model as a string ->$boundElementsThe bound elements as a jQuery collection ->newValue The new value of the property ->oldValue The old value of the property

A new callback elementChangeCallback is now present. This function is called whenever an element has changed. It is passed an object as an argument whose properties are: ->locationPathStringThe location in the model as a string ->$boundElementThe element changed as a jQuery object ->newValue The new value of the element

I haven't yet had the opportunity to do much testing with these as of yet, but they should work well. If you could test these and let me know if they meet your needs, I would be glad to work off of any feedback you could offer me.

Thanks, -John

[nevf]

Hi John, Thanks for all of that. I've got a busy few days and it's a short week so I probably won't get a chance to play until the w/e or next week.

[JohnLouderback]

Hi Neville, Great to hear. Hope it helps. I may do some testing between now and then and if everything seems solid, I may commit the new changes. If that happens and you find any issues you have thereafter, we can commit those necessary changes as well. In the mean time, I'll try working on adding AMD and CommonJS support in the next few days. Thanks, -John

[JohnLouderback]

Did these additions work for you?

Thanks, -John

[nevf]

I haven't tried an exhaustive use, but from what I have done it is all good.