|Metrosexual web developer|
|Socially inept technical guy|
|Luddite IT manager||
(sorry … why are you here anyway?)
But there are several problems with the method that prevent it from getting a better CleverWorkaround rating than “Meh”. They include:
- One size fits all, fields are hidden for all visitors irrespective of need.
- You need to modify auto-generated pages
- You need to modify a page from its site definition
- Insecure, relying on client side to hide content/controls is not a secure solution
On top of that, we are customising auto-generated aspx pages, namely NewForm.apsx, EditForm.aspx and DisForm.aspx – probably not such a good idea. (The fact that the “Edit Page” menu option for these files should be a hint that Microsoft are discouraging modification).
The fourth problem is a tricky one and a large topic in itself. Each time you customise a page, it no longer ‘predictable’ from an upgrade perspective, because by the nature of customisation, you are introducing variation. A future SharePoint upgrade or service pack may well make changes to the site definitions and automagically all pages created from them will upgrade fine. But any customised pages are not guaranteed to work.
So what is the result of this? Increased governance costs. Customisations need to be tracked and managed and upgrades are more complex. Thus my perspective on this is that if you can find an easy way to avoid customising pages from the site definition, then do so. Obviously, In a web content management scenario, significant site definition customisation is a likelihood, but in pure collaboration scenarios, you would be surprised with what you can get away with.
Insane? Totally – but sadly a true story.
Anyhow lets get back to the task at hand.
Wait just a dog gone second… is this supported?
Hacking away at the form pages (NewForm.aspx, EditForm.aspx and DispForm.aspx) certainly wasn’t supported in SharePoint 2003 according to Maurice. But with 2007 its harder to work this out. I’ve found nothing official, and Microsoft has a KB article talking about how to modify these pages without breaking stuff. To quote from them:
If you want to customize the controls that appear on the NewForm.aspx page, and if you do not want to show the default List Form Web Part, you can hide the List Form Web Part. To do this, follow these steps:
- Start SharePoint Designer 2007, and then open the NewForm.aspx page for the list.
- Right-click the List Form Web Part, and then click Web Part Properties.
- Expand Layout, click to select the Hidden check box, and then click OK.
Seems like a pretty clear endorsement to me! Anyway, back to business!
Re-examining the code
So, we have established that having to cut and paste this via SharePoint designer is not really the ideal method if you want to promote cleverness and re-use. We also don’t want to customise the pages from the site definition, and we want it to work with multiple audiences. Can we satisfy all of these goals?
Yes indeedie :-).
Step 1. The Web Part
File name and page layout do not matter as we will be deleting this web part page soon. Now edit this newly created page and drag and drop a “Content Editor Web Part” to one of the web part zones on the new page (doesn’t matter which)
Now, as instructed on the newly created web part, open the tool pane to the configuration screen below
Also, watch out for issues with quotes when you paste from here. I have seen my double quotes get screwed up breaking the code. If you uncomment the debugger line and it still never fires, you probably have screwed up quotes.
Step 2: Export the Web Part
The next step is to create a new web part, based on the customised content editor web part. This is an easy process that I have outlined below.
On the customised content editor web part created from step 1, click the edit drop down menu and choose “Export”
Save the web part file with a meaningful file name.
Once you have exported this web part, you can delete the web part page as we are finished with it.
The next step is to upload this exported web part into the site collection web part gallery. This is performed in site settings at the site collection level. Navigate to the web part gallery and upload the file you just saved.
In the next step, we have to set some metadata properties for the new web part. Since the web part gallery is just a document library, it can be assigned columns and content types like any other SharePoint document library. Of particular note here is the Title, Description and Group fields. The Group field is particularly useful, as when this web part is used, it is easy to find.
Sorry for the abrupt stop here readers, but that’s it for part 2, I was going to make one large post on this, but it’s simply gotten too big, so I’ll finish this off in part 3. But fear not, part 3 is 90% written and should be published within a day or two.
Bye for now