-
Notifications
You must be signed in to change notification settings - Fork 4
Captain / Alternate indicator on statscards #87
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
Re: S8 / MongoDB -- I'd like to switch to an "arbitrary attribute" sort of nosql / key/value model for teams, players, and stats at some mid-term point. Titles/geos/attributes already follow this model, which gives them huge amounts of flexibility. The issue is that the editing interface becomes significantly more complex than our current EditableTable, and it's not necessarily clear which attributes are required for the concept of a 'player' or 'team' to exist. |
I've gotten the sudden urge to take this head on after swearing at the editing UI over the last few days (love you Reilly :P). My real motivation is to completely overhaul the editing UI, but I see no point in doing that only to have to redo it once this is done. I completely agree that everything needs to move to k:v. We need flexibility at every level of a game/event and we just don't have it now. At a basic level -- rewriting this to the status quo -- I don't think the layout needs to change much. Currently you have the stattype (stype) which gives a name to a stat field on a player-by-player basis. You can similarly make the construct of a sport under which you can arbitrarily decided who gets what stat (a postition of 'G' gives you WLT Saves GAA and shows xyz information in the editing interface; a set of keys could be defined as a bio so it can be segregated, hidden, etc). So really your only difference from the editable table is that you get one editable table for players and one for goalies, which is already a better logical grouping. At that point, you're back to where we are currently, which means this could enter production without entirely fleshing out how to deal with additional data from an editing and a display perspective, and add as we figure things out. I need more time to think about handling an extended set of data, but I don't think that means we need to hold off, and I'm sure you've had some ideas in the past months. Let's talk this week if you have some time. |
Cool, are you free to meet Wednesday? Can you meet at like 9pm ET? I could maybe do 8pm if 9 is too late. I know we talked about doing this last year, and then decided to do it over the summer. Well, that didn't happen, so lets knock it out now. I don't think it'll be too hard to replicate functionality, especially if we can do it alongside the existing implementation to not impact production. I like the idea of grouping things for display. Could get a bit complex to set up different rules, but the result should be quite nice. |
Spitballing schema/editing: |
RE: Questions Do players have to belong to a team? How are players linked to a team? Should "teams" correspond to a single season? What attributes do players have to have? Any? Name? How do coaches fit in? Do we care about +/- being present? Should title just decide? |
This could go where the NHL 'flavor' logos are if the player is not a draft pick (which is most cases).
Collision details will have to be figured out. Also this will result in using s8/s8, so if we plan on tracking anything else we should look into expanding those (or switching to MongoDB).
The text was updated successfully, but these errors were encountered: