Ryan is an engineer in the Sacramento Area with a focus in Python, Ruby, and Rust. Bash/Python Exercism mentor. Coding, physics, calculus, music, woodworking. Looking for work!
To clarify, I'm thinking of making a hash of "cocktail name", "Cocktail instance" pairs, because I commonly know the name of the drink but not the ID. But that's only if there's a distinct performance benefit to querying all of the records from the DB once and keeping them in a hash in memory. That way, in list view, I can say:
## Drink Group A- Drink A
- Drink C
- Drink E
## Drink Group B- Drink D
- Drink B
And spell that ordering out manually. And then, if I want to re-order the groups or the orders of the items next week, I can do that without having to figure out the ID's.
I'm planning on using this particular view basically like a Specials board at a restaurant where the particular items on this view might change from week to week and I would like to have fine-grained control over which ones show up where, and be able to adjust that every so often.
Right now I'm just trying to get something good enough to get up on the internet so I don't mind hard-coding the view this way and changing the code when I want to change the Specials board. I know that later, it would likely be easier to have some sort of table that keeps track of Specials board items and groups so that I could do all of this customization in the browser. But right now, like I said, the I've spent too much time thinking about cool ways I "could" do something without shipping anything and it's making me sad, so I really just want a quick, hard-coded way to achieve the minimum useful feature set right now.
Anyway, if grouping and ordering can't be done via SQL you can do it in memory as suggested by Ben and then test if it's fast enough. If not, you can cache it server side.
I don't think I fully understood the problem but +1 on shipping something that can be iterated :D
Ryan is an engineer in the Sacramento Area with a focus in Python, Ruby, and Rust. Bash/Python Exercism mentor. Coding, physics, calculus, music, woodworking. Looking for work!
Meh, that's the part I'm not sure about yet. For example, right now, I might have a cocktail under a heading of "Summer Favorites," but maybe it's so good that in October, I remove the "Summer Favorites" group but move that cocktail to the "House Specials" group instead. Or something. Haven't quite fleshed out the idea yet.
Ryan is an engineer in the Sacramento Area with a focus in Python, Ruby, and Rust. Bash/Python Exercism mentor. Coding, physics, calculus, music, woodworking. Looking for work!
Actually, now that I type that out loud, it gets me thinking that I should probably just make some sort of Group/Category model and render cocktails grouped by Category. Less hard-coding, reasonably easy to implement. Not sure. I seem to have gotten off track from my original question, but I feel like I've got several good options to go forward with.
Ryan is an engineer in the Sacramento Area with a focus in Python, Ruby, and Rust. Bash/Python Exercism mentor. Coding, physics, calculus, music, woodworking. Looking for work!
Do you mean something like this?
from guides.rubyonrails.org/action_view...
It's not clear to me why you'd want them to be transformed to hashes instead of using the objects queried from the DB
ps. if you use caching, cache objects IDs, not the serialized objects themselves
To clarify, I'm thinking of making a hash of "cocktail name", "Cocktail instance" pairs, because I commonly know the name of the drink but not the ID. But that's only if there's a distinct performance benefit to querying all of the records from the DB once and keeping them in a hash in memory. That way, in list view, I can say:
And spell that ordering out manually. And then, if I want to re-order the groups or the orders of the items next week, I can do that without having to figure out the ID's.
I'm planning on using this particular view basically like a Specials board at a restaurant where the particular items on this view might change from week to week and I would like to have fine-grained control over which ones show up where, and be able to adjust that every so often.
Right now I'm just trying to get something good enough to get up on the internet so I don't mind hard-coding the view this way and changing the code when I want to change the Specials board. I know that later, it would likely be easier to have some sort of table that keeps track of Specials board items and groups so that I could do all of this customization in the browser. But right now, like I said, the I've spent too much time thinking about cool ways I "could" do something without shipping anything and it's making me sad, so I really just want a quick, hard-coded way to achieve the minimum useful feature set right now.
Does that make sense at all?
How does one cocktail belong to a group or another?
Rails has a helper method called option_groups_from_collection_for_... but it might not work because there's only one relation?
Anyway, if grouping and ordering can't be done via SQL you can do it in memory as suggested by Ben and then test if it's fast enough. If not, you can cache it server side.
I don't think I fully understood the problem but +1 on shipping something that can be iterated :D
Meh, that's the part I'm not sure about yet. For example, right now, I might have a cocktail under a heading of "Summer Favorites," but maybe it's so good that in October, I remove the "Summer Favorites" group but move that cocktail to the "House Specials" group instead. Or something. Haven't quite fleshed out the idea yet.
Actually, now that I type that out loud, it gets me thinking that I should probably just make some sort of Group/Category model and render cocktails grouped by Category. Less hard-coding, reasonably easy to implement. Not sure. I seem to have gotten off track from my original question, but I feel like I've got several good options to go forward with.
Yep! You can also just have a
categoryfield for them ifcategoryhas no other associated metadata.Ooh good point. Hm. OK I have some thinking to do. Thank you for your help!