SPListNameFromUrl throws execption when used for a file stored in root folder

Nov 28, 2013 at 1:43 PM
Edited Nov 28, 2013 at 1:44 PM
Hey marc,
we're using your Autocomplete function on a website which has been placed inside the root folder of our sitecollection. Inside this function gencontainerId() uses $.fn.SPServices.SPListNameFromUrl which then tries to access currentContext.thisList.length which throws an exception if the file is located inside the rootFolder.

My suggestion would be to change the following lines of code:
else if(currentContext.thisList.length > 0) {
    return currentContext.thisList;
}
---- into ----
else if(SPServicesContext.thisList !== undefined && SPServicesContext.thisList.length > 0) {
    return SPServicesContext.thisList;
}

With this change SPListNameFromUrl returns nothing (which is correct in this case) and nothing changes for the regular case (as far as I can tell).

Regards, Andreas
Dec 6, 2013 at 9:58 AM
Hey, did you have by chance the time to look into this issue?
Coordinator
Dec 6, 2013 at 3:37 PM
No, sorry, I haven't. I do know there's a bug in 2013.01 with calls from the root Web. Have you tried passing in
webURL: "/"
? That's a workaround until I can release 2013.02 (or 2014.01 if I don't get moving!)

M.
Dec 12, 2013 at 12:58 PM
Hey Marc,

the workaround is working so I guess 2013.02 or 2014.01 will do the job aswell. Anyway, I don't think my suggestion would hurt the stability or the code, but who am I to judge if there's an other side effect when making the change.

Thanks again
Dec 12, 2013 at 3:42 PM
Update:

After refreshing the browser cache it stopped working with webURL:"/" so there might be more to it.
Coordinator
Dec 12, 2013 at 4:43 PM
Can you try the latest alpha? It's got the fix I think will do the trick for everyone with these issues:
https://spservices.codeplex.com/releases/view/104652

M.
Dec 13, 2013 at 8:52 AM
Hey,

it seems that the lastest alpha doesn't work in our case.

For me it looks like the reason behind are the following methods being called:
  1. genContainerId("SPAutocomplete", opt.columnName); (just handing over the columnName)
  2. listName: $().SPServices.SPListNameFromUrl() (determin listName from Url, which means trouble ahead, because there is no list)
  3. since no additional parameters are handed to SPListNameFromUrl it will always try to check "} else if(currentContext.thisList.length > 0) {" in which case currentContext.thisList will be null so accessing .length has to fail.
Maybe I missed some options which could be handed over, but as I see it now, even with webUrl: "/" it will fail every time the script is placed on a site located in the rootFolder of a web.
Coordinator
Dec 13, 2013 at 2:35 PM
OK, so let me rephrase the issue so I'm sure I've got it.

You're using SPAutocomplete in a list form for a list in the root Web, i.e., "/". The function is failing in the call to genContainerId("SPAutocomplete", opt.columnName).

Can you please post your call to SPAutocomplete?

M.
Dec 16, 2013 at 1:16 PM
Not excatly! We don't use the autocompletion function on a list form, rather on a custom webpart we've placed on the welcomepage of our root web. So the the issue might be the assumption that the autocompletefunction is used only on list forms.
<script type="text/javascript">
$(document).ready(function() {
$().SPServices.SPAutocomplete({
sourceList: "Projects",
sourceColumn: "Title1",
columnName: "tb_ProjectTitle",
numChars: 3,
ignoreCase: true,
WebURL: "/",
debug: false,
filterType: "Contains"});
});
</script>
Coordinator
Dec 16, 2013 at 4:30 PM
That explains it. I never set up SPAutocomplete to work outside a list context.

After I built the function originally, I realized that jQueryUI's autocomplete function was far superior and didn't do much else with it. I'd suggest using that with SPServices providing the data.

M.