Closed llafuente closed 11 years ago
Thanks, I like the ideas as having these things as helper functions. What you are doing is mixing in these methods onto each class rather than inheriting from a common class, which I like the idea of.
I avoided having inheritance in the first place because each class felt too different, but maybe it's time to actually have a think about these things and factor out the stuff that's common - been a while since I've worked on the back end part of this.
At any rate, I do agree that at least some of this is sensible functionality to include, I'll spend some hours on it now if I can, and give you some better feedback asap :]
Took some of the functionality, modified it, made some of it more general, and added it to a new base class instead and will see if I can use that. This is better than having them being attached to each class later as I can use them properly within the library.
Will close this when I get the classes to inherit from this, and use its functionality.
Ok, better to extend from a Base class
I checkout the head and there is an error in currentRound
Base.prototype.currentRound = function (section) {
var rnds = this.getRounds(section);
for (var i = 0; i < rnds.length; i += 1) {
var r = rnds[i];
if (!this.isRoundDone(r[0].id)) { // <--- here! currentRound is the first not done
return r;
}
}
};
Two more functions, now using the new Base class I found them usefull while looping matches having my app data inside your structure so i don't have to look in both sites.
Base.prototype.setCustomData = function (id, customdata) {
var i,
m;
for (i = 0; i < this.matches.length; ++i) {
m = this.matches[i];
if (id.s === m.id.s && id.r === m.id.r && id.m === m.id.m) {
m.cdata = customdata;
}
}
};
Base.prototype.getCustomData = function (id) {
var i,
m;
for (i = 0; i < this.matches.length; ++i) {
m = this.matches[i];
if (id.s === m.id.s && id.r === m.id.r && id.m === m.id.m) {
return m.cdata;
}
}
};
Thanks. currentRound
, though I still have it commented out, was indeed wrong.
The customData is something I have thought about, but consequently forgot about. However, since you can now find a match directly, with Base::findMatch(id)
having two helpers to mostly do that feels unnecessary.
I think it's better we explicitly encourage using the data
key on a match object for custom data. Seems more sensible to me.
Many of your ideas have been implemented in an improved form in 0.12.0 that was just published.
See current base.md for documentation of the common methods.
Thanks for your ideas! :]
Hi,
I was working with this module for a few days and I found myself looping continuosly gathering some basic data so I implement many functions that will help you to extract the tournament status.
I dont know if you like camelcase or snakecase, in my case I prefer snake, I'll leave it up to you if you want to modify/rename some functions.
isRoundDone(round) tells if every match in the round has score
getRounds() return all rounds
getRound(round) return round data
getMatches(round, removed_finished) get matches list, alias of getRound if removed_finished=falsy
getMatch(match) return match data
getCurrentRound() return the fisrt round that some matches didn't have score
getNextRound() return the fisrt round that some matches didn't have score
getPosition return the fisrt round that some matches didn't have score
getPlayersIn return the fisrt round that some matches didn't have score