Support for "../" in a URL w/ prependURLs

[ggritmon 0 Likes (Newbie)]

When nesting loaders in an XMLLoader, I can use prependURLs to modify the location in which the assets are loaded. Unfortunately, if "../" was part of the URL path, the result is an invalid path.

 

// example: inside data/assets.xml

<SoundLoader url="../shared/sound1.mp3">

 

w/ prependURLs "http://foo.com/game/", this becomes:

"http://foo.com/game/../shared/sound1.mp3"

 

when it should be:

"http://foo.com/shared/sound1.mp3"

 

 

I was able to resolve this issue with an update to the LoaderMax.prependURLs method:

 

public function prependURLs(prependText:String, includeNested:Boolean=false):void {
 var loaders:Array = getChildren(includeNested, true);
 var i:int = loaders.length;
 while (--i > -1) {
  LoaderItem(loaders[i]).url = validatePath(prependText + LoaderItem(loaders[i]).url);
 }
}
protected function validatePath(path:String):String
{
 var i:int, j:int;
 do
 {
  i = path.indexOf("../");
  if (i > -1) {
j = path.lastIndexOf("/", i - 2);
if (j > -1) path = path.substr(0, j + 1) + path.substr(i + 3);
  }
 }while (i > -1 && j > -1)
 return path;
}

[GreenSock 18,251 Likes (Superhero)]

So your goal is to have LoaderMax automatically strip out any references to "../" in the URL? I'm just a bit concerned that it could be unintuitive for [rare] cases when people actually rely on that, like let's say they build all their URLs as relative to a specific folder, but then later want to change that by prepending "../../" to it. If I implement your suggestion, it would break the URLs. See what I mean?

[ggritmon 0 Likes (Newbie)]

All this change does is apply relative paths when they are prepended with absolute paths. They wouldn't be removed, they would be applied (for each "../", the folder before it is stripped out). If your XML contains relative paths, then reason would stand that they are relative to the asset loading the XML, and should still apply even if some absolute location has been specified.

 

Do you disagree?

 

Otherwise, this means the locations of assets in one place differs from the other (assets which used to be relatively outside this folder location are now within it?)

[GreenSock 18,251 Likes (Superhero)]

It sounds like maybe where we misunderstood each other is you were wanting to add a new feature that seemed intuitive (and quite useful) to you whereas I thought you were saying the current behavior is flawed and your new proposed behavior should be the default for prependURLs(). I totally see why you'd appreciate that new behavior, but I don't think it's appropriate for prependURLs() because it could be misleading. Prepend means...well...basically to add to the beginning. That's it. It doesn't mean strip out some of the existing URL and replace parts of what I'm prepending, etc.

 

I think you were presupposing that every developer would be reasoning the same way you were and that they'd structure things the same way, but I don't think it would be good to impose that on everyone. Some people may load XML from a completely different place. What if they tried prepending "../../"? See what I mean? I just try to be very careful about presupposing too many things or imposing a particular workflow on users. But again, I like your solution and I think it makes a lot of sense in common workflows, so please do feel free to keep your custom code in place for your projects. I just think that for the main release, prepend should always prepend rather than conditionally stripping out portions on each side of the URL.

[ggritmon 0 Likes (Newbie)]

If you prepend "../../", it would do just that, and subloaded assets would load from 2 levels above. The "../" replacement is conditional. Essentially, if "../" is found anywhere in a URL after another directory, it is removed along with the preceding directory. How the "../" got there is irrelevant. it's just another level of validation to the URL.

 

The example I listed above would work in both cases.

[ggritmon 0 Likes (Newbie)]

I agree that putting it in PrependURLs may not be the appropriate place. The location where the final URL is assembled and attempts to be loaded is really where it should go, as part of the 'assembly' process.