Using Native SharePoint Form Fields

When making a generic web part for modifying or interacting with different SharePoint data you can’t always predict the column data type before hand. The best way to make sure your web part works regardless of what data is being tossed in to it is to just use the out of box SharePoint Form Field control. This control goes ahead and grabs the column edit and display templates depending on the state you specify. Below is a code snippet example of how to use this control. Takes a lot of the headache out when dealing with unknown data types/building generic web parts.

/// <summary>

/// returns a valid native sharepoint fieldlabel control for use in forms

/// </summary>

/// <param name=”newItemContext”></param>

/// <param name=”fld”></param>

/// <returns></returns>

private FieldLabel buildLabel(SPContext newItemContext, SPField fld)

{

FieldLabel lbl = new FieldLabel();

lbl.ControlMode = SPControlMode.New;

lbl.FieldName = fld.Title;

//lbl.ItemContext = newContext;

lbl.RenderContext = newItemContext;

lbl.ID = String.Format(LABEL, fld.InternalName);

return lbl;

}

 

/// <summary>

/// Returns a valid native sharepoint field control based ont he field type/definition of the passed spfield object for use in forms

/// </summary>

/// <param name=”newItemContext”></param>

/// <param name=”fld”></param>

/// <param name=”listID”></param>

/// <returns></returns>

private FormField buildFormField(SPContext newItemContext, SPField fld, Guid listID)

{

//build form field interaction UI using native formfield control

int id = mainFormFields.Count + repeatingFormFields.Count;

FormField formField = new FormField();

formField.ControlMode = SPControlMode.New;

formField.ListId = listID;

formField.FieldName = fld.InternalName;

formField.RenderContext = newItemContext;

formField.ID = String.Format(FIELD, fld.Id.ToString());

return formField;

}

Creating a SharePoint 2007 WSP Without Templates

This post is to cover how to make a SharePoint 2007 WSP without using a prebuilt Visual Studio project template. Why you’d want to do this is another question entirely but falls back mostly to the ‘enterprise ready’ state of the SharePoint development story, especially when using things like a central build server. 😉

 

So, I’m going to assume you have your feature already built and focus on making your content in to a magic solution.

First we need to create a DDF file, this is a plain text file that is used by MAKECAB to generate your WSP and as an example looks like this:

; SOLUTION COMMENT ; FEATURE NAME LIST IS HANDY TO PUT HERE .Set CabinetNameTemplate=HelloWorldSolution.wsp .set DiskDirectoryTemplate=CDROM ; All cabinets go in a single directory. .Set CompressionType=MSZIP ; All files are compressed in cabinet files. .Set UniqueFiles=’ON’.Set Cabinet=on .Set DiskDirectory1=. ; Solution manifest “Solution Manifest.xml” “manifest.xml” ; Assemblies “bin\Release\HelloWorld.dll” “HelloWorld.dll” ; Features “TEMPLATE\FEATURES\HelloWorld\elements.xml” “HelloWorld\elements.xml” “TEMPLATE\FEATURES\HelloWorld\feature.xml” “HelloWorld\feature.xml” ; Layouts Resources “TEMPLATE\IMAGES\HelloWorld\Hello.gif”        “IMAGES\HelloWorld\Hello.gif”

; COMMENT

“RELATIVE PATH TO FILE” “PATH TO SAVE IN WSP FILE”

As you can see the wsp filename is specified in the Set CabinetNameTemplate variable at the top. Then the left hand side of each file reference is the relative path to a file from where the DDF is ran. I normally find it easier to see where things go if I make a folder structure similar to the SharePoint tree within my project so I can see where things will end up or should go. On the right hand side is the path to save the file to within the WSP itself.

Next, we have the Solution Manifest.xml, this is what is used by SharePoint to actually install your solution properly.

<?xml version=”1.0″ encoding=”utf-8″?> <Solution SolutionId=”41CD42ED-676E-44E0-A9B9-B606BE8AC6ED” DeploymentServerType=”WebFrontEnd” ResetWebServer=”TRUE” xmlns=”http://schemas.microsoft.com/sharepoint/”&gt; <Assemblies> <Assembly DeploymentTarget=”GlobalAssemblyCache” Location=”HelloWorld.dll” > <SafeControls> <SafeControl Assembly=”HelloWorld, Version=1.0.0.0, Culture=neutral, PublicKeyToken=” Namespace=”HelloWorld” TypeName=”*” Safe=”True” /> </SafeControls> </Assembly> </Assemblies> <FeatureManifests> <!– Site Collection Scope –> <FeatureManifest Location=”HelloWorld\Feature.xml” /> </FeatureManifests> <TemplateFiles> <TemplateFile Location=”IMAGES\HelloWorld\image.jpg” /> <TemplateFile Location=”LAYOUTS\HelloWorld\style.css”/> <TemplateFile Location=”LAYOUTS\HelloWorld\script.js”/> </TemplateFiles> </Solution>

There are a few key bits to point out:

<Solution> – Gives the solution ID and install type of your WSP

<Assemblies> – Any assemblies to add to the GAC during solution install

<FeatureManifests> – Any and all features to install, the path here is the same one you specified within the DDF file

<TemplateFiles> – Often times you have extra files that need to get added around the file system, the path here is the same as was used in the DDF file, and is relative to the TEMPLATES folder within the SharePoint folder hive.

After these bits are done you can toss them into an empty visual studio project, and use a post-build script to copy your files to the right places and run the magic WSP building command *drum roll*…

MAKECAB /F WSP.DDF

This will spit out a shiny new WSP for your project without using any Visual Studio templates that can cause issues with non-SharePoint dev boxes.

And…just in case you’re stuck on making your visual studio build script here’s an example that copies the built assembly from your main code project to your solution builder project and then builds your WSP:

cd $(ProjectDir)

cd ../MainProject/bin/Release

copy Assembly.dll $(TargetDir) /Y

cd $(ProjectDir)

MAKECAB /F WSP.DDF