How Plantly works

Plantly is like an onion

(I didn't mean that it's layered. It made me cry)

Context diagram

A smart person once defined the context diagram as follows: it is the document that encapsulates the whole essence of a piece of software that you can show to a non-technical person.

As it happens, that also makes it the best overview-giving-scheme there is.

Additional information

This is a link to Installation notes, which includes short step-by step overview of activities that were made to get the application (front and backend) running in AWS server

This is a link to Component diagram, which includes short overview of the current production line.

Backend description

The description of the backend are as follows:

1. On initialization, data concerning all the regions (based on the World Geographical Scheme for Recording Plant Distributions are downloaded and saved as "Region" objects by using RegionService. Each Region object consists of region id, name, appreviation, the id of the parent region and the number of plants found in it. From it , the list of region names (728 items) are served to the front end for choosing the region (localhost:8080/api/region_names). If region is chosen, the number of plants in the region is checked. If the number is 0 (estonia for example), the parent region is chosen instead (Baltic States instead of Estonia) ("SetAZone" method in IndexController). Region id is applied to the outgoing requests to trefle.io to receive plants that are characteristical to the region.
2. Plant browsing is done by sets of 20 plants as they are received from trefle.io. The default address is https://trefle.io/api/v1/plants?token=ID (&zone_id=id if applicable). Plants are served to front end at localhost:8080/api/plants by a method BrowsePlantsByPage in IndexController. Methods nextPageOfPlants (localhost:8080/api/plants/next), previousPageOfPlants (localhost:8080/api/plants/previous) and BrowsePlantsByPage (localhost:8080/api/plants/page_nr) are for getting the next page, previous page or page specified. All of these methods update the page number which is added to the address. Visited pages are saved to local temporary map, which is cleared when the region is changed or new inquiry from the front end is received. The idea of local temporary map (activePlants) is to reduce the amount of requests to trefle when browsing plants.
3. In addition to browsing, filtering by parameters and search by plant name is enabled. The request is taken in as a GetPlantsRequest object. Fields are checked for contents and address is composed by searchPlantsByMultipleCriterias.
4. Majority of the data handling from trefle.io is done by utilizing the PlantParser class in package additional. This enables to parse the data to JSON, read out the plant id values and when asked retrieve chosen fields from plant data to compose the plant object which is stored local temporary h2 database under PlantsService class.
5. Due to the nature of the data available in trefle only single fields are used and stored manually. These field mostly incorporate information about the plant's physical appearance (flower color, plant type, height, spread) and the gardening needs (requirements for light, water, nutrition, the soil composition peculiarities etc).
6. In addition, possibility to compose own unique garden is allowed by GardenController. This provides methods for saving plants (plant has garden flag which is then raised by savePlant at localhost:8080/api/garden/save/plantId), viewing them (getGardenContent at localhost:8080/api/garden) and deleting (removePlant at localhost:8080/api/garden/delete and removeAllPlants at localhost:8080/api/garden/deleteAll). In the last case a map on a plant is updated with the information about other plants in the garden selection at that moment. This allows viewing possible plant combinations when choosing plants to garden selection.