我不确定我的问题是否会有明确的答案，但我想阅读其他人对此的一些讨论......这里有一些快速的背景知识。
我正在创建一个请求表单，用于向我们的数据中心添加新设备。 我正在收集一些有关提交者和要添加的设备的非常基本的信息。 有些元数据变得非常复杂，但我不会在这里讨论。
首先，我从支持浏览器的 InfoPath 表单开始，因为我们的大多数用户都没有获得 InfoPath 富客户端的许可。 经过多次挫折后，我的工作开始顺利进行，但始终无法达到令我满意的表现水平。 从那时起，我一直在使用 SharePoint 的 Web 服务，并且我有一个用 HTML（带有一些 jQuery 魔法）编写的很棒的表单，可以提交到 SharePoint 列表。
所以现在我问自己...为什么不直接使用这个表格呢？ 首先，我可以完全摆脱 InfoPath...这也有助于我们获得许可，因为我不需要企业许可。 第二，性能……第三，当然我必须手动编码，但我可以，而且我喜欢它。
因此，InfoPath 已经被淘汰了。
这导致我需要将一些最佳实践想法与新想法相结合。 我的这个表单效果很好，但我希望一切都可以在 SharePoint 中运行。 作为测试，我刚刚为我的列表创建了一个新视图，删除了显示列表的 Web 部件，然后放入我的表单中。 除了一些 CSS 问题之外，一切正常，并且列表更新速度快如闪电！
但它应该是自定义视图吗？ 它应该住在其他地方吗？ 我应该只编辑 NewForm.aspx 吗？
我很想听听对此的一些想法。 最终，我的整个解决方案将作为一项功能进行部署，但我不确定这是否相关。
谢谢！！
I'm not sure that there will be a definitive answer to my question, but I'd like to read some discussion from other folks on this... here's some quick background.
I'm creating a request form that will handle adding new equipment to our datacenter. I'm collecting some pretty basic info about the submitter and the equipment to add. Some of the metadata gets pretty complex, but I won't get into that here.
At first I started with a browser enabled InfoPath form, because most of our users aren't licensed for the InfoPath rich client. After much frustration I got things working, but could never get a level of performance that I was happy with. Since then I have been playing around with SharePoint's web services and I have a GREAT form that I've written in HTML (with some jQuery magic) that submits to a SharePoint list.
So now I'm asking myself... why not just use this form? First, I can get rid of InfoPath completely... that also helps us out with licensing since I won't need Enterprise licensing. Second, performance... Third, sure I have to hand code it, but I can, and I enjoy it.
So, InfoPath is out the door.
That leads to where I need some best practice ideas mixed in with new ideas. I've got this form that works great, but I want everything to work within SharePoint. As a test, I just created a new view for my list, removed the web part that shows the list, and plopped in my form. Aside from some CSS issues, everything works and it updates the list lightning quick!
But should it be a custom view? Should it live somewhere else? Should I just edit NewForm.aspx?
I'd love to hear some thoughts on this. Ultimately, my entire solution will be deployed as a Feature, but I'm not sure that's relevant.
Thanks!!
发布评论
评论（3）
我会以大致相同的方式完成它：
如果您必须修改 NewForm.aspx，不要删除默认的 ListForm Web 部件，因为 SharePoint 将其用于其他用途。 您最好将其隐藏起来以避免将来出现问题。
希望有帮助
I would've done it mostly the same way:
If you must modify NewForm.aspx, don't delete the default ListForm Webpart since it's used by SharePoint for other things. You're better of just hiding it to avoid future issues.
Hope that helps
我认为您应该为您的请求 SharePoint-List 创建自定义表单模板。
请参阅MSDN：创建自定义表单模板。
我还建议阅读了解 SharePoint：列表表单 。
I think you should create custom form templates for your request SharePoint-List.
See MSDN: Creating Custom Form Templates.
I also recommend reading Understanding SharePoint: List Forms.
使用自定义表单或完全独立的应用程序来编辑 SharePoint 数据没有任何问题。 您最终会得到与使用标准新表单相同的数据，因此它不可能破坏修改后的视图之外的任何内容。
设置自定义新表单可能是最合适的地方 - 很容易更改 schema.xml 中的新表单 url 或通过设计器。
There's nothing wrong with using a custom form or a completely seperate app to edit SharePoint data. You end up with the same data you would get from using the standard new form, so it can't possibly break anything beyond the modified view.
Setting up a custom newform is probably the most appropriate place for it - easy enough to change the newform url in schema.xml or through designer.