ensure WebDAVProvider.rootPath is a folder

[sdumetz]

Setting up the default WebDAV server, if you create a folder (cube in my example) with a dummy scene with it and navigate to http://localhost:8000/voyager-story-dev.html?document=/cube/scene.svx.json WITHOUT setting the root parameter, the scene kinda works but for the asset tree not matching properly.

Easiest way to show this is click Create in the Article Task. Nothing is shown until you click somewhere to deselect said article.

I traced it back to WebDAVProvider.rootPath, being normally set to /cube/ but defaults to the value of ExplorerApplication.props.document, here /cube/scene.svx.json.

I checked usage of this path and it looks like it's only used in WebDAVProvider.parseResponse

Not sure if expecting rootPath to always end with a trailing "/" is a valid option though? It doesn't seem to work otherwise anyway? if I set root=/cube the scene won't load

[gjcope]

Sounds reasonable and seems to work fine. Merged with https://github.com/Smithsonian/dpo-voyager/tree/rc-48

Seems like this could be extended to the root url as well as it is not forgiving about the trailing slash. I don't think it's an issue to expect a well formed path to a directory, but it's also nice to make it mistake-proof where possible.

[sdumetz]

Seems like this could be extended to the root url as well as it is not forgiving about the trailing slash. I don't think it's an issue to expect a well formed path to a directory, but it's also nice to make it mistake-proof where possible.

As someone who made this mistake more than once, I wholeheartedly agree. It won't break anything for me but I don't know if anyone might be relying on the current behavior?

[gjcope]

I don't think sticking a slash on the end when it's not there is too intrusive. The only scenario I can think of is if someone is doing url routing to their backend (which I know has happened) and it messes with their tokenizing or something.