search

NilsEnevoldsen / ScryfallLinks

MediaWiki extension that creates Scryfall links from Magic: The Gathering card names
MIT License
7 stars 3 forks source link

Add deck export #16

Open NilsEnevoldsen opened 7 years ago

NilsEnevoldsen commented 7 years ago

What formats should we support?

NilsEnevoldsen commented 7 years ago

Ideas

File formats:

API calls to other websites:

API calls to commerce websites?

NilsEnevoldsen commented 6 years ago

Here's a resource for some file formats: https://github.com/april/decklist/blob/master/js/decklist/decklist.js

NilsEnevoldsen commented 6 years ago

Oh, export to clipboard might also be good.

applehat commented 6 years ago

MTGO, Apprentice, and OCTGN added by https://github.com/NilsEnevoldsen/ScryfallLinks/pull/26

It also gives a decent foundational base for creating the other downloads inside that special page.

NilsEnevoldsen commented 6 years ago

Thanks for this, @applehat!

NilsEnevoldsen commented 6 years ago

I've done a first pass at a deck exporter. Right now it exports to text, MTGO, Apprentice, and OCTGN.

I decided to do this with javascript instead of with a SpecialPage.

The javascript will only load on pages with decks, and it will be cached by ResourceLoader. It weighs about 1KB compressed, so it's much lighter than the base64 encoded file links I used before.

@applehat noted that "SpecialPage downloads… allow friends to send each other links to download decks without having to visit a wiki page, where javascript / base64 method requires them load the page, find the link, and click it". This is true, but I think this behavior is probably extremely rare.

I also wanted to avoid SpecialPages because they are a bit arcane. Keeping the plumbing as javascript makes hacking more accessible and less dependent on MediaWiki knowledge.

Additionally, the current SpecialPages seem brittle. I frequently get no deck errors.

I put in a placeholder SpecialPage that explains the deprecation for users in case users end up on that page.

I am sure there are some bugs with my first attempt, so kicking the tires is appreciated.

I should also consider whether to do card name validation/normalization prior to exporting. That would be a lot more work. Not sure if it's worth it.

Big question for anybody listening out there: I'm not a js whiz, and I welcome advice on the cleanest way to organize this code. Right now here's what happens when an export link is clicked. The deck from the webpage is vacuumed up just as it is, as an XML object. Then a function parses the XML deck into a JSON object: a Deck, which contains DeckSections, which contains DeckEntrys (i.e. cards). The print() function of a Deck object recursively calls the print() function on each DeckSection, which recursively calls the print() function on each DeckEntry. The print() functions all take a format parameter (such as mtgo). Alternatively, I could hook each format up as its own print() function, such as printMTGO(). Or maybe these functions shouldn't be part of the Deck prototype at all, and turning a Deck into a formatted file/string should work in an entirely different way. What's best?

Looping in @valeryan and @yandere-sliver in case they have input.

applehat commented 6 years ago

An API endpoint would make more sense then the special page, if I was to do this again.

Pulling from the API for the file download would also be easy

On Wed, Sep 26, 2018, 10:22 PM Nils Enevoldsen notifications@github.com wrote:

I've done a first pass at a deck exporter. Right now it exports to text, MTGO, Apprentice, and OCTGN.

I decided to do this with javascript instead of with a SpecialPage.

The javascript will only load on pages with decks, and it will be cached by ResourceLoader. It weighs about 1KB compressed, so it's much lighter than the base64 encoded file links I used before.

@applehat https://github.com/applehat noted that "SpecialPage downloads… allow friends to send each other links to download decks without having to visit a wiki page, where javascript / base64 method requires them load the page, find the link, and click it". This is true, but I think this behavior is probably extremely rare.

I also wanted to avoid SpecialPages because they are a bit arcane. Keeping the plumbing as javascript makes hacking more accessible and less dependent on MediaWiki knowledge.

Additionally, the current SpecialPages seem brittle. I frequently get no deck errors.

I put in a placeholder SpecialPage that explains the deprecation for users in case users end up on that page.

I am sure there are some bugs with my first attempt, so kicking the tires is appreciated.

I should also consider whether to do card name validation/normalization prior to exporting. That would be a lot more work. Not sure if it's worth it.

Big question for anybody listening out there: I'm not a js whiz, and I welcome advice on the cleanest way to organize this code. Right now here's what happens when an export link is clicked. The deck from the webpage is vacuumed up just as it is, as an XML object. Then a function parses the XML deck into a JSON object: a Deck, which contains DeckSections, which contains DeckEntrys (i.e. cards). The print() function of a Deck object recursively calls the print() function on each DeckSection, which recursively calls the print() function on each DeckEntry. The print() functions all take a format parameter (such as mtgo). Alternatively, I could hook each format up as its own print() function, such as printMTGO(). Or maybe these functions shouldn't be part of the Deck prototype at all, and turning a Deck into a formatted file/string should work in an entirely different way. What's best?

Looping in @valeryan https://github.com/valeryan and @yandere-sliver https://github.com/yandere-sliver in case they have input.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/NilsEnevoldsen/ScryfallLinks/issues/16#issuecomment-424946100, or mute the thread https://github.com/notifications/unsubscribe-auth/AAQBfNYt1_K4ZhUAxtZV3ph4H_k_uSs5ks5ufESGgaJpZM4QhfHE .

valeryan commented 6 years ago

@NilsEnevoldsen I will load this on my dev system and do some testing with it and see if I have anything I can contribute. Thanks.

NilsEnevoldsen commented 6 years ago

Added decklist.org in 24328de.

valeryan commented 6 years ago

@NilsEnevoldsen we have been testing this on our staging environment and it looks to work well and has been performant.

NilsEnevoldsen commented 6 years ago

Great to hear that, @valeryan. Thank you!