-
Notifications
You must be signed in to change notification settings - Fork 3
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add deck export #16
Comments
What formats should we support? |
Ideas File formats:
API calls to other websites:
API calls to commerce websites? |
Here's a resource for some file formats: https://github.com/april/decklist/blob/master/js/decklist/decklist.js |
Oh, export to clipboard might also be good. |
MTGO, Apprentice, and OCTGN added by #26 It also gives a decent foundational base for creating the other downloads inside that special page. |
Thanks for this, @applehat! |
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 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 Looping in @valeryan and @yandere-sliver in case they have input. |
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 ***@***.***> 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
<#16 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAQBfNYt1_K4ZhUAxtZV3ph4H_k_uSs5ks5ufESGgaJpZM4QhfHE>
.
|
@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. |
Added decklist.org in 24328de. |
@NilsEnevoldsen we have been testing this on our staging environment and it looks to work well and has been performant. |
Great to hear that, @valeryan. Thank you! |
No description provided.
The text was updated successfully, but these errors were encountered: