Selected lookup value used for different lookup column

Feb 13, 2012 at 1:26 PM

Hello marc, 

we got 3 lookup columns: 
Lookup column A: uses SPComplexToSimpleDropdown
Lookup column B: uses SPComplexToSimpleDropdown and SPCascadeDropdown to Column A
Lookup column C: uses SPComplexToSimpleDropdown and SPFilteredDropdown

In our scenario column B has an item selected with id 94, column C has no value selected. However, when we save the item, column C comes up with a selected value aswell. Both columns use different lookup lists, but they both contain an item with id 94. So when we've saved the item, both column B and C have item id 94 selected, although we only set the value for column B. To me it looks like a variable is being used for both columns if both Ids match.

We're using Alpha13 at the moment, since we didn't have the chance to test beta2 yet. 

SPCascadeDropdown text: <script language="javascript" type="text/javascript">$(document).ready(function() {$().SPServices.SPCascadeDropdowns({relationshipList: "Unterkategorien", relationshipListParentColumn: "u4sKategorie", relationshipListChildColumn: "Title", parentColumn: "Kategorie", childColumn: "Unterkategorie", listName: "Interne Spezifikationen", matchOnId: "True", debug: "false", noneText: "(Ohne)"}); });</script>

SPComplexToSimpleDropdown text: <script type="text/javascript">$().SPServices.SPComplexToSimpleDropdown({columnName: "Kategorie"});$().SPServices.SPComplexToSimpleDropdown({columnName: "Unterkategorie"});$().SPServices.SPComplexToSimpleDropdown({columnName: "Prozessreferenz"});</script>

SPFilteredDropdown text: <script type="text/javascript">ExecuteOrDelayUntilScriptLoaded(getRelativeUrl, "sp.js");var relativeUrl;function getRelativeUrl(){var ctx = new SP.ClientContext.get_current();this.site = ctx.get_site();ctx.load(this.site);ctx.executeQueryAsync(Function.createDelegate(this, this.onSuccess), Function.createDelegate(this, this.onFail));}function onSuccess(sender, args) {relativeUrl = this.site.get_serverRelativeUrl();filterDropDown();}function onFail(sender, args) {alert('failed to get site. Error:' + args.get_message());}function filterDropDown(){$().SPServices.SPFilterDropdown({ relationshipList: "{B0EB08D8-7F1F-4969-AC3E-AAA876D55FE7}", relationshipListColumn: "Title", columnName: "Prozessreferenz", listName: "Interne Spezifikationen", noneText: "(Ohne)", CAMLQuery: "<Neq><FieldRef Name='ContentType'/><Value Type='Text'>Verbinder</Value></Neq>", debug: false }); }</script>

Coordinator
Feb 13, 2012 at 1:39 PM

Andreas:

If you're not using SPCascadeDropdowns on column C, then it shouldn't be set by anything but the user.

Note that for the column A->B relationship, you can just set the simpleChild option to true and column B will be converted to a simple dropdown.

M.

Feb 13, 2012 at 1:49 PM

Hey, 

thanks for the fast reply. We're not using the SPCascadeDropdowns on column C, however the value is set after hitting the default SharePoint save button.

How can I double check our settings? Could beta2 behave any different compared to alpha13 in this regard? Is it possible that one local variable will not be reset and the value for the selected id is handed over to a different column?

 SPComplexToSimpleDropdown for column B is executed before  SPComplexToSimpleDropdown for column C.

Coordinator
Feb 13, 2012 at 4:40 PM

Andreas:

The differences between ALPHA13 and BETA2 are minimal, but there are some, of course. I'm going to be releasing v0.7.1 today, hopefully.

M.

Coordinator
Feb 14, 2012 at 1:43 PM

One other thought: It looks like you have multiple script blocks. Have you tried wrapping them all together in a $(document).ready() to ensure that they run in the sequence you expect? It may make debugging this easier.

M.

Feb 21, 2012 at 3:42 PM

Hello Marc, 

I done some more digging .. and I think I found the root of all evil ;-). It comes down to all our ComplexToSimpleDropdowns having the same ID, which is caused by this function not returning the listname inside our customforms.

So there are several questions on my side:

- can we do anything to make the function work inside our custom forms?

- can we modify the genContainerId function to return some other id instead?

Thanks

Feb 22, 2012 at 7:21 AM

Two additional notes: We're working with 0.7.1a and we've put all script blocks together like you suggested.

Feb 27, 2012 at 8:55 AM

Hello Marc, 

any suggestions on this problem?

Feb 27, 2012 at 6:40 PM
Edited Feb 27, 2012 at 6:40 PM

Looking at the source of SPListNameFromUrl, it needs the form to end with ".aspx", then it just removes everything after the last slash, and then it loops through all the lists looking for one whose default view url folder (stuff before last slash) matches that.

So I think this won't work if your custom forms don't end with .aspx, or don't live directly in the list root folder -- or, I suppose, if the list has a strange default view url which isn't in the list root folder.

Feb 28, 2012 at 9:06 AM

Hey, 

thanks for your analysis. You've narrowed it down perfectly. Our custom forms end with .aspx, but they are not located in the forms folder of the specific list. We're using our aspx on various lists so we've put them into a seperat folder, which means that you can't make any assumptions from the url of the aspx file. 

I've edited the ComplexToSimpleDropdown code for us, which is anything but ideal, but I really don't see the big benefit of using the SPListNameFromUrl method to create a unique id for the dropdown control. I'm using the display column name to create an id which is available inside the method. This wouldn't work if somebody would have several lookup columns with the same display name on the same list, where the script is used. This seems to be a rare case in my opinion.

Anyway wouldn't it be the better approach to check the DefaultEditFormUrl of all lists for the aspx file? This way you wouldn't be forced to place the aspx files inside the forms folder of the list. You would be free to put them down where ever you want to and you would still be able to find the list.

Coordinator
Mar 12, 2012 at 2:15 AM

Andreas:

I haven't found a more reliable way to get at the default forms. Do you have a suggestion?

I'm not using the listname to create the ID, but I do call the SPGetStaticFromDisplay function by calling SPListNameFromUrl to get the current listname. Note that if SPListNameFromUrl already "knows" the listname, it doesn't do any Web Services calls, but passes back the known value.

M.

Mar 12, 2012 at 8:18 AM

There is a property called SPList.DefaultEditFormUrl which could come in handy, although I'm not sure it would work in all scenarios. In my opinion the following function call it not necessary for the method SPComplexToSimpleDropwdown:

// Build up the simple dropdown, giving it an easy to select id
var simpleSelectId = genContainerId("SPComplexToSimpleDropdown", opt.columnName);

What you're trying to achieve is preventing a scenario, where 2 lookup columns with the same Displayname but different Staticnames would end up getting the same id and therefor end up messing up the selected values (when SPComplexToSimpleDropdown has been applied to both of them). In my opinion this shouldn't be the case in 99% of all SharePoint environments.

SPComplexToSimpleDropdown is not given a listName parameter and therefor when the function genContainerId is called the following code tries to get the listName but fails in my environment:

// Generate a unique id for a containing div using the function name and the column display name
function genContainerId(funcname, columnName) {
	return funcname + "_" + $().SPServices.SPGetStaticFromDisplay({
		listName: $().SPServices.SPListNameFromUrl(),
		columnDisplayName: columnName
	});
} // End of function genContainerId
Using genContainerId inside SPComplexToSimpleDropdown seems to be overkill in the first place (in my opinion). Else you should be able to pass the listName to the SPComplexToSimpleDropdown call so it can be used inside the given code without calling $().SPServices.SPListNameFromUrl().

Coordinator
Mar 19, 2012 at 3:25 PM

Looking through what I'm doing in SPComplexToSimpleDropdown, I see your point. What I was trying to do was give the simple dropdown a reliable id that was also consistent with the ids I'm crreating in other functions. This allows developers who use the function to easily hook into the new dropdown and bind to its events, if needed.

What about the options we're discussing in this other thread? http://spservices.codeplex.com/discussions/348892 If you could pass in the listName, then would that solve your issue?

M.

Mar 19, 2012 at 3:36 PM

Hello Marc, 

I don't think the suggestions from the other thread would help us right now, however we're working on an other solution on our side. We're trying to get rid of our "very-special-custom forms" and move towards a small webpart which will be placed onto the regular editform.aspx or displayform.aspx aso. 

Development wise this seems to be the way we have to go. We would be able to use $().SPServices.SPListNameFromUrl() and many other features like the default ribbon bar which is not available right now. You can put this discussion on hold until we come back with news.

However, if you could hand over the listname to getContainerId and SPComplexToSimpleDropdown all our problems would be solved.

Coordinator
Mar 19, 2012 at 3:43 PM

Well, the ribbon issue will be there regardless, right? In the short term, why don't you clone SPComplexToSimpleDropdown and just create your own id?

M.

Mar 19, 2012 at 4:05 PM

I've replaced the getContainerId function call inside SPComplexToSimpleDropdown with our own code, which helped us to get everything working as expected. Thanks for your support!