Loading tweets...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.
40 comments
1 ping
Skip to comment form ↓
Christian Ståhl
August 28, 2009 at 8:40 am (UTC -4) Link to this comment
This is a great tip, and a must knowledge-have for us DVWP-fans!
mohsin
December 26, 2009 at 2:19 am (UTC -4) Link to this comment
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?
Marc
December 26, 2009 at 9:14 am (UTC -4) Link to this comment
You haven’t tried it, have you? This will still work. The WebURL parameter is what points to the other site.
M.
mohsin
December 27, 2009 at 11:45 pm (UTC -4) Link to this comment
Thanks, it worked
Jack Lauret
March 19, 2010 at 11:31 am (UTC -4) Link to this comment
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
Marc
March 19, 2010 at 11:33 am (UTC -4) Link to this comment
Absolutely true, Jack. Getting the information architecture right before making this change is important.
M.
Dudley Adshead
March 25, 2010 at 6:45 am (UTC -4) Link to this comment
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?
Marc
March 25, 2010 at 8:27 am (UTC -4) Link to this comment
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.
Ali
April 15, 2010 at 11:08 am (UTC -4) Link to this comment
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?
Marc
April 15, 2010 at 11:14 am (UTC -4) Link to this comment
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.
Ali
April 15, 2010 at 11:40 am (UTC -4) Link to this comment
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 :(
Marc
April 15, 2010 at 2:11 pm (UTC -4) Link to this comment
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.
Ali
April 15, 2010 at 8:12 pm (UTC -4) Link to this comment
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 :(..
Marc
April 15, 2010 at 8:16 pm (UTC -4) Link to this comment
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.
Amit Tyagi
June 1, 2010 at 7:12 am (UTC -4) Link to this comment
Really nice post.
Saved a lot of trouble for me…….Thanx Marc
Christophe
November 6, 2010 at 8:15 am (UTC -4) Link to this comment
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?
Marc
November 6, 2010 at 11:56 am (UTC -4) Link to this comment
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.
Alex
December 10, 2010 at 11:14 am (UTC -4) Link to this comment
Hi,
I ran into a scenario which I have more than 200 pages (with DVWP) where the GUIDs need to be updated or changed to the ListName. Do I need to update them page by page? Is there a tool other than can SPD to speed thing up?
Your advice is greatly appreciated,
Alex
Marc
December 10, 2010 at 2:53 pm (UTC -4) Link to this comment
Alex:
If you’ve already go all 200 of these pages set up and working, do you really need to change to ListNames? In any case, I haven’t ever needed to do such a large set of changes. I almost always switch to the ListName as I’m building the DVWPs. I’d think that you might be able to script it somehow, but it may take just as much time getting someone to figure that out as it would to just do it manually.
M.
1 2 3 Next »
Using a DataSource in a Data View Web Part (DVWP) in a Different Site in SharePoint Designer 2010 « Marc D Anderson's Blog
November 2, 2010 at 10:30 am (UTC -4) Link to this comment
[...] Site Collection which resides in a subsite called ‘Marc’. Note that I’ve also switched from ListID to ListName in this example. As long as your information architecture is solid, that switch can be useful to [...]