I will have to defer your question to Marc Anderson, the author of the SPServices library, who can more adeptly answer questions about special circumstances when using his library. (Heck, I couldn’t have done it without his indepth help!)

http://spservices.codeplex.com/discussions

Blessings,
Jim Bob

Now onto the question at hand…
I have a top dropdown (the one which is cascading the value) which I want to control multiple dropdowns below, rather than just one. Also, the lists in each of the following dropdowns are the same to allow the user to select, so there will not be a country -> state -> city type association. Just a simple country -> state, country -> state, etc association. I know I can allow for multiple selections, but for each selection I have another associated field which collects some information regarding the “state” selection. How can I get the top dropdown to affect the dropdowns below it?

Thanks!

Thanks again.
Hector

There’s a performance penalty for using this logic, but it almost guarantees that you will have good data in your list. For that reason, I see the performance hit as acceptable. Keep in mind that the more related cascades you have and the higher up the chain you make a change, the more Web Services calls SPServices will make.

M.

Jim Bob passed your question over to me. (I answer questions about SPServices as quickly as I can if you post them on http://spservices.codeplex.com, too.)

You’ve guessed right that SPServices is doing Web Services calls to get the info from the related lists. That’s the only way it can work

M.

I look forward to hearing how it works out. If you get stumped, don’t forget to jump over to Stump the Panel (http://www.EndUserSharePoint.com/STP) and let’s talk it out.

Blessings,
Jim Bob

Yes this helps > Will need to experiment .. the auto polpulate will feed off from a sharepoint list that has
X columns that has been extracted from SAP / XRPM. So this classification would be both for
the Project side/ Production support and the Production Acceptance docs. They are looking to be able
to search by the above metadata properties.. And yes we will be using content type for the different project documents. Thanks again for quick repsonses!!!

Of course, you can autopopulate just about anything as long as it makes sense.

For example, for Full-Time Employee example I’m using in this series, I autopopulate a few things on insert based on where the user is coming from. Because I want the respective manager for each location to only update their own employees, I created individualized pages for each location. (The managers have access to all of them, which allows them to easily transfer employees among locations.)

Each page filters on its location, so on insert, I autopopulate the location w/ jQuery. Also, there are a couple of different “types” of employees that are grouped separately for reporting purposes: FTE (full-time employees), PRN, Other (PT, Temp, Float, etc.) On each page, I separate these out further into their own DVWPs and then stack them with Christophe Humbert’s EasyTabs. So again, depending on which tab they’re on, I autopopulate for that tab.

So, I could see in your case that you’ll be working within a Project (so that can be autopopulated) on a particular WBS, Line of business, PM, etc. section so you can autopopulate those, too. Additionally, if you’re using content types for the Doc Lib, you can default metadata for that CT…

Does that help?

Blessings,
Jim Bob