SharePoint中的表单

Question

如果我想在SharePoint上添加表单，是否更容易使用InfoPath或在C＃中构建自定义Web部件？还有其他选择我应该考虑吗？

每个选项有哪些要求和障碍？

Answer 1

使用InfoPath构建表单绝对是在SharePoint中发布表单的最简单方法。请注意，它有许多限制，您可能会发现自己试图设置一些有问题的逻辑或需要一个额外的功能。

C＃编程需要C＃知识（当然）和SharePoint API的知识。此外，完成后，SharePoint必须发布并信任生成的DLL，这需要sysadmin干预。这可能并不总是可用，并且下次尝试升级SharePoint时可能会出现问题。

最后，我建议只使用SharePoint的内置功能来尝试完成大部分内容（包括表单）。如果你稍微深入一点，你会发现你实际上可以通过自定义列表的视图，排列字段的顺序，添加自己的列（和站点列）等来实际构建复杂的应用程序。最好的事情是这种方法是纯粹的SharePoint。不需要额外的知识（和人）。

Answer 2

实际上，您不需要太多的SharePoint API知识就可以创建自定义Web表单。这是一个非常直接的过程;我没有任何方便的链接，但应该有不止一些“hello world”。浮动的例子让你开始。 SharePoint Web部件的棘手部分是如何最好地调试和部署它们。

我认识一些顾问，他们的笔记本电脑上有一整套虚拟服务器在本地运行，所以他们可以随时随地使用。那对我来说不是一个选择;我的小组使用System.Web.UI.WebControls.WebParts.WebPart，因此我们可以在部署到我们的开发环境之前进行本地测试。请注意，如果你走这条路线，就无法在本地进行全面测试，因为你会遗漏一些SharePoint元素，如样式表和系统提供的Web部件。就部署而言，我们仍在研究细节。您可以手动执行此操作，但对于锁定的生产环境而言并不是很好。一种审查方法是“特征”;将新增强功能应用为单个安装程序看起来很有希望，虽然我不确定如何处理它的错误修复。

Answer 3

您能更具体地了解表单和共享点版本吗？

这取决于你的Sharepoint版本：如果你有2003，如果你想使用InfoPath，它也必须安装在客户端上。在SharePoint 2007上，我认为不需要它。

如果它是一个业务规则很少的大型表单，那么InfoPath就可以了 - ＆gt; wysiwyg，易于部署。

如果您的表单涉及更多业务规则，则_layouts中的Web部件或页面可以“更简单”。并且更易于维护。

Answer 4

Infopath对快速构建表单并将它们扔到Sharepoint上是邪恶的。 我希望它比构建自定义C＃应用程序快1000倍。

Answer 5

它可能取决于你想要的方式

例如，  1.如果您试图将控制权交给最终用户以便自己定制表单，您可以选择Infopath。

Infopath很容易理解，发展。为了使用infopath，您必须学习Infopath，Infopath表单服务和Sharepoint api以整合Dotnet（C＃）和Sharepoint。