MOSS 用户配置文件为用户的语言首选项的监督

我的当前项目, 有些用户将旅行世界各地和他们得出不同的目的地, 使用任何机器时派上用场. 那些客人机器将运行 Windows 安装和配置为本地语言环境. (我只被意识的来宾机器可能没有正确的语言包… 很可能不会, 事实上… 我停车,现在的人).

SharePoint 需要提供一种机制,藉以用户能够选择他们的首选的语言,然后荣誉那语言无论用户如何访问苔藓青苔. 换句话说, 无视无论浏览器会告诉 IIS/苔藓和相反查找该首选语言和使用它.

我们要去调查两种方法:

  1. HTTP 处理程序: 在 IIS 上安装自定义 HTTP 处理程序将查找用户的 MOSS 配置文件, 找出的首选语言,然后交换机周围所需的 HTTP 标头之前将控制传递给苔藓.
  2. global.asax: 修改 global.asax 来做同样的事情. 我们可能会修改别的东西, 但这个想法是,我们找到一些我们可以在其中插入我们区域设置开关的逻辑的地方.

其他复杂的因素是我们需要支持 60 k 用户, 关于 1,000 ,可能在同时访问 MOSS 在峰值负载.

HTTP 处理程序看起来蛮厉害, 但可能是最好的地方,要放入的代码,因为它是在 IIS 级别和全知. 它是工作的好的单点.

我们倾向于 global.asax 类型方法, 主要是因为我们相信我们会有更多的选项,用于在该点缓存数据.

我学了更会更多关于这个主题的博客.

如果你知道这件事, please post a comment 🙂

</结束>

订阅我的博客.

跟我在 Twitter 上 http://www.twitter.com/pagalvin

4 上“的想法MOSS 用户配置文件为用户的语言首选项的监督

  1. 亚普 · Vossers

    我没有测试这个所以我不确定是否能正常工作.

    页类有 InitializeCulture() 可重写的方法. 如果您自定义的 masterpage 后面的代码中这样做, 我们能做些大意:

    重写受保护失效 InitializeCulture()
    {
    // 重写虚方法 InitializeCulture() 检查是否配置文件包含用户的语言设置
    字符串 UserCulture = GetCultureFromUserProfile();
    如果 ( UserCulture != "")
    {
    // 是在配置文件中的用户语言设置: 切换到它
    Thread.CurrentThread.CurrentUICulture = 新 CultureInfo(UserCulture);
    Thread.CurrentThread.CurrentCulture = CultureInfo.CreateSpecificCulture(UserCulture);
    }
    }

    很明显,您可以生成一些缓存到此方法的实现.

    源: http://quickstarts.asp.net/QuickStartv20/util/srcview.aspx?path=~/aspnet/samples/localization/LocalizePers.src&文件 = LocalizePers_cs\LocalizePers_cs.aspx&lang = C # 源

    答复
  2. 乔纳森 ·

    我想用以下流的 HTTP 处理程序:

    1. 请求进来, 检查 cookie 的会话 cookie 的语言首选项 (会话 cookie 过期时关闭浏览器)
    2. 检查是否请求是针对 ASPX 页, 如果不是, 跳过的请求
    3. 如果 cookie 存在, 将语言标头设置为指定的值. 完!
    4. 没有 cookie, 身份验证凭据,用户查找在 SPS, 找到语言首选项
    5. 设置 cookie 标题和语言的 HTTP 标头. 做.

    APX 的第一个页面请求将有 SPS 查找的开销,但从那时起与每个请求都没有查找,所以将本机的速度. 不需要会话缓存或任何其他开销通过使用会话 cookie 太. 一旦关闭浏览器, 会话 cookie 就会消失. 如果用户在更改其语言偏好的 SPS 他们只需要关闭并重新打开浏览器才会生效.

    答复
  3. 沉淀

    事实上,http 处理程序不是 iis 一级…它是在应用程序级别 (ISAPI 筛选器是在 IIS 一级)…我会小心的不列颠哥伦比亚省 SP 有它自己的处理程序…所以一定要测试出来…以前做,但有一些冲突与 SP 处理程序.

    答复
  4. 丹尼尔

    我会更倾向于使用 HTTPHandler, 唯一原因是我不喜欢触摸的 SharePoint 文件. 再加上很容易地创建一个 SharePoint 解决方案部署 HttHandler ( 和使用 SPWebConfig API 来修改 web.config). 有的用户负载你做, 我能想象你有一个相当大的农场, 你真的不想走在每个服务器上的 modifiying 文件.
    部署 global.asa 文件通过一个解决方案是一个糟糕的主意, 如果您取消它, 您的原始文件是不见了 …
    也有能力迅速收回解决方案可能会是个好主意, 万一事情出了问题与处理程序的性能.

    答复

留言

您的电子邮件地址不会被公开. 必需的地方已做标记 *