alphagov / digitalmarketplace-content-loader
99%
master: 99%

LAST BUILD BRANCH: bk-add-boolean
DEFAULT BRANCH: master
Repo Added
Files 12
Badge
Embed ▾
README BADGES
x

If you need to use a raster PNG badge, change the '.svg' to '.png' in the link

Markdown

Textile

RDoc

HTML

Rst

LAST BUILD ON BRANCH checkbox-tree
branch: checkbox-tree
CHANGE BRANCH
x

252

push

travis-ci

galund 
Taxonomy (category tree) implementation - simplification

  - https://trello.com/c/y79rP1KA/197-suppliers-choose-a-category-backend
  - less is more - don't need to build another tree structure
  - also tidy up inheritance for summary, multiple inheritance avoided
    as not needed

Explanation of why we are storing the parent values:

  - really, these additional categories are a denormalization. Arguably,
    the frontend should just assume that they are selected - the place
    they actually need to be selected is in the search engine;
  - however, the indexer doesn't have access to the tree at the moment,
    so moving the denormalization there is rather hard;
  - the next best place to put this might then be the API, because that
    would ensure a consistent view on the data. But that would require
    teaching the API about this as a special field, and no other fields
    get processing applied - either the data posted in is accepted, or
    not (i.e. we only have validation, nothing beyond that). And again,
    the API doesn't currently have access to the original framework data,
    so even if we wanted to have the additional categories added there,
    it's hard in the current structure.
  - that leaves us with having to do the denormalization in the frontends
    (i.e. in the content loader)
  - having the API validate that the denormalization was applied means
    duplicating that content loader logic into the API, and again we don't
    actually have the data available that would allow us to do that anyway...
  - and therefore data validly posted to the API may not have the
    denormalization applied (i.e. if someone posted to the API via some other
    method than the content loader).
  - and that's weird, but we can't do anything about it, and weird stuff
    shouldn't be silent, so here we are.

12 of 12 new or added lines in 1 file covered. (100.0%)

771 of 777 relevant lines covered (99.23%)

1.98 hits per line

Relevant lines Covered
777 RELEVANT LINES 771 COVERED LINES
1.98 HITS PER LINE
Source Files on checkbox-tree

Recent builds

Builds Branch Commit Type Ran Committer Via Coverage
252 checkbox-tree Taxonomy (category tree) implementation - simplification - https://trello.com/c/y79rP1KA/197-suppliers-choose-a-category-backend - less is more - don't need to build another tree structure - also tidy up inheritance for summary, multiple in... push galund travis-ci pending completion  
247 checkbox-tree Checkbox tree - further simplification - https://trello.com/c/y79rP1KA/197-suppliers-choose-a-category-backend - don't need to store every option's parents, gathering the expected list of parent values as we go is sufficient push galund travis-ci pending completion  
245 checkbox-tree Checkbox tree - remove unused variable - https://trello.com/c/y79rP1KA/197-suppliers-choose-a-category-backend - also tidy up inheritance for summary, multiple inheritance avoided as not needed push galund travis-ci pending completion  
243 checkbox-tree Taxonomy (category tree) implementation - https://trello.com/c/y79rP1KA/197-suppliers-choose-a-category-backend - less is more - don't need to build another tree structure push galund travis-ci pending completion  
242 checkbox-tree Taxonomy (category tree) implementation - Bump version to 3.1.0 push galund travis-ci pending completion  
241 checkbox-tree Taxonomy (category tree) implementation - test for category tree summary page push galund travis-ci pending completion  
240 checkbox-tree Checkbox tree needs to work if only 'label' is specified for an option push galund travis-ci pending completion  
191 checkbox-tree Taxonomy (category tree) implementation - support for the same value appearing in several places in the tree. push galund travis-ci pending completion  
190 checkbox-tree Taxonomy (category tree) implementation - summary value for hierarchy is a subset of the 'options' key in the YAML, this allows us to annotate with detail like labels and 'missing' flags - also update a comment in ListSummary that was in ... push galund travis-ci pending completion  
187 checkbox-tree Taxonomy (category tree) implementation - rename taxonomy to Hierarchy because it's less specific - sort the values we return, so we have we are guaranteed no diff when the same data is written back to the API, if the values are unchanged. push galund travis-ci pending completion  
See All Builds (667)