improved getURL method - Githubissues

esgibter / fandomstats

Fandom Statistics

12 stars 2 forks source link

improved getURL method #13

Closed esgibter closed 10 years ago

esgibter commented 10 years ago

For issue https://github.com/esgibter/fandomstats/issues/6, https://github.com/esgibter/fandomstats/issues/7, https://github.com/esgibter/fandomstats/issues/9, this change:

Creates class AO3url, which is a tool that takes in search parameters as an object and spits out a properly-formed AO3 search URL. The getUrl() method can take in any complexity of parameters available (or, at least, whatever complexity I covered in the tests I wrote, which I think is the majority of cases)
Adds tests for AO3url, which tests for a simple, medium complexity, and high complexity search parameters

The class and method aren't consumed yet - I'm going to do that in my next pull request. That will also include how we store the params object and pass to the backend, which I'm still trying to figure out.

esgibter commented 10 years ago

@annathecrow I've updated this with your blueprint update. One change I want your opinion on: do you know the standard directory structure / namespacing for multiple models in blueprint/flask? In your change you made a generic models.py, and here I've broken tasks into two models files - url_models.py and scraper_models.py.

This doesn't seem like the most elegant solution - I'm currently hunting around for how we could have a /models folder, which all of the models could go in, but I can't get my imports working correctly for that - I'll keep poking at it, but let me know if you've got any pointers.

esgibter commented 10 years ago

Okay, I'm taking back a bit what I said in my previous comment - I'm now putting everything in one models.py and seeing how that goes. In my next pull request it might be more obvious that we're stuffing too much into one file... but we shall see.

annathecrow commented 10 years ago

hmm, so far I've only seen a single models.py per blueprint. I suppose the general idea is that each blueprint works with a single data model, which should be manageable in single file. I'll look around, though.

esgibter commented 10 years ago

yeah, that's what I saw too, which is why I moved it back to one models.py. We can keep it in one for now until it feels untenable and then go from there.