Replacing ListIDs with ListNames in Data View Web Parts
This is another idea that I was certain I’d posted about long ago, but I can’t seem to find. It’s especially useful if you are developing Data View Web Parts (DVWPs) in one environment and then porting them to another on any sort of frequent basis.
When you create a Data Source for a SharePoint list, you end up with some code that looks roughly like this by default (This is a code snippet from a DVWP in WSS and I’ve added spacing to make it more readable.):
<DataSources> <SharePoint:SPDataSource runat="server" DataSourceMode="List" UseInternalName="true" selectcommand="<View></View>" id="dataformwebpart1"> <SelectParameters> <asp:Parameter Name="ListID" DefaultValue="6335D0C8-3089-435F-80C4-12850D5CB7D3"/> </SelectParameters> <DeleteParameters> <asp:Parameter Name="ListID" DefaultValue="6335D0C8-3089-435F-80C4-12850D5CB7D3"/> </DeleteParameters> <UpdateParameters> <asp:Parameter Name="ListID" DefaultValue="6335D0C8-3089-435F-80C4-12850D5CB7D3"/> </UpdateParameters> <InsertParameters> <asp:Parameter Name="ListID" DefaultValue="6335D0C8-3089-435F-80C4-12850D5CB7D3"/> </InsertParameters> </SharePoint:SPDataSource> </DataSources>
Alternatively, you may see a slightly different structure in MOSS and/or if you have chosen a list in a different site (smaller snippet):
<SelectParameters> <WebPartPages:DataFormParameter Name="ListID" ParameterKey="ListID" PropertyName="ParameterValues" DefaultValue="BCD0B397-2550-4937-892A-64370C87913E" /> <WebPartPages:DataFormParameter Name="WebURL" ParameterKey="WebURL" PropertyName="ParameterValues" DefaultValue="/" /> </SelectParameters>
As you can see, in both cases the list is referred to by its GUID. This is great on one level because the reference stays intact if you rename the list. However, if you want to move your DVWP code to another environment which refers to the same list, it will throw an error because the list GUID is different.
So rather than changing the ListID each time, replace the occurrences of ListID with ListName. This lets you refer to the list by its obvious name rather than the more obscure GUID:
<DataSources> <SharePoint:SPDataSource runat="server" DataSourceMode="List" UseInternalName="true" selectcommand="<View></View>" id="dataformwebpart1"> <SelectParameters> <asp:Parameter Name="ListName" DefaultValue="My List Name"/> </SelectParameters> </SharePoint:SPDataSource> </DataSources>
or
<SelectParameters> <WebPartPages:DataFormParameter Name="ListName" ParameterKey="ListName" PropertyName="ParameterValues" DefaultValue="My Other List Name" /> <WebPartPages:DataFormParameter Name="WebURL" ParameterKey="WebURL" PropertyName="ParameterValues" DefaultValue="/" /> </SelectParameters>
This makes your DVWP code portable to other environments where there is a list in the same location with the same name, like a DEV/Staging/PROD construct.
Note that I’ve also removed the Delete, Update, and Insert sections above. If your DVWP is just displaying the contents of a list (which is probably the most common use of a DVWP), you don’t need the Delete, Update, and Insert sections.
This is a great tip, and a must knowledge-have for us DVWP-fans!
I have read in different articles to change ListId to ListName to avoid any problem in deployng DVWP to any other system. My problem is that i am using a list of another site in my DVWP. Basically the list in on root site while the page on which it is using via DVWP is on a subsite 2 levels below from root site. So i think only changing ListID to ListName will not be enough.
Can you tell me how to configure my new DVWP so that it can be deployed on other system where there will be list of same name on root site?
You haven’t tried it, have you? This will still work. The WebURL parameter is what points to the other site.
M.
Thanks, it worked
Marc,
I have tried this method but the webpart is not working when I put it on a subsite (my list also resides on the parent site). I used the WebURL but do I have put the full URL of the list in the DefaultValues or just a “/” as its not working with just “/” – can you please help. My parameters looks like these
Nadeem:
Yes, just a / ought to work, as you can see in my examples. What happens when it is “not working”?
M.
Thanks Marc – I am getting error – “unable to display webpart….” in the parent site itself where the list is but when I remove the “webUrl…” statement it works fine in the parent site just with the ListName. I am doing this in SP2010 and using both parameter statements ListName and WebURL. Basically I am creating a service catalog list in the parent site and each service will be subsite and will be populated by the information in the master list via DVWP. So with just ListName the webpart doesn’t work in sub-sites. Thanks.
One more note – instead of using WebURL i used WebID and default value as RootWeb and it worked in the parent site but again not in the subsite (getting list doesn’t exisit error).
Hi Marc – got it to work. I used the WebID and ListName properties but put the WebID statement first and the ListName as second. But also added the full URL of the list to the WebPartPages:DataFormWebPart’s ListUrl property.
Now – is there a way to add a filter to the webpart that site publishers can change based on which service they would like to use this webpart for. I added the filter to the webpart as ID=1 (the first item in services list) but can users be able to change this filter when they add/edit the webpart on a sub-site to display content from list ID 2 or any other number ?
Sorry – excitedly rushed to respond – but even with the above its not working on subsites – works on parent but not sub :( —–still looking for a solution.
nadeem:
I’m really not sure what’s going on for you. It’s definitely WebURL, not WebID. Take a look at the last example in the post.
M.
Thanks for your quick reply but its just not working – here’s my code (I took out the quotes and html)
(SelectParameters)(WebPartPages:DataFormParameter ParameterKey=WebURL PropertyName=ParameterValues DefaultValue=/ Name=WebURL)
(WebPartPages:DataFormParameter ParameterKey=ListName PropertyName=ParameterValues DefaultValue=ServicesCatalog Name=ListName)
(asp:Parameter DefaultValue=1 Name=MaximumRows)
(asp:Parameter)
(SelectParameters)
Hi Marc,
one thing ought to be mentioned..
ListName refers to the display name (The value of the SPList.Title property) of the list. So, if a user changes the name of the list, your DVWP is broken.
Happy coding!
Jack
Absolutely true, Jack. Getting the information architecture right before making this change is important.
M.
One problem I have found is that I can get the DFWP to work fine when I change the ListID values to be ListName – however if I then try to add a filter to the web part it doesn’t work. I read elsewhere that when you add a filter (eg a simple querystring filter), the DataForm webpart itself has an attribute called ListName but that attribute must be the GUID of the list.
If so then this trick of making redeployable web parts becomes a lot less useful if I can’t redploy a dataform web part that has a filter on it.
Has anyone else experienced this?
Dudley:
Think of it this way: When you start customizing ther code in a DVWP, you’re leaving the reservation. Anything you try to do through the Common Data View Dialogs may or may not work and may cause unpredictable results. You make the trade-off bewtween total freedom and using the dialogs.
As for the filters, it all depends on how you are adding them.
M.
Marc,
The list ID problem was resolved by accessing the list via a web service, however, I have a DVWP that sends data to another DVWP on another page. I cannot transport my DVWP to Prod with this problem. Is there anyway I could transport 2 DVWP’s that talk to each other?
Ali:
If you’re using a Web Part Connection, they are based on the GUIDs as well. I generally don’t use Web Part Connections because I find them to be unreliable and they do some things that no one wants (like showing all the items in the destination with no selection in the source rather than no items). I just wire up the DVWPs to work based on Query String values instead.
M.
Thanks for your quick answer Marc. How do you wire them up? The scenario you are mentioning, does that include 2 DVWPs? Would I need to deploy 2 DVWP’s. Please excuse me for asking basic questions as I always prefer writing custom web parts rather than using DVWP’s, I have been forced to use a DVWP instead :(
DVWPs are better. ;=)
If you look at this post, you’ll see how I send the values back on the Query String to the same page.
Then the second DVWP picks up that value in the ParameterBindings and you add a filter on the rowset:
M.
Thanks for patiently answering my questions :).
The blog you mentioned above is slightly different from my scenario. The item change event in my case is not a dropdown, its an item click. I am replacing a CQWP because once an item on CQWP is clicked, it takes you you to the Dispform.aspx and provides you with that item info (OOB functionality).
I replaced the CQWP with 2 DVWPs (connecting them). One is on the default page of the site and other resides elsewhere on a site. Once I click on the default page DVWP, it sends the row of data to another DVWP on another page. I realized it when I tried exporting the 2 DVWPs to the production (with no connection) and I am left bewildered now. I miss Visual Studio :(..
The same principles can make this work. Make the links in the first DVWP pass the ID you’re interested in to the second page on the Query String. Then in the second DVWP filter based on that value. You don’t need to pass the “row”, just the relevant ID.
M.
Really nice post.
Saved a lot of trouble for me…….Thanx Marc
Marc, this is an excellent tip, and the comments highlighting the limitations of the method are very useful too.
After several years using this method, have you come across other limitations? I like the tip because it makes backup/restore or import/export easy, but I can’t help telling myself: what’s the catch?
Christophe:
In all this time (and I’ve been using this trick for longer than the post would indicate) I’ve never had a problem. Renaming the list is the biggest concern, but if your information architecture is solid, that ought not to happen.
M.
Even if you rename the list, the only change needed is to replace all occurences of the former list name with the current list name. Easy peasy.