Custom SharePoint List View - can I put it in a feature (WSP)?

Question

Here's my situation:

I'm working in SharePoint 2007 Enterprise, I have a feature that creates a list for me when I deploy and activate it. My usual workflow thus far has been to deploy the solution, activate it, then open up SharePoint Designer to customize the list.

My customizations are typically pretty complex, but I'll keep things simple. In this case, let's just say that I edit AllItems.aspx, convert the data view to an XSLT data view, then I add one column with static text.

I've used a few different tools (SPSource, VSeWSS, SharePoint Manager, OCDExportList, etc) to extract my custom schema.xml and all the default views, but I have yet to have any luck figuring out where the the code for AllItems.aspx is now that it's been customized.

When I extract (using any of the tools above) AllItems.aspx is no different than the default. The <View> element in schema.xml is reduced to one line, for example:

<View DefaultView="TRUE" 
      MobileView="TRUE" 
      MobileDefaultView="TRUE" 
      Type="HTML" 
      FPModified="TRUE" 
      DisplayName="All Documents" 
      Url="Forms/AllItems.aspx" 
      Level="1" 
      ContentTypeID="0x" />

I'm really stuck here... I've got no clue what to do. Is it even possible? It would save me a great amount of time (and documentation) if I could include my customizations in my feature.

If there's any other info I'm missing that would help, let me know... thanks!

---

Latest findings:

I've found out a bit more in the past couple hours. If I save the list as a List Template, then save the .stp file locally as a .cab file I can extract its contents. One of the files is manifest.xml which contains the schema.xml as well as a few other sections.

One of those sections is a <webparts> section that has a <webpart> for each view. Each of those <webpart> elements contains a really long string of characters... no clue what those characters actually represent.

The important thing is that I think any custom views have to actually be Web Parts if deployed as part of a solution... but I'm not positive.

Answer 1

I have faced a similar issue a while ago. I had to create a very customized view and I had to give up the ListFormWebPart completely, and have created my own webpart to render the data.

Generally, when you customize the aspx file in SPDesigner, all your changes will be in the aspx file itself. Open it in SPDesigner and you will see there all the changes you have made. After you have converted to the XSL Data View, the standard ListFormWebPart is replaced by a DataFormWebPart, which doesn't care about the <View> tags specified in the schema.xml; Look in the aspx file itself for the ListFormWebPart.

Why not do all the customizations you want on a list, save the list as a template (it will include the associated AllItems.aspx) and then use that template in your feature to create your list? You could add the extracolumn from code (if it's dynamic and cannot be included in the template), and so on.

Answer 2

I have a similar issue and have been doing a lot of research into this. The dataview web part to me is one of the most powerful components in Sharepoint. Unfortunately I have to provide my solution as a .wsp package and that means that I can not just make the site and use Designer on that site. I have taken a 2 step approach in that I used designer to create my dataview and I also edited the code of that dataview to replace the ListID and Guids to ListName and the actual list name. This allows it to be exported and used in any page/site as long as the list name is the same. I am creating a webpart page document library also in my solution and I believe I can add the pages that have the webparts to this library using the onet.xml file. I will try to get the results of that test in as soon as I can do it.

Answer 3

Yes you can. Get the Sharepoint manager tool from Codeplex http://spm.codeplex.com/

Install it on a machine in your farm, it will allow you to browse the farm via a tree view that shows all objects.

Make the list via the Sharepoint GUI, then browse to it w/ SPM.

SPM will allow you to extract the MOSS/WSS created xml that describes the list view (it shows up in the left hand property grid), which you can then plop into your manifest.xml