Package com.tccc.kos.ext.dispense.pipeline.beverage.graph

Class BevGraph

java.lang.Object
com.tccc.kos.ext.dispense.pipeline.beverage.graph.BevGraph
public class BevGraph extends Object
A graph of dependencies that are used to compute beverage, brand and group availability information based on pump status and other override inputs.

A graph is always constructed using a BevGraphBuilder and once constructed can be used to modify availability at various points in the dependency graph and have the resulting changes generate events.

For information about how to construct a graph see BevGraphBuilder. In short, a graph is constructed as a collection of nodes that link pumps / ingredients at the bottom to beverages, to brands and groups at the top. State changes ripple up through the graph and ultimately result in changes to beverages, brands and groups.

It is possible to construct a very simple graph where ingredients are combined with waters in a legacy BiB setup or a much more complex graph that describes ingredients, recipes, beverages, and even mix based beverages in which a beverage is described as a combination of other beverages.

There is support for three type of top level entities:

  • beverages : These represent pourable beverages by id and indicate visibility and availability of those beverages. These id's are matched up with additional meta data in the ui which describes the other properties of the beverage. In very simple cases, the id can be formatted such that it includes data the ui can consume. Beverage id's are also passed back to the engine to select a beverage for pouring so the engine is responsible for also being able to reverse an id back to the information required to pour the beverage.
  • brands : This is such a common pattern that is is built into the graph. A brand is typically a collection of related beverages. For example, the brand Coke may include beverages such as Coke, Cherry Coke, Coke with Lime and so on. The brand data will identify the availability of the brand (visible if any beverage is visible and available if any beverage is available) as well as include the availability information for each beverage in the group. This allows external code (such as a ui) to derive the beverages from the brand without needing to use additional meta data to capture the relationship. Multiple brands can be created and a beverage can appear in multiple brands.
  • groups : A group behave the same as a brand but is returned in a separate list from brands. This allows brands to be used for the most common use case, but still provides groups to add additional named availability groups that serve a different function. A common example is beverage categories such as fruit flavored or low calorie drinks. These are often managed as filters in ui code but by creating groups in the graph, the ui can both easily tell when there are no visible / available beverages in the group and hide / disable the group as well as get the beverage list without needing to perform the filtering on the ui side. By keeping brands and groups separate, the ui doesn't need to filter them determine which is which.
Since:
1.0
Version:
2023-02-07

  • Field Details

  • Method Details

    • incVersion

      public int incVersion()
      Increment the version of the graph.

    • getBeverages

      public List<Availability> getBeverages()
      Return beverage availability.

    • getBrands

      public List<Availability> getBrands()
      Return brand availability.

    • getGroups

      public com.tccc.kos.commons.util.MultiValueMap<String,Availability> getGroups()
      Return group availability.

    • getNode

      public GraphNode getNode(String id)
      Get the node with the specified id

    • getBeverageNode

      public BeverageNode getBeverageNode(String id)
      Get the beverage node with the specified id

    • getVersion

      public int getVersion()