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.
The DFC doesn't actually specify which cup it means. I don't expect
anyone providing "cup" as unit to measure their produce and expect it to
calculate as a regular volume. It can just be seen as items.
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.
The new DFC Connector is based on the new DFC context which changed all
URLs of all data types.
There's also a better way to access semantic properties now.
