views:

1274

answers:

5

If I want to put a form up on SharePoint, is it easier to use InfoPath or build a custom web part in C#? Are there other options that I should consider?

What are the requirements and hurdles for each option?

A: 

Can you be more specific about the form and sharepoint version ?

It depends on your version of Sharepoint : if you got 2003, if you want to use InfoPath, it has to be installed on the clients as well. On SharePoint 2007, i think it is not required.

If it is a large form with few business rule, InfoPath can be the way to go -> wysiwyg, and easy deployment.

If your form involves more business rules, a web part or a page in _layouts can be "simpler" and more maintainable.

mathieu
+5  A: 

Building forms using InfoPath is absolutely the easiest way to publish a form in SharePoint. Notice it has many limitations, and you might find yourself trying to put some problematic logic or need an extra feature.

Programming in C# requires C# knowledge (of course) and a knowledge in SharePoint's APIs. Also, once completed, the resulting DLL has to be published and trusted by SharePoint, which requires the sysadmin intervention. This might not always be available to you, and might be problematic the next time you try to upgrade SharePoint.

Finally, I recommend trying to accomplish most of the stuff (including forms) simply by using SharePoint's built-in features. If you dive into it a little, you'll find out you can actually build complicated applications simply by customizing Lists' views, arranging the order of fields, adding column (and site-columns) of your own, etc. The best thing about this approach is it's pure SharePoint. No extra knowledge (and people) needed.

Moshe
A: 

Infopath is wicked at quickly building forms and throwing them up onto Sharepoint. I would expect it's 1000x faster than building a custom C# app.

Kolten
+1  A: 

Actually, you don't need much knowledge of the SharePoint APIs in order to create a custom web form. It's a very straight forward process; I don't have any links handy, but there should be more than a few "hello world" examples floating around to get you started. The trickier parts with SharePoint web parts is how to best debug and deploy them.

I know some consultants who have a full suite of virtual servers running locally on their laptops so that everything is there for them to play with. That's not an option for me; my group utilizes System.Web.UI.WebControls.WebParts.WebPart, so we can test locally before deploying to our dev environment. Please note that if you go that route, you can't fully test locally, as you'll be missing some SharePoint elements like style sheets and system-provided web parts. As far as deployment, we're still working on the details. You can manually do it, but it's not great for locked down production environments. One approach to review is "Features"; it looks promising for applying new enhancements as a single installer, although I'm not sure how you handle bug fixes for it.

pdwetz
A: 

It may deppends on the way you are thinking for

For eg, 1. you can go for Infopath, if you are trying to give the control to end user inorder to customize the form by own.

Infopath is very easy to understand, develop. In order to use the infopath you have to learn Infopath, Infopath Form Services, and Sharepoint api to integerate Dotnet (C#) and Sharepoint.

guna Samba