Closed mottosso closed 9 years ago
Had some trouble understanding the concept, but if I read correctly it works like this:
test
.test
function returns False it stops processing overall, otherwise it continues.How do we know what is in the current state of operation? What data do we get from that?
Note that you made a typo. At the beginning you have orderErrors where later you have errorOrders.
but if I read correctly it works like this:
That's exactly right.
How do we know what is in the current state of operation? What data do we get from that?
The test is given vars
, which currently consists of this.
{
"order": 2, # Order of next plugin
"orderErrors": [1, 1.4] # Orders at which an error has occured
}
It is updated every time a new plug-in has finished processing. Currently, this is all the information necessary to make enough of a decision about whether to continue processing or not. As time goes, I'd imagine a few more members to be added but so far there hasn't been a need.
Note that you made a typo. At the beginning you have orderErrors where later you have errorOrders.
Thanks, fixed!
Added to 1.1
Goal
To facilitate the implementation of custom tests used in determining when to abort processing.
Motivation
There's been some talk about how one would customise the point at which publishing is aborted, such as whether to continue with Conform is Extraction has failed. This way, the logic behind whether to abort or not is fully in the hands of implementers, and something like Border Control could be implemented on your end before becoming part of the API.
Due to some refactoring work, this is a freebie and will be part of 1.1.
References
Implementation
A test is any callable that takes a dictionary of variables that defines the current state of operation.
The state is passed to the registered test and queried for once per plug-in during processing.
A test is registered like this.
The default test looks like this.