SharePoint Magazine » forms

A tribute to the humble “leave form” – Part 7

cleverworkarounds — Tue, 10 Feb 2009 13:08:04 +0000

Hi all

Welcome to edition 7 of this seemingly never-ending tribute to the humble annual leave (vacation) form. This is getting to be like the “Friday the 13th” series of movies – they never stop!

First up, I want to categorically state that, as a heterosexual Australian male, I have a few stereotypical personality traits . I enjoy beer, kung-fu movies, Burger Rings, Vegemite and Tim-Tams, love the cricket (especially playing India) and most importantly of all, I do not read instructions. Period. I think that ignoring the RTFM rule is a characteristic of all of humanity but Australians in particular seem to celebrate this trait as something endearing.

Therefore, it pains me greatly to have to inform you that this seventh edition of the series is one of those posts where you have to put on the brakes and explain some really boring conceptual stuff to proceed with the rest of the series. Yeah, I know – theory is boring and sucky and you just wanna get into the nuts and bolts of it all. But, as Homer demonstrates below, sometimes we have to defy our genetic programming and actually read the instructions. The alternative is a SharePoint solution equivalent to that of Homers BBQ.

This post will deal with some of the mechanics of form submission and form publishing.

What has gone before…

The first few posts in this series are starting to get hazy – it seems so long ago now. To sum it all up in a nutshell, we introduced the leave form as a means to introduce a lot of key SharePoint features in an easy to understand and relevant way. We set several requirements that we had to achieve.

Automatic identification of requestor

Reduce data entry

Validation of dates, specifically the automatic calculation of days absent (excluding weekends)

Mr Burns is not the only approver, we will need the workflow to route the leave approval to the right supervisor

We have a central leave calendar to updateAt the end of part 6 we were working on validation of dates. We added some validation rules to ensure that you could not return to work before you started your leave of absence. But at the end of that post, I showed how a published form did not obey our data validation rule, where the form was set to prohibit incorrect dates, yet I was able to click save and put the form straight into the document library. What the…?Why did this occur?

Saving vs Submitting – form confusion

Like everything else designed by nerdy engineers, InfoPath and Forms Services can be used in a few different ways. This offers flexibility of course, but has the disadvantage that if the flexibility is not well understood (i.e not reading the instructions ), it is easy to cause user confusion. Homer is a classic case of a person who, when faced with two choices, will always pick the wrong one.

You have to remember that InfoPath started out as a program installed onto your PC, along with other MSOffice applications. Thus, historically, an InfoPath form is just another type of document. In its simplest (and default) scenario, the form is very much like any other MSOffice document in that you create/open the form, edit it and then save it.

But hang on a second! Most of the time, the data collected in the form is part of a larger business process. Also most of the time, business process needs to do “stuff” with the information that the user has entered. In other words, the data usually doesn’t stay in the forms that users fill out.

So the InfoPath designers, wanting to please everybody, designed InfoPath in such a way that saving a form and submitting a form are two different things. Homer Simpson doesn’t care about this nor should he. He just wants to fill out the form so he can go back to dreaming about the land of chocolate.

Here is the key thing you need to know, though. Saving a form is, in effect, performed on the presumption that the form is still a work in progress. Saving the form should be thought about in the same way you would save a word document after performing some edits. Because the form is still a work in progress, data validation should not take place.

But at some point the form stops being a ‘document’ and becomes…well… a form! It is complete and no more edits should be made. This is when you actually submit the form!

Submitting a form triggers the data validation rules that were set up in part 6.

Big deal…When does this get hard, Paul?

Okay, so you may not think that there is really that much of a drama with the whole “save vs submit” thing. But when InfoPath is integrated with SharePoint via Forms Services, it can get complicated. You see, InfoPath allows you to create forms that submit their data to one or more locations. For example, the Springfield Nuclear Power Plant leave form could be set up so that when Homer submits his application, the data is sent to a database, and a copy of each completed form is also sent in an e-mail message to Waylon Smithers and Monty Burns.

For reference, here are the places that InfoPath can submit to;

A Microsoft Access or Microsoft SQL Server database
A Web service
A server running Microsoft Windows SharePoint Services
In an e-mail message
An application on a Web server
A custom application that hosts InfoPath

Now, given that this series of articles is about SharePoint, which option of the above list do you think we are interested in? You guessed it! The third option in the above list is SharePoint.

But here is the root cause of the confusion, when you publish an InfoPath form to SharePoint, all forms that you fill in end up being created in a document library. Back in part 4 of this series, we first published the form and as part of that process, created a form library called “Leave Forms”. Consider the screenshot below. We are about to create a new form in this library.

Below is a screenshot of the new form to fill out. Note the toolbar at the top with a “Save” and “Save As” options. If you then click ‘Save” on the form, it will prompt you to save into the above document library.

Therefore, if you use the “Save” option, the “In-progress” copies of the form are stored in the document library and no data validation has taken place. You really have not submitted the form at all.

Does the end user realise this? Some might – but come on! This is Homer J Simpson we are talking about here!

So clearly we need to submit this form because in part 6 we added validation rules that need to be checked. But, what the…? – How the hell do I submit?

Setting up form submission

Real programmer disclaimer: Yes I know there are other ways of doing all of this, but remember – this series of posts is for beginners.

Okay, for now the theory bit is over, and now we get to play with InfoPath again. We are going to add the form submission capability to our existing form so that we can actually submit the form. The thing is, I am also going to *remove* the “Save” and “Save As” options from that toolbar, so that the only action you can make is to submit.

Why would I do this? Several reasons.

It is a simple form and really, you either fill it in and submit or you don’t. There really isn’t that much of an imperative to save this form, prior to submitting it.
When you submit a form, and you are submitting to a SharePoint library, the submitted form is saved. Therefore, I don’t need a “work in progress” copy.
The Homer factor. If you supply a “Submit” and a “Save” button, you know full well that Homer will go and click the “Save” button, when he should be clicking “Submit”. As soon as the save dialog pops up, he won’t know what to do. At this point he will lose interest and fall asleep.

Hiding save buttons

So, start InfoPath, open up the leave form in design mode, and choose “Form options” from the “Tools” menu.

From the list of options, choose “Open and Save” and uncheck the “Save and Save As” checkbox as shown below.

Click “OK” and republish this form to SharePoint using the steps described in part 4. Note the before and after screenshots below

Spot the difference? The “Save” and “Save As” buttons are missing, and with that I can confidently say that I have now made this form Homer proof because he can’t inadvertently click “Save” and think he has submitted the form. Of course, it is so Homer proof that he now has no way to submit the form, so now we have to enable the “Submit” button.

Enabling the submit button

Once again, open the leave form in design mode, and choose “Submit Options” from the “Tools” menu. InfoPath will dutifully display a fairly nondescript dialog box that, at first glance, seems rather simple. There is a checkbox that you need to tick to “enable form submission”. Sweet! How easy is that?

Upon checking that box, you now have to choose where you are going to send form data to. The default option is “Email”, but we want to send it to a SharePoint document library, as shown below. Choose SharePoint and then click OK.

Uh oh! Did I say this was going to be easy? Okay I lied .

So, what is this message telling us? “You must select a data connection for submitting to a SharePoint document library”. Hmmm…I hope that something about that message sounds vaguely familiar to you. That is because this is not the first time we have dealt with data connections.

Data Connections revisited

Way back in part 5, you earned your CCLFD certification by creating a data source that automatically identified Homer by talking to SharePoint web services. If you missed that post, then I suggest reading it, as it is a great example of utilising data connections to *receive* data into InfoPath.

In part 5, we set up a data connection to a webservice by following a wizard. To remind you of how it was done, I have copied the screenshots to this post.

Now, take a look at the second screenshot from the above three. It is asking you to create a connection to receive or submit data and at that time we were receiving data. Guess which one we are doing this time?

So, back to our “Submit Options” dialog box. We were not able to click “OK”, because we have not created a data connection to submit the data. Let’s now start this process by clicking the “Add” button. Given that you have already told SharePoint that you want to submit to a document library, InfoPath now wants to know the name of that document library and the name of the file that will be created by the submit.

Now, given that the entire staff of the nuclear power plant will be filling out this form, we don’t want to simply call the submitted form “Form” as suggested by default. If we did that, we would end up with a document library containing a single file called “FORM” due to the fact that all previous “FORM” files would have been overwritten and replaced by the current “FORM”.

Luckily the InfoPath team anticipated this and the filename can be dynamically generated using functions. (We looked at functions early in part 5).

First up though, I will specify the document library to submit completed forms to. It will be in the same document library that we was created when we first published the leave form in part 4,the imaginatively titled “Leave Forms”. Below is the library as it is inside the radiactivenet site. Note the URL is exactly what I entered into the “Document Library” field.

A unique filename

The final step for submission is to create an auto-generated filename that is unique. Although the principle is dead simple, this bit is actually tricky when you do it for the first time.

The file naming convention to be used will be as follows:

“Leave Form – ” + [EmployeeName field] + ” – “, [LeaveType field] + ” – ” + [todays date]

Here are some examples of this convention in action with various staff.

“Leave Form – Homer Simpson – Sick – 2007-09-18″
“Leave Form – Lenny Leonard – Annual – 2008-11-22″
“Leave Form – Carl Carlson – Bereavement – 2008-12-25″

So, how do we achieve this? Let’s get back to the screen where we are prompted to add a file name for a submitted form.

Click the “Fx” button to the right of the “File name” textbox and you will be presented with the (far too small to be user friendly) “Insert Formula” dialog box. We are going to create a formula that constructs the desired file name.

The first thing to note is that we will be using a combination of fixed text, the data entered on the form and built in InfoPath functions. To join all these together in the manner we want is referred to as concatenation. Why do people call it concatenation? I have no idea but it’s obvious that an engineer thought up that name! .

We start by inserting the concatenation function called “concat”. Click “Insert Function” and in the leftmost window choose the “Text” category. The function called “concat” should be the first one listed. Select it and click “OK’ and you will see that a partially completed formula has been created.

The first part of our file name is the text “Leave Form – “. So single click the first occurrence of the “double click to insert field” hyperlink and it will be highlighted. From here, simply type in the string “Leave Form – ” (including the double quotes).

The next part of the file name is the name of the employee. We already have this, because in part 5 we set up a data connection to automagically grab first name and surname and store it in the textbox called “EmployeeName”.

Single click the next occurrence of the “double click to insert field” hyperlink and it will be highlighted. From here, click “Insert Field or Group” and choose “EmployeeName” from the list of fields.

Okay, so we have the “Leave Form – Homer Simpson” part done. Next we want a hyphen ” – ” and then the LeaveType field. By now you should be getting familiar editing the formula in the dialog box. Rather than bore you with even more screenshots, I’ll talk through the next 2 steps.

Single click the next “double click to insert field” link.
Type in (note the leading and trailing space) ” – “
Type in a comma (minus quotes) “,”
Click “Insert Field or Group” button
Choose the “LeaveType” field and click OK.

If all has gone to the script, then you will see this in for formula box.

Note that you can use the mouse to place the cursor anywhere in the Formula textbox and modify what is there.

Finally, we need another hyphen and to insert another function. This time the function is called “time” and it returns the current date in a short locale based format.

Referring to the above screenshot, place your cursor between the last letter of the underlined LeaveType (which is “e” ) and the closing bracket.
Type in (including the quotes and note the leading and trailing space) ” – “
Type in a comma (minus quotes) “,”
Click “Insert Function” button
Choose “Date and Time” from the Categories List in the “Insert Function” dialog box
Choose “today” from the list of functions and click “OK”

We are done! The final formula looks like this. Click “OK” and you now should be back at the data connection wizard (the second screenshot below).

Click “NEXT” on the wizard, and we are prompted to give this data connection a name. Since this data connection has been created to submit leave forms to a document library called “Leave Forms”, I figured that a good name would be “Submit to Leave Form Library”. Click “Finish” and you are done!

To recap on what we have completed in this section, each time a form is submitted, its filename will be automatically specified and the end-user does not have to worry about it.

All rightie, then! Let’s republish this form to SharePoint and take a look at the effect.

Testing it out

Assuming everything worked, the effect of what we have done is immediately noticeable. We now have a “Submit” button on the form where the “Save” and “Save As” used to be. Sweet!

So let’s test the data validation rules that we created in part 6. If you recall, this form should not be submitted if the return date is before the start date. For that to really happen you would have to be Dr Who and use the Tardis to arrive before your departure…

Below is the form with deliberately incorrect data (click to enlarge).

If I now click the newly visible “Submit” button, what happens? Ecccccxcelent! It refuses to submit the form.

I don’t know about you, but this is one of those error messages that some people simply will not read. Homer will no doubt call technical support but the point is, crap data has not gotten past the form in the first place.

Now, when we correct the fault and resubmit the form, it accepts!

Click “Close” and we now see the newly submitted form in the document library, saved with our file naming convention! Woohoo!

Conclusion (Are we done yet?)

We now have achieved the goal of ensuring that our form is validated before being submitted. From a skills point of view, you now have created data connections to both send and receive data and you have integrated your form with web services, as well as some nice data validation logic.

Waylon Smithers is still pleased with progress thus far, and Homer hasn’t managed to completely derail things just yet.

But unfortunately for all of us, there is still much work to do. The next post will spend some time pimping up this whole validation and submission process, illustrating a pitfall or two along the way.

Thanks for reading

Paul Culmsee

www.sevensigma.com.au

www.cleverworkarounds.com

A tribute to the humble leave form – part 6

cleverworkarounds — Fri, 28 Nov 2008 09:29:13 +0000

Hi again

When I started this series of articles, I knew it would be quite a few parts and ambitious in its way. But after reading some of the other great articles on SharePoint Magazine, such as Bjørn Furuknap’s first article on customising the user experience, I’m now feeling like I picked the easiest topic of all!

Seriously, Bjørn, part 1 of your series is the closest experience I can imagine to any man giving birth! I bet you feel relieved getting that one out of your system!

So, do I feel guilty that my subject matter is easier? Am I suffering nerdiness envy?

Hell, no! I’ll stick to my fantasy world of user acceptance testing with Homer Simpson any day!

Previously…

Given that there are big time gaps in getting these articles out, I’d just like to reiterate that this series is pitched at a very wide audience, so hard-core nerds will probably find it waffly and frustrating. But then again, most regular people find hard core nerds waffly and frustrating .

I have been writing this series from the point of view of a frustrated implementation developer/engineer who has to deal with a clueless business development manager and a difficult customer. This, of course, is completely unfamiliar territory for all implementation developer/engineers because none of you reading this would have ever experienced such a situation, right? … hehe

Part one of this series introduced some background and provided the requirements for the leave application/approval process for the Springfield nuclear power plant. Those requirements were:

Automatic identification of requestor

Reduce data entry

Validation of dates, specifically the automatic calculation of days absent (excluding weekends)

Mr Burns is not the only approver, we will need the workflow to route the leave approval to the appropriate supervisor

We have a central leave calendar to update

Parts two to four were really the “slick presales demo” parts of this series where the world is promised to the client and, hence, expectations were completely off the planet. Thus, we started out nice and easy in part two and three, where we introduced InfoPath 2007 and went through the exercise of importing the existing Springfield MSWord based form. We then added some data entry controls and tidied up the formatting. In part four, we published this form to SharePoint itself.

All in all, the first four articles covered some pretty straightforward stuff. Now, however, the salesman has moved on and our intrepid engineer is starting to get into the pointy end of things. In part five we delved into the scary world of web services and InfoPath data connections so satisfy the requirement of automatic identification of the requestor. That was a bit of a jump, wasn’t it?

This time around, let’s take care of the “reduce data entry” requirement, and leverage some of InfoPath’s useful features to make our form smarter. For those who found article 5 a bit heavy, this one is actually quite a bit easier (but it’s just a brief lull before we get to coding!). At the end of part 5 I said I’d deal with how to automagically handle the employee number – but I have decided to take care of that a little later.

Preventing a rift in the space-time continuum

Yeah, I know I was using the Simpsons theme for this series, but today I am dropping in a dash of Heroes.

First up, we need to add some logic to the form so that it doesn’t submit crap (that’s the technical term for “invalid”) information. For example, we want to make sure that you cannot return to work on a date *before* you leave – unless you’re Hiro Nakamura, of course.

Generally, for the rest of us who cannot bend time, you do actually come back to work at some point *after* you leave, so let’s make the necessary changes to ensure that our form does not destroy the world in some space-time vortex.

Today we are interested in the three date/time fields as shown below.

If you recall in part three where we created the form controls, we gave them the meaningful names of CommenceDate, CompletionDate, ReturnDate.

For reference, at any time, you can review your field names easily by clicking the “Data Source” link in the InfoPath design pane as shown below.

So, we have these three date fields and the rules are:

The completion date cannot be *before* the commencement date.
The return to work date cannot be *before* the completion date.

When you think about what we are doing here, we are validating data to make sure that it matches our business rules. Fortunately for us, InfoPath has some nice capabilities here to assist. Even better, they called it “Data Validation”. So, let’s take a closer look…

Select the “Completion Date” control, right click and choose “Data Validation”

You are presented with a fairly unexciting text box asking you to add a condition that determines whether the value entered is valid. Clicking the “Add…” button displays the dialog box to add a condition. It is quite common to have multiple conditions that need to be satisfied in order for the data entered to be considered valid.

In our case, we wish to ensure that the CompletionDate field cannot contain a value that is less than the CommenceDate field. Create this condition by specifying “less than” from the middle drop down box, and then picking the “CommenceDate” field for the third dropdown box.

Clicking OK and we have our completed validation condition!

One final OK and we are back at our form and ready to test this. Rather than publish the form to SharePoint now, we can make use of InfoPath’s “Preview” button on the toolbar and test it out. Below I have an example preview where Homer has been identified as per the previous post. Additionally, I have used the date picker to specify the commencement date (October 25 2008) of leave.

What do you now see on the Completion Date field? What’s with that red asterix? Maybe I should hover my mouse over it and take a look, eh?

Aww… How sweet! A tooltip that matches the description I gave for this data validation condition. Well, what do you know? I spelt data instead of date (don’t worry I’ll fix it up later).

So, let’s try and defy time, then. I will enter October 24th as my return date. Doesn’t seem vary happy does it?

But if I change the date to the 25th of October (therefore validating the rule we set up), InfoPath happily accepts the value.

That it? That was easy!

Yeah, it was very easy so what are you complaining about? Easy is good and there should be more of it!

We now need to do the same thing for the “Return to Work” form field. Essentially, we perform the very same steps and thankfully for the both of us, I am not going to smother you with screenshots. This is where you try it yourself and instead I will simply list the steps and one screenshot.

Right click the ReturnDate field and choose Data Validation
Add a new validation condition where the ReturnDate is less than the CompletionDate
Add a tooltip text “Return date cannot be before the completion date”
Click OK twice and test using the preview button

The published experience

Now that we have successfully tested the validation rules for the date fields, let’s publish the form to SharePoint and see what it all looks like. I followed the exact publishing steps that I outlined in part 4, so please refer to that article if you need a recap.

I navigated to the forms library as described in part 4 and created a new form.

I then deliberately entered bad data into the form and sure enough, the data validation rules picked up on the issue. Excellent – Waylon Smithers is very pleased!

Reviewing our progress…

So, since we are about to see off part 6, our Project Manager wants to get a status update on how the Springfield leave form project is progressing. So, after 6 articles, what have we achieved? To remind you, the requirements were:

Automatic identification of requestor

Reduce data entry

Validation of dates, specifically the automatic calculation of days absent (excluding weekends)

Mr Burns is not the only approver, we will need the workflow to route the leave approval to the appropriate supervisor

We have a central leave calendar to update

Identification of Homer is now sorted, and we have taken steps both in the areas of reducing data entry and validating the dates (excluding days absent). So, we are tracking nicely and haven’t fallen behind schedule just yet .

Before we continue with addressing all of these requirements, we will have to take a bit of a detour as I explain below.

Too good to be true?

Here’s a little experiment for you to try. On the above form, published in its current form with deliberately invalid dates (highlighted in red), you will see a toolbar that has a “Save”, “Save As”, “Close” and “Print View” on it. I clicked the Save As button and was dutifully prompted for a filename. I called the form “Homer’s Test Form” as shown below and clicked Save

I then closed the form and checked out the form library on the http://radioactivenet site. What the…! It saved it! What’s the point of data validation if you can just save the form anyway?

The answer to that question, my friends, is there is a difference between saving a form and submitting a form. But you will have to wait for part 7 of this series for that riveting discussion!

Thanks for reading

Paul Culmsee

www.cleverworkarounds.com

www.sevensigma.com.au

A tribute to the humble “leave form” – Part 4

cleverworkarounds — Thu, 11 Sep 2008 08:00:10 +0000

Hi again. Welcome to part 4 of my tribute to the “leave form”. It’s probably time to just get straight into the article, as I think the whole leave form joke isn’t overly funny anymore

Crap, there is probably going to be a dozen or so articles and I’m running out of jokes already?

But then I suddenly remembered that in this certification obsessed IT world we live in, I could make up my very own certification! I mean how hard can it be? Just add the word “institute” to your name and your legitimate right?

Therefore I am pleased to unveil the first of a series of certifications to be offered by the CleverWorkarounds Institute and its associated body of knowledge (CIBOK). The CCLFD or CleverWorkarounds Certified Leave Form Developer certification, which allows certified practitioners the opportunity to feel vastly superior to the mere mortals they work with. Additionally, it has waaaay more bragging rights than one of those weenie certifications like MSCE or CISSP. Of course, like all acronyms to add to your business card, you are certainly guaranteed a big, fat pay rise.

So what someone wants to validate your credentials, you just flash the badge below and they will all be like…”wow, this dude is a business process god!”

SharePoint Pre-Requisites

Right enough banter and back to business! Now remember, we are in “Business Development Manager” mode in this post and therefore we are trying to impress here. Selling the client the message that the you will solve all organisational process issues (and find the answer to world peace) in InfoPath and Forms Services. So far, we have fairly quickly produced a usable InfoPath form. All in all it has taken maybe 10-15 minutes of demo time. So in the interests of “impress the client at all costs”, we have done enough to publish it straight into SharePoint, so that it is usable via a web browser.

That CCLFD certification is looking good yes?

So first up, we need a SharePoint site to publish the site to. But not just *any* SharePoint server. It needs to be running the enterprise licence if you wish to use InfoPath Forms Services. So sorry stingy people, WSS and Office SharePoint Server 2007 Standard Edition will not suffice.

Now if this were a demo, I would have already had this set-up in advance to make the client “ohhh”, “aaah”, “wooow” louder. But I think it is worth examining the prerequisites in more detail.

Assuming that the SharePoint farm been built and a web application has been created (called http://radioactivenet), it is time to create a brand new site collection to host this form. The SharePoint farm administrator performs this task in Central Administration -> Application Management. In this example, we are creating a completely blank SharePoint site.

Have we done enough to publish our form to SharePoint? Unfortunately, not quite. In fact if we tried to publish our leave form into the site as it is now, we would have a little warning message that easy to overlook and then cause you no end of wasted time.

But I am getting ahead of myself. Having created this new site collection above, we now need to enable the enterprise feature-set that includes the forms services component that we need. For the purposes of this post, I will not be explaining the SharePoint feature framework, but for the uninitiated, SharePoint is like a fisher-price toy with lots of buttons that have different effects when pushed. (We haven’t yet pushed the right button). Think about SharePoint site templates (e.g Document Workspace, Wiki Site) as automatically pressing the buttons for you.

To activate the enterprise featureset, we log into http://radioactivenet as an administrator or site collection administrator. Choose the “Site Actions” drop down menu below the search box. Choose “Site Settings” and you will be taken to the administrative back-end of a SharePoint site collection. I have highlighted the option to control site collection features. (Click to zoom)

This screen shows you all of the nice buttons to push. The one that we need for this demonstration is the “Office SharePoint Server Enterprise Site Collection Features”. Simply the click “Activate” and you are done!

Finally, let’s publish it already!

To remind you all of where we got to at part 3, we have a functional form looking like this. (Click to expand)

Publishing an InfoPath form into SharePoint is based on a Wizard. We want to impress here, so we will do a straightforward form publication. Start the wizard by choosing “Publish” from the “File menu”. The first wizard screen will ask you *where* you wish to publish to. Obviously we go with the default answer of SharePoint

Next we are asked to specify which SharePoint site we would like to deploy this new form to. We are using our newly created http://radioactivenet site.

Now we hit the first important step in the whole process. This is the step where InfoPath publishing wizard asks you to how to publish this form. While I am not going to explain each option in detail at this stage, I will warn you now that we are going to come back to this screen in subsequent posts.

Notice how “Enable this form to be filled out by using a browser” is checked? This is because this InfoPath form that we created has been set to be “browser compatible” way back in part 2 when we first created the form template.

The first and default choice is to create the form in a SharePoint Document Library. Thus in the SharePoint world, InfoPath forms are just another type of library storage. therefore you can can use version history, recycle bin and all of the other goodies that come with SharePoint document libraries. Now I should make it clear though, that SharePoint creates a special type of library called a “Form Library”, designed specifically for InfoPath forms. So we leave “Document Library” chosen as the default and click continue on.

Having chosen to use a document library we are now asked to create a new one or choose an existing library. In our case, we have not yet created the library to hold the leave form, so we choose to “Create a new document library” and then enter it’s name and description into the follow-up dialog box. This will create a form library called “Leave Forms” for us as part of the publishing process.

The next step is another important one. But in the interests of our “impress the client at all costs” focus, we are going to leave it until the next post. So we click Next to continue.

That’s it for the publishing process! Clicking the Publish button will commence the process. InfoPath will create the form library and when it finished provide us with a summary of what has been performed as shown below. You can see the name of the library where the form was published (“Leave Forms”), the URL of the SharePoint site (http://radioactivenet/leave forms) and the fast that Infopath Forms services is running on the server.

The new form library

So, are we ready to “wow” the client yet? Almost!

Looking at the http://radioactivenet site, we can now see that we have a new content item in the navigation. Well what do you know? It’s a leave form library!!

If you navigate to this document library, you will see that it pretty much looks like any other SharePoint document library. Clicking the New drop down in the document library though shows that something is subtly different with this library. The document type to create has the InfoPath symbol on it. This library knows that it is here to store InfoPath forms.

But there is one minor catch. By default, SharePoint assumes that if you have InfoPath installed on your PC, then you will always prefer to use InfoPath in preference to a more limited, somewhat “clunkier” web based version. In our case, we want the form to show up in a browser, irrespective or whether InfoPath is installed on you PC. So let’s do that now.

In the new Leave Forms library, we choose “Form Library Settings” from the “Settings” drop down menu as shown below.

Now remember how I said that a forms library is a document library geared especially to host InfoPath forms? Well, now you get to see why. One of the configuration options unique to a forms library is whether to display a form in a browser or using InfoPath. The option controlling this can be found in “Advanced Settings” as highlighted below. The third option under advanced settings controls the behaviour for “browser enabled” documents. Note that the default option is to “Open in the client application”.

So let’s change this to “Display as a web page” and click OK. Also note the second option, “Document Template”. We will be talking about this a subsequent post as well.

The big test!

So, all is now in place and it is time to demonstrate the functionality to your eager and excited clients. Go back to the home page of http://radioactivenet and choose “Leave Forms” from the navigation bar. In the document library view, choose “New Document” from the “New” drop down.

Wohoo! The form renders in the browser! (and the crowd goes wild! )

Conclusion

So there you go, in something like 20-25 minutes, you have created and published a web based form that started life as a MSWord template. Highlighting how long this world have taken to be custom developed, your client is already writing a cheque and wants you to do this with all of their internal forms right???

Whatsmore, we haven’t even gotten to the unbridled joy that is a workflow yet! Oh man if the client likes forms services, they ain’t seen nothin’ yet right???

Well, to be honest, this form really isn’t that smart yet is it? Before we even get to workflow considerations, the form still isn’t *that* friendly and we haven’t yet satisfied several of the requirements outlined in part 1. Remember that we had to provide:

Automatic identification of requestor

Reduce data entry

Validation of dates, specifically the automatic calculation of days absent (excluding weekends)

Mr Burns is not the only approver, we will need the workflow to route the leave approval to the right supervisor

We have a central leave calendar to updateSo in the next post, we will make this form a little smarter and see if it is still within the realms of mere mortals (non developers) to do.thanks for readingPaul Culmseewww.cleverworkarounds.com