I want to summarize a few steps you need to take to deploy custom list forms (like NewForm.aspx) and view forms (like AllItems.aspx). Not because these things are undocumented, they are, but because I couldn’t find a good article which sums it all up in a neat way. So I’ll give that a shot myself

This post will handle the following kind of problems:
- Adding your own CSS or JavaScript to the NewForm.aspx page to add functionality;
- Adding your own CSS or JavaScript to the AllItems.aspx page to customize your list view;
- Replacing the default ListView webpart which is used in NewForm.aspx

First off, we’re talking about a custom list in a custom list definition which is being made in Visual Studio and deployed via a solution. You can make the same changes through SharePoint Designer, but then they’re obviously confined to a single site. I’m also supposing you’ve already got the list definition setup in a solution in Visual Studio.

First, it’s important to understand how the ghosting system works. A SharePoint ghosted file is a file which appears in a library, but isn’t actually there. The ghosted files are stored on disk instead of in the content database. All of the list forms are ghosted and stored in C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\TEMPLATE\Pages. The viewpage.aspx is represented as AllItems.aspx in a default library, the form.aspx file is being used as (you guessed it); NewForm.aspx, EditForm.aspx and DispForm.aspx. So when you open up AllItems.aspx in SharePoint Designer, you’re not actually opening a file from the content database, but the viewpage.aspx page is opened from disk. SharePoint remembers in what webpart zone you’ve added webparts and places those in there for you.

When you use SharePoint Designer often, you probably know the message telling you that you’re customizing a page from site definition. This is called unghosting. Since it would be foolish to edit the aspx page on disk (your changes would then be applied to all forms on all sites), SharePoint makes a copy of the page on disk and places that in the content database. The next time you load the page, your customized version is loaded instead of the default ondisk version. And when you revert to site definition, well you probably get the idea; you reghost the page and it’s loaded from disk again. Cool.

Why is this important? Copying the template files from disk is the first step of your modification process!

Let’s start with a modification to NewForm.aspx. What you need to do is:

1. Copy the form.aspx page from C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\TEMPLATE\Pages into your solution
2. Make sure the file is marked as an Element File. You can do this in the file properties (Deployment Type) or in the .spdata file
3. Now edit the aspx page the way you want it to, you can add JavaScript and CSS, replace ootb parts, whatever you like.
4. The final step is to make sure your list will use your customized version instead of the default one. Therefore you open up the schema.xml file of your list and find this line:

   <Form Type="NewForm" Url="NewForm.aspx" SetupPath="pages\form.aspx"
WebPartZoneID="Main" />

   Replace it with:

   <Form Type="NewForm" Url="NewForm.aspx"
Path="\CustomListInstance\NewForm.aspx" WebPartZoneID="Main" />
   Make sure the path matches with the path of your list instance. A subtle difference is the difference between SetupPath and Path. Where SetupPath refers to C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\TEMPLATE as root directory, the Path attribute uses your feature directory as root path.

5. Deploy the list to a site, and your customization should be in place

Not too bad right? It’s more a matter of knowing the right tricks.

And once you know the right tricks, you can repeat them for the other forms. You can use you adapted form template for all the form types, or create a seperate one for Editing and Displaying if you like.

And for adding custom content to the AllItems.aspx page, the steps are basically the same:

1. Copy the viewpage.aspx page from C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\TEMPLATE\Pages into your solution
    
2. Make sure the file is marked as an Element File.
    
3. Now edit the aspx page the way you want it to.
     
4. The final step is to make sure your list will use your customized version instead of the default one. Therefore you open up the schema.xml file of your list and find this line:
<View BaseViewID="1" Type="HTML" WebPartZoneID="Main"
DisplayName="$Resources:core,objectiv_schema_mwsidcamlidC24;"
DefaultView="TRUE" MobileView="TRUE" MobileDefaultView="TRUE"
SetupPath="pages\viewpage.aspx" ImageUrl="/_layouts/images/generic.png"
Url="AllItems.aspx">


   Replace it with:

   <View BaseViewID="1" Type="HTML" WebPartZoneID="Main"
DisplayName="$Resources:core,objectiv_schema_mwsidcamlidC24;"
DefaultView="TRUE" MobileView="TRUE" MobileDefaultView="TRUE"
SetupPath="pages\viewpage.aspx" ImageUrl="/_layouts/images/generic.png"
Url="AllItems.aspx">

   Same thing as above. Use Path instead of SetupPath and repeat this for every view element you might have in your schema file.

5. Deploy the list to a site, and your customization should be in place

Cool! Now you can deploy custom stuff to all of the default forms in a list, how nice is that. Oh and one more tip. Suppose you don’t want to use the default ListView webpart in your new / edit form, you can easily replace it with a webpart of your own. You can do this by changing the UseDefaultListFormWebPart attribute to “false” instead of true. Adding a new webpart is done inside of the Form tag and looks like this:


<Form Type="NewForm" Url="NewForm.aspx" SetupPath="pages\form.aspx" WebPartZoneID="Main" UseDefaultListFormWebPart="False" >
  <WebParts>
    <!-- Add your custom webparts here -->
  </WebParts>
</Form>