The Spree::Variant in OFN corresponds to a DFC SuppliedProduct. But
several Spree::Variant can be grouped under one Spree::Product which
wasn't exposed on the DFC API.
I'm adding a custom property here which can be used internally and
shouldn't break any other DFC tools.
A gotcha of this first test implementation:
The `ofn:` prefix has not been defined in the context. Software needs
to know that this is an Open Food Network attribute or ignore it.
We could define our own context and ontology and publish it on our
website but I don't see any benefit of that at this point.
When the application is not preloaded then running Rspec doesn't know
Rails until the spec helper is loaded. So we can't use Rails to find the
path of the spec helper. This has been fixed before but the DFC Address
code was developed at the same time and missed.
We were aiming to use stable URLs to identify resources but the URL
helpers were still using dfc-v1.7 because that was the last and
overriding path of the mounted DFC Provider engine.
Using Spring was hiding an loading error. When you start Rspec, Rails
and its engines are not loaded yet. So our way to load the spec helper
via `Rails.root` did not work when you ran specs on their own without
loading Rails with Spring first.
We still have the scale stored in two places but in our current system
that's part of a unit's "id".
If the DFC adds that value to its standard then we can use it for lookup
and don't need to repeat it.
* https://github.com/datafoodconsortium/taxonomies/issues/7
I observed new data from the DFC Prototype. It now uses the DFC 1.8
ontology with the hasQuantity object.
It now also uses PUT requests for updates because PATCH is not as well
supported. Rails doesn't care though.
I couldn't observe a request for the CatalogItem yet because the
Prototype failed to send it.
We wanted to use our own context before but now I found a better way for
the connector to cache the context and therfore we can use the original
implementation again.
This protects us from the DFC website going down or the DFC updating
the context with breaking changes. We are in control of updating the
context now (opt-in to newer versions).
The DFC Prototype does include the context while the output of the DFC
Connector refers to the URL of the published context. While that's more
efficient, it's also brittle because the context is updated from time to
time. That happened three days ago and working with the newly published
context breaks our integration until we get an updated version of the
DFC Connector containing the new URLs for datatypes.
This allows us to run the specs separately to generate the
documentation. It's more efficient this way and the separate swagger doc
file is easier to read.
The engine-specific swagger helper also allows us to simplify the spec
files.
Added an exception to our styleguide because it's intended and useful to
have a complete (lengthy) description of the API in one block.
