This repository was archived by the owner on Jul 24, 2023. It is now read-only.
Refactor Recipes and Recipe creation#103
Open
tgomezzzz wants to merge 5 commits into
Open
Conversation
angplee
approved these changes
Aug 6, 2020
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This PR refactors internal recipe creation, simplifying the recipe creation servlet. Previously, the doPost() method of NewRecipeServlet built a recipe Datastore entity by first extracting individual parameters with request.getParameter() and then setting the entity's properties. The PR scraps this approach, instead adding a Recipe constructor that takes in a Map, allowing one-line recipe creation using request.getParameterMap(). Instead of extracting each individual parameter from the request, the new constructor iterates over the key-value pairs in the map and stores the parameters in their corresponding Recipe fields. This iteration approach yields an advantage for the parameters that vary in number from recipe to recipe (tags, ingredients, equipment, and steps.) The servlet no longer needs to extract these parameters in the getParameters() method, which required a while loop to get the unknown number of each parameter. Since the new constructor iterates over every key-value pair, these parameters are simply added to their corresponding Recipe field collections as they're encountered. Once the iteration finishes, the constructor builds a Datastore entity from the parameters it just stored in its own Recipe object.
The PR also adjusts how tags, ingredients, equipment, and steps are stored in Datastore. Because these parameters were previously extracted with getParameters(), which returned a Collection of EmbeddedEntities, they were all wrapped in EmbeddedEntities in Datastore. Now that getParameters() is no longer used, this adds an unnecessary layer of complexity when saving recipes to Datastore and retrieving them from Datastore. This PR changes tags, equipment, and steps to be stored as a Collection of strings, while ingredients remain EmbeddedEntities to account for their additional properties. This allowed me to remove redundant helper methods that converted a Collection of EmbeddedEntities into tags, ingredients, equipment, and steps, as well as the entire Step class, which in retrospect served no real purpose.