Skip to main content
8 events
when toggle format what by license comment
Jun 16, 2020 at 10:01 history edited CommunityBot
Commonmark migration
S Jul 4, 2016 at 20:39 history suggested Matteo Tassinari CC BY-SA 3.0
indegrient -> ingredient
Jul 4, 2016 at 20:38 review Suggested edits
S Jul 4, 2016 at 20:39
Jul 4, 2016 at 1:34 vote accept Luca Fülbier
Jul 4, 2016 at 1:30 comment added Luca Fülbier @JoshCaswell You could encapsulate measurement unit data in its own class aswell. That would give you the advantage, that you could easily translate between different unit systems. You would model the Ingredient "Water" with the UnitType "Fluid" and measure it in litres, or fluid ounces. Based on the users preferences you could then translate between the two.
Jul 4, 2016 at 1:26 comment added Luca Fülbier The IngredientUse class is a good idea. I would have needed to save the additional information anyways, so i might aswell put it in a separate class. If you want to combine the generic Ingredient and IngredientUse approach (encapsulate recipe specific ingredient data, but still be able to create generic ingredient descriptions, pictures, etc), how would you do that? Save the id of the generic Ingredient in your IngredientUse class and query it, if needed?
Jul 3, 2016 at 22:03 comment added jscs Introducing this "IngredientUse" type is clearly the way to go. I'm working on a problem with a very similar structure at this very moment, and I've concluded that wrapping those persistent records into a second, more transient entity keeps the associated data in its proper place and lets the Ingredients be reused across recipes. (The bit I'm puzzling over is where to store the "unit": it's part of the recipe that the honey is measured in mL instead of g, but it's still useful information the next time the ingredient is used anywhere.)
Jul 3, 2016 at 21:09 history answered Christophe CC BY-SA 3.0