Models inside FruitMachine

[wilsonpage]

I am not happy with the api new FruitMachine.View() at the moment. It's pretty verbose. The reason it is like this is because at one stage FruitMachine has the API new FruitMachine.Model() like Backbone.

I guess my question is: Is it enough for fruit machine to just manage Views, or should the namespace be kept open in the event we may need Models in the future.

I would be cool if users could plug in their own models instances. Could FruitMachine Views work with Backbone Models for example?

This would be you could do something like:

view.data(myModel);

// or

view.model(myModel);

Internally FruitMachine would have to call model.toJSON() before rendering, or allow the user to provide a custom getter method.

[matthew-andrews]

I like the focus and simplicity that FruitMachine being a view renderer gives us. I like your idea of plugging in models (and potentially supporting any via plugins) but I don't know how that would look. For the time being I'd be all for changing the API from new FruitMachine.View() to new FruitMachine().

[matthew-andrews]

Spent some time looking through Backbone's code. I think your initial thoughts were right - FruitMachine should purely be a view renderer rather than a do-everything library like Backbone is - and therefore I think it would be right to simplify the in-app API from FruitMachine.view to FruitMachine.

But maybe we could work towards implementing the full Backbone API for other pieces of app logic as part of any refactoring of History manager, router, etc. It would be great if one day if we had the option of swapping out FruitMachine with Backbone (ie. run a find & replace to swap FruitMachine with Backbone.View (and History to Backbone.History, etc), run our unit tests and have everything continue to work).

I think we can actually do better than Backbone in terms of lighter, more decoupled code with our concept of plugins - (eg. I like how our delegate object is decoupled from FruitMachine, whereas in Backbone it's tightly coupled).

Interesting things in the backbone source:-

Optimized internal dispatch function for triggering events. Tries to keep the usual cases speedy (most Backbone events have 3 arguments).

var triggerEvents = function(events, args) {
    var ev, i = -1, l = events.length;
    switch (args.length) {
    case 0: while (++i < l) (ev = events[i]).callback.call(ev.ctx);
    return;
    case 1: while (++i < l) (ev = events[i]).callback.call(ev.ctx, args[0]);
    return;
    case 2: while (++i < l) (ev = events[i]).callback.call(ev.ctx, args[0], args[1]);
    return;
    case 3: while (++i < l) (ev = events[i]).callback.call(ev.ctx, args[0], args[1], args[2]);
    return;
    default: while (++i < l) (ev = events[i]).callback.apply(ev.ctx, args);
    }
  };

Also it would be nice to port over the once event (which JC wanted I believe) - which would mean we might be able to use this event system for our global app events one day too.

Bind events to only be triggered a single time. After the first time the callback is invoked, it will be removed.