"dependencies": {
"spine": "spine/spine",
"jade": "1.8.1",
"stylus": "0.49.3"},@findByAttribute(name, value) and @findAllByAttribute(name, value) seems a bit limiting. I currently have a case where I want to be able to findBy-Multiple-Attributes, which I can do with select, but it seems like it would be easy to add support to these two methods to take an object and then have it return records that match all the key/value pairs in the object while keeping the current function signature available as well. Thoughts?
lodash-amd does a great job of having lots of small modules in the same repo: https://github.com/lodash/lodash-amd
and a problem I do not know how to solve. Let's say I have a model 'Binary' and 'Categories' with an m:n relation and a table that lists all binaries (including one column for the categories it belongs to). Now I'd like to wait for Binaries.fetch() AND Categories.fetch() to have completed before rendering that table. With promises I could do something like:
p1 = Binaries.fetch()
p2 = Categories.fetch()
$.when(p1, p2), -> render
but I don't see how to to that in Spine...espacially in combination with the element pattern
@michelkaeser
is there a way to delete the record from Spine without trying to make an Ajax request (because in that case it will fail because the record doesn't exist anymore and re-add it)?
You can pass ajax: false into the method options to disable ajax for an action, e.g. record.destroy(ajax: false). Is that what you mean?
Binaries.ajax().fetch() which returns the jqXHR object that should work with $.when().
destroy() method rather than using events. If you're using model relations it might look something like:destroy: ->
@user().destroy()
super
@supernintendo sorry for the late reply.
There aren’t currently any plans to move away from CoffeeScript. That being said, I’m personally a little sad about the direction CoffeeScript seems to be headed… If it continues to go stale, I’d be in favour of an ES6 rewrite.
My team at Lightmaker is pretty heavily invested in Spine, so if CoffeeScript dies, it would probably be easier for us to refactor our codebase (and Spine) in ES6 than switch to different library. An ES6 refactor could be mostly automated, but switching libraries likey couldn’t.
TL;DR - Short term: CoffeeScript. Long term: (IMO) If CS dies (or there’s enough demand), ES6.
