Sharepoint 定制个性化
我正在创建共享点自定义解决方案，它将在页面中显示下拉列表的数量。 下拉数据在多个页面中共享。
我想保留用户选择的值，这样当他访问该页面或具有相同下拉列表的任何其他页面时，他应该能够看到下拉列表中预先选择的保存值。
为了实现这一点，我有多种选择。 请推荐最适合 SharePoint 的方案 1)Sharepoint 用户资料 2）分享点列表 3）饼干 4）隔离存储？
这里的选项 3 和 4 是客户端。 但我正在寻找 SharePoint 提供的任何其他方式来保存用户首选项/个性化信息。
哪一种是在 SharePoint 中执行此操作的正确方法？ 谢谢
I am creating sharepoint custom solution that will show number of drop down in page. The drop down data is shared in may pages.
I want to persist selected values of the user such that when ever he visit that page or any other page that have same drop down, he should be able to see is saved value pre selected in drop down.
To implement this I have a number of options. Please suggest the best for SharePoint
1)Sharepoint User profiles
2)Sharepoint list
3) Cookie
4) Isolated storage?
Options 3 and 4 here are clientside. But I am looking for any other way that SharePoint provides to save user preferences/personalization information.
Which one is the correct way of doing that in SharePoint?
Thanks
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
对于用户配置文件，您应该注意的一个问题是它们仅适用于 MOSS（而不是 WSS）。 在WSS中，每个站点都有自己的用户信息列表。 如果您正在构建的解决方案需要在 MOSS 和 WSS 环境中运行，您应该进行相应的规划。
杰特
One issue you should be aware of with user profiles is that they are only available for MOSS (as opposed to WSS). In WSS each site has their own User information list. If the solution you are building will need to run in both MOSS and WSS environments, you should plan accordingly.
jt
我的直觉告诉我为此使用 cookie，如果这是一个相当简单的状态，则需要坚持下去。 这似乎是 UI 逻辑的一部分，我不会将其绑定到配置文件存储。
页面和 Web 部件也具有个性化存储，但它们通常不在实例之间共享。
My instinct tells me to use cookies for this, if it's a fairly simple state you need to persist. This seems to be a part of the UI logic, and I wouldn't bind that to the profile storage.
Pages and web parts have personalization stores as well, but they are generally not shared between instances.
我会选择配置文件存储，因为这就是它的用途，尽管通常当您在 SharePoint 中编写自定义代码时，最佳实践的想法会被抛到九霄云外。
I would go with profile storage, because that's the sort of thing it's there for, although generally when you are writing custom code in SharePoint the idea of best practices kind of gets thrown out the window.