Forms in SharePoint

Question

If I want to host a form in SharePoint, is it easier to use InfoPath or create a custom web part in C #? Are there any other options I should consider?

What are the requirements and obstacles for each option?

Answer 1

Forming using InfoPath is the easiest way to publish a form to SharePoint. Please note that it has many limitations, and you can try to put some kind of problematic logic or require an additional function.

C # programming requires knowledge of C # (of course) and knowledge of the SharePoint API. In addition, upon completion, the DLL must be published and trusted by SharePoint, which requires sysadmin intervention. This may not always be available to you, and there may be a problem the next time you upgrade SharePoint.

Finally, I recommend that you try to complete most of the material (including forms) simply by using the built-in features of SharePoint. If you immerse yourself in this a bit, you will find that you can create complex applications by simply customizing the list views, arranging the order of the fields, adding columns (and site columns), etc. The best thing about this approach is pure SharePoint. No additional knowledge (and people) is required.

Answer 2

In fact, you don’t need a lot of knowledge about the SharePoint APIs to create a custom web form. This is a very direct process; I have no links, but there should be more than a few hello world examples floating around to get you started. The more complex parts with SharePoint web parts are how to better debug and deploy them.

I know some consultants who have a complete set of virtual servers running locally on their laptops, so that everything is for them. This is not an option for me; my group uses System.Web.UI.WebControls.WebParts.WebPart, so we can test locally before deploying to our dev environment. Please note: if you go along this route, you cannot fully test locally, as you will not be able to find some SharePoint elements, such as stylesheets and web parts provided by the system. As for deployment, we are still working on the details. You can do this manually, but it is not very convenient for locked production environments. One approach to the review is “Features”; it looks promising to apply new enhancements as a single installer, although I'm not sure how you deal with bug fixes for it.

Answer 3

Can you clarify the form and version of sharepoint?

It depends on your version of Sharepoint: if you received 2003, if you want to use InfoPath, it must also be installed on clients. In SharePoint 2007, I don’t need to think .

If this is a large form with a small business rule, InfoPath can become a way -> wysiwyg and easy deployment.

If your form includes more business rules, the web part or page in _layouts may be “simpler” and more convenient to maintain.

Answer 4

Infopath is unholy when you quickly create forms and drop them on Sharepoint. I would expect this to be 1000 times faster than creating a custom C # application.

Answer 5

It may depend on how you think about

For example, 1. you can go to Infopath if you try to give control to the end user inorder to customize the form yourself.

Infopath is very easy to understand, develop. To use infopat, you need to study Infopath, Infopath Form Services and Sharepoint api for integrating Dotnet (C #) and Sharepoint.