Adds README entry for failedToLoad (if storeUriFailed)
@@ -186,6 +186,7 @@ $ngRedux.getState();
isLoadingAgreementData: true|false, //default is false, whether or not the agreementData has been loaded,
isLoadingPetriNetData: true|false, //default is false, whether or not the petriNetData has been loaded,
isLoading: true|false, //default is false, whether or not this connection is currently loading itself (similar to the isLoading in the need)
+ failedToLoad: true|false, //default is false, whether or not this connection was able to be loaded or not
showAgreementData: true|false // default is false, whether or not the agreementDataPanel is active
showPetriNetData: true|false // defautl is false, whether or not the petriNetDataPanel is active
multiSelectType: String // default is undefined, indicates which action is supposed to happen for the multiselect messages
@@ -204,6 +205,7 @@ $ngRedux.getState();
isOwned: true|false, //whether this need is owned or not
isBeingCreated: true|false, //whether or not the creation of this need was successfully completed yet
isLoading: true|false, //whether or not the need is currently in the process of being loaded
+ failedToLoad: true|false, //whether or not the need has failed to load (due to delete or other)
toLoad: true|false, //whether or not the need is flagged as toLoad (for future loading purposes)
flags: Immutable.List //all the flags that are present within the won:hasFlags predicate of a need
facets: Immutable.Map //all the facets that are present within the won:hasFacets predicate of a need
@@ -273,11 +275,11 @@ There are also abstractDetails, which are not considered complete Details but pr
To adjust details for individual use cases, the data parsing functions should be overwritten in `usecase-definitions.js`. For parsing, **all details defined in any use case** will be considered. To avoid unexpected behaviour, `detail.identifier` must be unique across all use cases and must not be "search", as this literal is used to recognise full-text searches. Additonally, if two or more use cases use the same `parseToRDF({value, identifier})` function or use the same RDF predicates, information may not be correctly recognised. E.g., if one use case parses a "description" to be saved as `dc:description`, and another use case parses a "biography" to also be saved as `dc:description`, "description" and "biography" can't be told apart while parsing. As a result, which `parseFromRDF(sonLDImm)` is used for parsing the information depends on the order of use case definitions.
-Details are represented in the state as part of `is` and `seeks`, for example:
+Details are represented in the state as part of the need or a branch `seeks`, for example:
```javascript
/*
-is : {
+seeks : {
title: string, //title of the need
description: string, //description of the need as a string (non mandatory, empty if not present)
tags: Array of strings, //array of strings (non mandatory, empty if not present)
