Using JavaScript in SharePoint forms enables developers to quickly customize the “look and field” and the behavior of a SharePoint form (Display, New or Edit form). It’s quick because you will see the effect directly on the form and given that you are embedding the JavaScript properly (putting the script in a content editor web part), you can also easily transport your code from development to production environment.
I recently have a chance to modify some SharePoint form fields thru JavaScript and would like to share my overall experience using JavaScript:
- make a text field readOnly: my first attempt is by setting the disabled property to true with no success, the correct answer is document.getElementById(’your_control_id’).readOnly = true;
- make a checkbox field readOnly is more complicated, the readOnly property doesn’t exist/work, so I keep on researching and finally have this:
function makeReadOnly()
{
return false;
}
if (document.getElementById(’your_control_id’).type == “checkbox”)
{
document.getElementById(’your_control_id’).onclick = makeReadOnly;
}
- I am unable to make a textarea field read only (I will try again later)
- Setting a default value for people picker field is so far unsuccessful, I think it’s because that field is not really a plain textbox, the whole field include some javascript to validate the entry and some hidden fields as well. If setting a default value is really needed, do it thru API code instead (so create a sharepoint list item in code and set the value for the people picker field)
After thought of using JavaScript:
Works great for simple form behavior handling but if a form get really complicated e.g. data validation, dynamic value, I would suggest building an ASP.NET control or Infopath form rather than adding logic on the SharePoint Display/Edit/New forms.
Introduction
I first want to mention that I learned how to do this by following the four part workshop written by Robert Shelton. This is a very comprehensive workshop that gives you access to all of the source code and documentation. Where Robert’s workshop walked you through building a complete workflow in Visual Studio including the Association and Initiation, my particular needs at the time were focused solely on an Initiation form. In this post, I will attempt to condense this lesson as concisely as possible.
I am using Visual Studio 2005 for this process, so all of my screenshots will be from that version.
Let me first address the question “why Visual Studio?” Initiation forms can easily be built using InfoPath. The answer is simple: an Initiation form built in InfoPath doesn’t easily (if at all) allow you to access data from the list item on which you are running the workflow.
What you can expect from this post
This post is not a comprehensive tutorial on how to build a custom workflow. You should already have familiarity with building basic workflows using Visual Studio. There are two parts to building a workflow that uses a custom Initiation form: creating the Initiation form and creating the workflow itself. This post focuses most of its attention on building the initiation form. I only highlight the important aspects of building the workflow itself as it pertains to this situation.
To demonstrate how this is built, I will present an example that I recently built. Our corporate intranet portal contains a list of project information. I needed to produce a workflow that would allow a user to publish that information to our public website hosted on a different farm. Before publishing, the user should have the ability to edit the data to get it “website ready.”
Read More »
I recently stumbled upon this little bug by accident. If you create a folder called “Forms” in a document library, you won’t be able to re-name it or delete it directly. Backing up for a second, you can’t create a folder called “Forms” directly as a top-level folder in the library - the name conflicts with the hidden “Forms” folder that is inherit in any document library. However, SharePoint will allow you to create such a folder as a sub-folder to another folder.
Let’s say, for example, that you create a folder called “HR Documents,” inside which you create folders called “Policies,” “Procedures,” and “Forms.” If you try to delete or rename the “Forms” folder, SharePoint spits back an error message. This, apparently, is a known bug, but I have not come across a fix, as of yet.
The only way to rid yourself of such a folder is to delete the containing folder (e.g. “HR Document” in my example), or to delete the library altogether.
So, take heed in naming your folders.
This Preview Pane function is OOTB and is always there, you go to “modify this view” in the list and at the view setting page, under the style section, select the “Preview Pane” option:

Open this view now and you will have an easy way to preview all your information by hovering on the list item:

Microsoft has made an annoucement on its Business Intelligence strategy by adding Office PerformancePoint Server 2007 features (originally a separate product) into MOSS enterprise CAL this week.
Now there is one more reason to LOVE SharePoint!
Read the full press news here.
Do you have a lot of outlook contacts that you want to share with other people? In particular, share it with users in MOSS/WSS 3.0? Do you want to be a power user of both MOSS and outlook 2007? Do you know that you can manage your files, documents and also contacts in outlook 2007 and in MOSS AT THE SAME TIME (That they are two-way-synched)?
To upload your outlook contacts, first create a sharepoint contact list in a WSS 3.0 site (if not already exists):

In the SharePoint contact library, under the Actions menu, click “Connect to Outlook”:

This will create a link to the SharePoint contact library created above inside your Office Outlook 2007!
And then within your outlook, just copy and paste your existing outlook contacts into the new SharePoint contact library and you are done!
This was a question popup about a year ago when the client SPS 2003 virtual directory is hosed on a drive other the default C:\Inetpub\wwwroot location.
It all began with a gradual migration, the new targeted web application for MOSS 2007/WSS 3.0 is created automatically at C:\Inetpub\wwwroot\VirtualDirectories\
while the SPS 2003 site is at E:\Inetpub\wwwroot. At that time, I only know to manually change the virtual directory physical path location in IIS manager after the targeted web application is created.
Yesterday, I came across Bill Baer’s blog and one of his posts answered my questions of changing the default location for virtual directory creation.
The method turns out to be not a “SharePoint configuration” but rather a “IIS configuration”. Not at all an experienced server/IIS administrator myself, I feel like his post is “good to know” and one of the gotcha situation
I had a situation where I needed to compare a query string parameter to a value in a list inside a data view web part in SharePoint Designer. If the two values matched in regards to the text, but did not match in regards to case (for example: SomeWord vs. someword), they would not match when compared in the XSLT. It appears that the version of XSLT used in a data view web parts doesn’t support the lower-case() and upper-case() functions.
Luckily, I discovered a workaround. Originally, I had the following code:
<xsl:variable name="Rows" select=/dsQueryResponse/MyList/Rows/Row[normalize-space(@MyField) = $myQueryStringVar]“/>
At first, I tried this:
<xsl:variable name="Rows" select=/dsQueryResponse/MyList/Rows/Row[normalize-space(lower-case(@MyField)) = lower-case($myQueryStringVar)]“/>
But I received an error that the function was not supported. The workaround is as follows:
<xsl:variable name="lower">abcdefghijklmnopqrstuvwxyz</xsl:variable>
<xsl:variable name="upper">ABCDEFGHIJKLMNOPQRSTUVWXYZ</xsl:variable>
<xsl:variable name="Rows" select="/dsQueryResponse/MyList/Rows/Row[normalize-space(translate(@MyField,$upper,$lower)) = translate($myQueryStringVar,$upper,$lower)]“/>
As a SharePoint administrator, keeping your SharePoint environment up-to-date is one of the important tasks. Since MOSS 2007 and WSS 3.0 went RTM in November 2006, there are 2 major updates: Service Pack 1 and Infrastructure Update.
The following link summerizes the deployment roadmap for these important updates and provides useful information in terms of understanding and planning for those major updates:
Updates Resource Center for SharePoint Products and Technologies (Powered by Microsoft TechNet)
A must-have browser favorite for all SharePoint administrators!
Have you ever thought to yourself that the development experience in SharePoint is quite frankly a pain? That there are no real best practices or guidance about how to conduct application development or how to use an Application Lifecycle Management (ALM) process?
I was introduced today to the link below on msdn that offers a series of articles whose goal is to define some best practices and offer guidance on how to conduct an ALM process using tools such as Visual Studio and Team Foundation Server.
Most of the articles are still under construction, but this definitely looks like a link to keep handy.
The link is http://msdn.microsoft.com/en-us/sharepoint/cc990283.aspx.