Methods related to Card Art Preference Settings, and for Card Art Smart Selection have been renamed with better wording.
Most importantly, StaticData now includes a new method to retrieve the number of art count for a given PaperCard, as well as a completely refactored and improved method for getAlternativeCardPrint.
In particular, the class now provides three different implementation of getAlternativeCardPrint, with the more sophisticated one also including normalisation wrt. the card frame, and whether or not the chosen alternative print should be gathered from an Expansion edition.
All these specialisation are part of the "Card Art Optimisation" algorithm included in Deck, and instructed by statistics gathered from Card Pool (next commit)
Now the smart card art selection is also included in the set of checkings that are performed to see whether or not card arts in Pools require any update.
Deferred sections for deck are only used once, and just when the deck needs to be loaded. At that time, if any optimisation to card art is enabled (and required, that is "there are cards with no pre-specified edition").
After that, sections are memorised and later updated if anything needs updates, and the last used card art preference was different.
CardEdition now includes a new Map data strcuture that is allocated only if necessary (i.e. when lazy card loading is enabled) and it will be used for faster card in set lookup by card name. The Map will return a List of cards to account for multiple versions (prints) of a card with the same name within a CardEdition
The new `getAlternativeCardArt` method builds on the previous `getCardFromEdition` which generates alternative card art given a PaperCard and a reference date.
Extension to this method is also incorporated to force the options to adopt for card art preference policy.
If None provided, default options set up in Game preferences will be used!
CardPool now includes the logic to (a) retrieve the edition frequency map of itself, as well as retrieving its corresponding PivotEdition (depending on cards in the pool).
This refactoring optimises the code in Deck class for "smartCardArt" selection
`getTheLatestOfAllTheOriginalEditionsOfCardsIn` is the new name for `getEarliestEditionWithAllCards` which better clarifies the intent of the method.
The implementation has been optimised, according to the new CardDb behaviour and APIs.
The tests have been extended to verify that the output of the method is always consistent regardless of the edition of cards in the input CardPool.
This method will be also re-used in Decks when inspecting the list of cards to add in a Deck Section.
This refactoring avoids code duplications, and improves modularization.
New tests (and fixed updated CardRequest implementation) verify that any method used for Card Retrieval when receiving directly CardRequest formatted strings as cardName won't have any side effect. In particular, the code is reliable to be robust enough to support passing in both card name (only) or a full cardRequest string.
If the latter, any parameter in the request will be updated - accordingly - only when explicit params in function calls are provided.
Also, new tests demonstrate that the current implementation has NO side effect when testing for multiple combinations. Therefore, whatever is requested in requestString won't be overruled, unless really requested too.
This new revision of the APi brings a more consistent distribution of the different parameters and settings in DB API calls.
In particular, the changes affect the getCardFromEditions which are now separated into three sets of methods:
- methods to retrieve a card based on CardArtPreference
- methods to also include a Release Date restriction,
that can be now considered in both directions
(as in "releasedBefore" and "releasedAfter" a specified date).
These changes will be functional for new additions in future changes to Deck Importer, as well as will be used
to refine the implementation of the new Smart Card Art Selection in Decks.
From an implementation perspective, it is important to emphasise that all those methods are just syntactic sugar
for parameter passing to the **same** core (private) retrieval method (centralised single point of failure)
which incorporates all the required parameters, that would also be cumbersome to use in a public API.
Even if UNKNOWN card load is enabled, we should check whether the card was not found because of originally filtered.
Therefore, the actual UNKNOWN card will be added now ONLY IF it is not contained in the filtered Blacklist.
