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.
The new "Smart Card Art Selection" option for card images in deck has been added.
The Ui and forge preferences have been updated (default is False), as well as corresponding support in StaticData.
On this note, the old `getAlternativeCardPrint` has been re-implemented to enforce a "Latest_Art" based preference selection so that editions could be selected accordingly (as the smart method was originally designed)
Actual implementation of the method will be part of future commits as still under dev - and requires better encapsulation
The getImagefile will be invoked since this method will also account for any difference in `full` and `fullborder` naming for card images.
In particular, it will try everything possible before giving up and assume the card has no image.
This is **crucial** for cardDB card retrieval, as well as determines the boolean value returned by PaperCard.hasImage method/property
CardDb now includes a more refined mechanism to set up values for CardArt Preference.
These methods do now support the proper setup for legacy values and string values (as supported previously in mobile version).
Moreover, new methods are now defined to support the new (separated) pair of settings as integrated into the Desktop App.
