I have the Character model, with several models with a has_one association: Statistic, Fortitude, Reflex, Will, Armor, Hp and Initiative. These are all displayed on the Character show page.
What I want to do is create a horizontal menu bar that link to other pages with further information. The first one I want to do is an Items page, with various items such as Weapons, Armor, Magic Items, Gear and Treasure. I'm seeing these as separate models that belong_to the Character model, but I'm unsure how to go about building this.
Look, I made some visual cues (mostly because I am awful at explaining what I'm trying to do)
Here's a rough idea of how the final, styled application might look. At the top, you'll see "Items." This will be a link that takes a user to a new page, like so:
So now for more questions!
When I asked about this on Stack Overflow, several people said the models I've created for Character (Hp, Armor, Statistic, etc) should really be attributes. I'm not clear on how an attribute differs from a model. Can a user edit an attribute from the view the way a user can edit the model, the way I've built it? Am I creating too much complexity here? My thinking was that things that change (relatively) often, such as Items, Spells, Statistics, should be Models for ease of editing, styling and displaying, whereas things that don't change, such as a character's name, class, race, etc, would be created as columns in the Character model.
Should these be attributes instead of columns? Are columns attributes? I'm not entirely sure what attributes are, and it's hard to find concrete information.
In other news, I've been reading through the archives of railstips.org. I found an article about 12 great rails tutorials, but the problem is the article it linked to is 6 years old. What! So if you've got any great tutorials that are more recent, lay them on me.
Onward!
in Rails, attributes refer to "things that contain data in models" usually this means columns on persistent storage. Associations are just relationships between these "things that contain data". Try calling attributes on a model to see exactly what data we're talking about.
ReplyDeletehas_one associations are a funny case. Almost always you could put the columns directly on the parent model, instead of the association. Often though, you'll want this data only occasionally, or it needs to have a lot of functionality not related to the parent model, so you break it out into it's own model.
As a concerete example, we worked on a web-based game once that had a Character model, and two has_one relationships to Inventory and Population.
Population was somewhat bad to be split from Character because we displayed population data very frequently, so adding this extra step of indirection provided little performance benefit but did serve as a nice place to store methods that were specific to Population stats. If I had it to do over, I would have merged this into the Character model.
Inventory was used very rarely (only when attacking other users), and it had well over a hundred columns, lots of custom methods for generating attack ratings. It was pretty clear that this model would have been a disaster to merge into character.
Many Rails articles are old, but that doesn't always mean they are unusable, just that they are probably doing more work than they would have to for the latest version of Rails.
Yeah, the main problem with old tutorials is often the syntax will be slightly different or they'll be using a different database, but it's easy enough to convert it to what I'm using now. It's pretty painful when the tutorial calls for a PC with a MySQL database and separate program to create tables, though! I'm all "UGH, people did things this way?"
ReplyDeleteThis weekend I plan to get used to Git. I feel like I've been bouncing around a lot with my RoR learning, but I don't think that's necessarily a bad thing.