Updated _parsePath to handle query strings better. - #1
Conversation
| var name = ''; | ||
| var ext = ''; | ||
| var origExt = ''; | ||
| if (s.SUPPORTED_EXTENSIONS.indexOf(match[5]) >= 0) { |
There was a problem hiding this comment.
Just to stay consistent with the code style convention, brackets should be on the next line.
There was a problem hiding this comment.
It seems that the code in this file keeps the brackets in the same line, the original line 1203 being an exception. I'm happy to change it, but I just want to make certain since dropping it down will be inconsistent with the rest of this file.
There was a problem hiding this comment.
Actually, my bad, you are correct. Springroll follows that convention but this is the CreateJS fork. So disregard.
|
I don't see any issues at first glance. Could you also include the built library please? Also, could you please tell me of your method that you used to test the different cases? Did you use a unit test? If so, could you please provide it? |
|
Yes, I created a basic unit test: I wasn't aware whether SoundJS is set up with a unit testing framework, so I performed it in the console: |
|
Looks awesome to me. |
|
Awesome thanks! Yep, looks good! |
Per this discussion, I've updated the SoundJS
_parsePathmethod to handle query string variations better.In most cases, the new regex can find the extension for a sound file whether it's a direct link or part of a query string.
Below I've listed a wide assortment of urls the updated method can handle, including the three properties it outputs.
Two fail: one has no audio file type specified, and the other fails since the method is only checking the first valid parameter of the query string for a file type. It's checking against the first parameter's "1.1.1", but I'm not certain of a concise and foolproof way to fix the general case for an indeterminate set of parameters.
Let me know what you think!