על הפרוייקט הנוכחי שלי, חלק מהמשתמשים ייסעו ברחבי העולם, כאשר הם מגיעים ליעדים שונים, השתמש המכונה שיהיה שימושי בזמנו. המכונות האלו חוות לפעול Windows ו מותקן ותצורתו נקבעת עבור האזור המקומי. (פשוט הבנתי כי המכונות חוות ייתכן שאין לך את ערכות השפה הנכון… כנראה לא, למעשה… אני מחנה את זה עכשיו).
SharePoint צריכה לספק מנגנון לפיו המשתמש יכול לבחור את השפה המועדפת שלהם ויש לכבד אותה שפה ללא קשר איך המשתמש ניגש מוס מוס. במילים אחרות, להתעלם כל מה הדפדפן אומר IIS/מוס, במקום לחפש את השפה המועדפת ולהשתמש בו.
אנחנו הולכים לחקור את שתי הגישות:
- המטפל HTTP: עוזר HTTP מותאמות אישית מותקן IIS יחפש במילון פרופיל המשתמש מוס, להבין את השפה המועדפת עליך ולאחר מכן לעבור כותרת ה-HTTP מסביב לפי הצורך לפני העברת השליטה מוס.
- global. asax: לשנות global. asax לעשות את אותו הדבר. אנו עשויים לשנות משהו אחר, אבל הרעיון הוא למצוא מקום איפה שנוכל להכניס את ההיגיון מיתוג האזור שלנו.
מסבכים הינם הגורם השני הוא שאנחנו צריכות תמיכה 60 אלף משתמשים, אודות 1,000 אשר עשוי להיות בעת ובעונה אחת לגשת מוס בשיא לטעון.
המטפל HTTP נראה דרסטי למדי, אבל אולי המקום הטוב ביותר כדי לשים את הקוד מהיותו IIS ברמה, היודע-כל. . זה נקודה אחת טובה של עבודה.
אנו נוטים לכיוון הגישה סוג של global. asax, בעיקר כי אנחנו מאמינים יהיו לנו יותר אפשרויות עבור אחסון במטמון נתונים בנקודה זו.
אני אהיה לבלוגים יותר בנושא זה כמו ללמוד יותר.
אם יש לך מושג מה זה, אנא פרסם תגובה 🙂
</קצה>
עקוב אחרי הטוויטר ב http://www.twitter.com/pagalvin
לא בדקנו את זה אז אני לא בטוחה אם זה עובד.
המחלקה דף יש של 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 % 23 מקור
אני חושב HTTP המטפל עם הזרם הבאים:
1. בקשה נכנסת, לבדוק את קבצי ה-cookie עבור קובץ cookie הפעלה עבור העדפות שפה (קוקיות לפוג כאשר הדפדפן סגור)
2. בדוק אם הבקשה היא על דף ASPX, אם לא, דלג על פי בקשה
3. אם קיים קובץ cookie, להגדיר את כותרת שפה לערך שצוין. אתה סיימת!
4. . אין עוגיה, . קח את אישור האימות ולחפש המשתמש ב- SPS, למצוא את העדפות שפה
5. קוקי הגדרת כותרת וכותרת שפה HTTP. עשיתי.
בקשה ראשונה של דף APX התקורה של בדיקת מידע SPS אבל כל בקשה מכאן ואילך עם יש אין בדיקות כך תהיה מהירות הילידים. אין צורך ממטמון ההפעלות או כל הוצאות אחרות באמצעות קובץ cookie הפעלה גם. ברגע שהדפדפן נסגר, העוגייה הפעלה נעלם. אם המשתמש משנה את העדפותיהם שפות ב- SPS הם רק צריכים לסגור ולפתוח מחדש את הדפדפן בשביל זה ייכנסו לתוקף.
למעשה המטפל http לא ברמה של iis…. זה ברמת היישום (מסנני ISAPI הם ברמה של IIS)…הייתי נזהר שלפנה ס SP יש משלו הנדלר…כדי להיות בטוח כדי לבדוק את זה החוצה…עשו זאת בעבר. אבל היו איזה סכסוך עם המטפל SP.
אני אהיה יותר נוטה להשתמש HTTPHandler, הסיבה היחידה היא שאני. לא אוהב לגעת את הקבצים של SharePoint. בנוסף זה קל ליצור פתרון SharePoint כדי לפרוס את HttHandler ( והשתמש של API של SPWebConfig כדי לשנות את web. config). אתה עובר את העומס המשתמש לעשות, אני מתארת לעצמי שיש לך חווה גדול למדי, אתה ממש לא רוצה ללכת modifiying קבצים בכל שרת.
פריסת הקובץ global. asa דרך פתרון זה רעיון רע, אם שתחזור בך, הקובץ המקורי נעלם …
גם בעל היכולת. משכי את הפתרון במהירות יכול להיות רעיון טוב, במקרה הדברים להשתבש עם perf של המטפל.