Basic character management

[matthewphilyaw]

Following #21 we need to support character management for a user

• [ ] CRUD for Character to allow client to manage the characters
• [x] One character per game, name must be unique per game however the same character name can exist in other games.
• [x] Character will have a name
• [x] Player channel uses character_id to join with instead of user_id
• [ ] path should be something like api/users/:id/characters but needs some discussion.

this is to lay ground work for supporting characters. Keeping it simple to start with.

[matthewphilyaw]

@copenhas the second item I put in, thinking that the character is probably closely tied to a game not sure if that's the best way but just the direction I see. Any thoughts?

[matthewphilyaw]

path should be something like api/users/:id/characters but needs some discussion.

Torn between how this will be used externally and to be honest probably should be api/characters?user_id this way if we add any screens the list of characters in a game we can then support api/characters?game_id etc...

The user facing url on the client can be something like /users/:id/characters for the page which I think is valid, but not needed in the api.

[copenhas]

I agree that what a character can be and how it is created would be game specific. When we get there I think we should just hard code a basic character creation. Later figure out how games should be able to customize the process... You know when we might actually have a game.

For the API path, does JSON API have any guidance?

[matthewphilyaw]

Actually yeah. In fact thinking about it that's probably why preferred the api/characters. i need to check it cause that's what we want to follow. The client can be more flexible that's more or less presentation to the user.

[matthewphilyaw]

@copenhas So reading up on the recommended url design here I'm going to have to assume the following structures are probably what we will end up with.

1. /games
2. /games/:game_id
3. /games/:game_id/relationships/characters
4. /games/:game_id/characters
5. /characters

6. /characters?filter[user_id]=1&filter[game_id]=4
7. /characters/:character_id
8. /characters/:character_id/game
9. /characters/:character_id/relationships/game
10. /characters/:character_id/user
11. /characters/:character_id/relationships/user

If understand this correctly relationship urls return the barebones hashes like {"type": "characters", "id":"3"} for each character in the game for example referring to url 3, and url 4 would represent "related" links where you get the same list but the entire entity so in keeping with this example it would return the full character instead of just the id.

Links 9 would represent a one to one, in that 9 should return exactly one game id, and the related link on 8 would pull the entire game entity. This is the same for 10 and 11. Seems the convention is that singular means one and plural means many, hence why in 9 and 11 you get game/user.

I included game links here because the json api was mentioned here. I would imagine that the this would also mean we may want to bring back the user api and follow suite with

/users?filters.... etc...
/users/:user_id
/users/:user_id/characters
/users/:user_id/relationships/characters

don't know obviously seems redundant with filters on characters, but it seems that the point of all this seems to enable client to sort of pivot based on where it's at. So the point I guess is to allow multiple ways to get to the data reaching out from where every you are. So if you are looking at the user profile and want to list the characters you simply hit /users/:user_id/characters without having to do anything else. I have this sneaky suspicion that Ember Data will leverage these.

[matthewphilyaw]

Obviously we need to ensure that any creates updates or deletes are only allowed for the logged in users data. Certainly don't want one user modify another users character.

Think I would do a simple model for now just ensuring the if in the update matches the logged in user. However we may need to explore permissions more in depth when we add the ability create games etc.

[matthewphilyaw]

If we end up using this relationship/related url scheme I wonder if it's worth wrapping this up in a function or macro?

ja_url "/characters", Controller, [:games, :users]

and it generates all the pheonix routes, much like the resource macro does. It would gen all the verbs for CRUD etc.

Originally was thinking that you could do this

ja_url "/characters", CharacterController, Character

Which would work too I think, as the Character schema contains the associations, so it will show the belongs_to, and vice versa if we had has_many characters on the user. So then we could gen either singular or plural routes for the relationships.

Just have feeling this will become a pain if we don't have some tool to help gen these urls. Something to work toward I think.