En mi proyecto actual, algunos de los usuarios a viajar alrededor del mundo y cuando llegan a diferentes destinos, usar cualquier máquina es útil en el momento. Esas máquinas huésped va a correr Windows e instalación y configuran para el escenario local. (Sólo me he dado cuenta de que las máquinas de huéspedes no tengan los paquetes de idioma de derecha… Probablemente no, En realidad… Aquél por ahora estacionando).

SharePoint tiene que proporcionar un mecanismo por el que el usuario puede seleccionar su idioma preferido y luego tener musgo honrar ese idioma independientemente de cómo el usuario accede a MOSS. En otras palabras, ignorar lo que diga el navegador IIS/musgo y en su lugar ver ese idioma y utilizarlo.

Vamos a investigar dos enfoques:

1. Controlador HTTP: Un controlador HTTP personalizado instalado en IIS se verá en el perfil del usuario MOSS, descifrar el lenguaje preferido y luego cambiar el encabezado HTTP alrededor según sea necesario antes de pasar el control de musgo.
2. global.asax: Modificar el global.asax para hacer lo mismo. Nosotros podemos modificar algo más, pero la idea es que encontremos un lugar donde podemos insertar nuestra lógica de conmutación de configuración regional.

El otro factor que complica es que necesitamos apoyo k 60 usuarios, acerca de 1,000 de que puede ser al mismo tiempo acceder a MOSS en pico de carga.

Parece muy drástico el controlador HTTP, pero posiblemente el mejor lugar para poner el codigo ya que es a nivel de IIS y omnisciente. Es un buen punto de individual de trabajo.

Nos estamos inclinando hacia un enfoque de tipo global.asax, principalmente porque creemos que tendremos más opciones para almacenar en caché datos en ese momento.

Voy a ser más sobre este tema de blogging como aprendo más.

Si tienes sabe algo de esto, please post a comment 🙂

</final>

Suscribirse a mi blog.

Sígueme en Twitter en http://www.twitter.com/pagalvin

Estoy en un proyecto donde tenemos que recoger métricas alrededor de una función denominada "comparten una historia." La idea es muy simple — Si usted está buscando un interesante artículo en la intranet y quiere compartir con alguien, Haga clic en un vínculo con la etiqueta de "compartir esta historia" a su amigo un correo electrónico.

Jugamos con un formulario personalizado para este propósito, pero al final, sentido común ganó el día y sólo utilizamos el familiar <a href = mailto:…> técnica. (<un mailto href:…> es un poco sorprendentemente robusto de HTML; como un bono, ese vínculo me hace volver a mis viejos tiempos de páginas man de UNIX; aquellos fueron los días!).

Esta técnica proporciona una interfaz de gran para los usuarios finales ya a utilizar a su familiar cliente MS Outlook (o cualquier cliente de correo electrónico se han instalado).

Dificulta las cosas nos tipos de pobre desarrollador ya que cliente * también * quiere ejecutar un informe en el futuro que muestra cómo a menudo los usuarios compartan historias y aún qué historias se comparten más a menudo.

Nos whiteboarded algunas posibles soluciones. Mi favorito es copia al carbón (CC) una lista de SharePoint. De esa manera, el usuario final todavía obtiene al cliente de outlook mientras llegamos a capturar el evento porque nos pondremos una copia del correo electrónico nos. Existen algunos inconvenientes obvios. El principal problema es que el usuario podría simplemente en blanco hacia fuera o de otra manera destrozar el CC dirección. Y, tenemos que gestionar ese evento biblioteca de correos electrónicos. Tenemos un trabajo programado en el tablero blanco responsable de esa limpieza.

Si tienes algún acercamiento inteligente para resolver este problema, por favor diga.

</final>

Suscribirse a mi blog.

Sígueme en Twitter en http://www.twitter.com/pagalvin