Op my huidige projek, sommige van die gebruikers sal reis regoor die wêreld, en wanneer hulle kom op verskillende bestemmings, use whatever machine is handy at the time. Those guest machines will be running Windows and installed and configured for the local locale. (Ek het net besef dat die gaste masjiene nie kan het die reg om taal pakkette… sal waarskynlik nie, in werklikheid… Ek parkeer dat 'n mens vir nou).
SharePoint needs to provide a mechanism whereby the user can pick their preferred language and then have MOSS honor that language regardless of how the user accesses MOSS. In other words, disregard whatever the browser tells IIS/MOSS and instead look up that preferred language and use it.
Ons gaan twee benaderings te ondersoek:
- HTTP Handler: 'N persoonlike HTTP hanteerder geïnstalleer op IIS sal kyk op die gebruiker se mos profiel, die taal van voorkeur en dan skakel die HTTP-kop rond soos nodig voordat beheer te MOSS.
- Global.asax: Modify global.asax to do the same thing. We may modify something else, but the idea is that we find some place where we can insert our locale-switching logic.
Die ander kompliserende faktor is dat ons moet 60k gebruikers te ondersteun, oor 1,000 wat gelyktydig toegang tot spitslas word mos.
Die HTTP-hanteerder lyk redelik drastiese, but possibly the best place to put the code since it’s at the IIS level and all-knowing. It’s a good single point of work.
Ons leun na 'n Global.asax tipe benadering, hoofsaaklik omdat ons glo dat ons meer opsies vir die kas van data sal op daardie stadium.
Ek sal blog meer oor hierdie onderwerp as ek meer inligting.
As jy weet niks oor hierdie, please post a comment 🙂
</einde>
Volg my op Twitter http://www.twitter.com/pagalvin
Ek het dit nie getoets is nie, so ek is nie seker of dit werk.
Die bladsy klas het 'n InitializeCulture() metode wat kan apart. As jy dit doen in die kode van jou persoonlike masterpage agter, jy kan doen om iets langs die lyne van:
beskerm ignoreer nietig InitializeCulture()
{
// oorheers virtuele metode InitializeCulture() om te kyk of profiel bevat 'n gebruiker taal instelling
string UserCulture = GetCultureFromUserProfile();
indien ( UserCulture != "")
{
// daar is 'n gebruiker taal instelling in die profiel: oorskakel na
Thread.CurrentThread.CurrentUICulture = nuwe Culture(UserCulture);
Thread.CurrentThread.CurrentCulture = CultureInfo.CreateSpecificCulture(UserCulture);
}
}
Jy kan natuurlik 'n caching bou in die implementering van hierdie metode.
Bron: http://quickstarts.asp.net/QuickStartv20/util/srcview.aspx?path = ~ / Aspnet / monsters / lokalisering / LocalizePers.src&file = LocalizePers_cs\LocalizePers_cs.aspx&lang = C% 23 bron
Ek dink die HTTP hanteerder met die volgende vloei:
1. Versoek kom in, gaan koekies vir 'n sessie koekie vir taalvoorkeur (session cookies verval wanneer die leser word gesluit)
2. Gaan na indien versoek is vir ASPX bladsy is, indien nie, slaan versoek
3. As koekie bestaan, stel die taal kop aan die waarde wat gespesifiseer. Jy is klaar!
4. Geen koekie, neem die verifikasie Bewyse en kyk die gebruiker in SPS, vind taalvoorkeur
5. Stel koekie kop en HTTP taal kop. Gedoen.
Eerste APX bladsy versoek sal die oorhoofse van SPS lookup maar elke versoek van dan op met het geen soektogte inheemse spoed sal wees. Geen behoefte vir session cache of enige ander oorhoofse deur gebruik te maak van 'n sessie koekie te. Sodra die leser word gesluit, Die sessie koekie gaan weg. As die gebruiker verander hulle tale voorkeur in SPS hulle net nodig het om te sluit en heropen die leser om dit in werking tree.
eintlik die http-hanteerder is nie op die IIS-vlak…dit is by die aansoek vlak (ISAPI filters word by die IIS-vlak)…Ek sou wees versigtig bc SP het sy eie hanteerder…so seker wees om dit uit te toets…Ek het dit gedoen voor, maar het 'n paar konflik met die SP hanteerder.
Ek sal meer geneig wees om 'n HTTPHandler te gebruik, die enigste rede is dat ek nie graag aan die SharePoint lêers. Plus dit is maklik om 'n SharePoint oplossing te skep 'n HttHandler te ontplooi ( en gebruik die SPWebConfig API is die Web.config te verander). Met die gebruiker vrag wat jy doen, Ek sou dink jy het 'n aansienlike plaas, jy wil regtig nie modifiying lêers om te gaan op elke bediener.
Die implementering van die lêer Global.asa via 'n oplossing is 'n slegte idee, As jy dit trek, jou oorspronklike lêer is weg …
Ook die vermoë om die oplossing te trek vinnig 'n goeie idee wees, in die geval dinge verkeerd gaan met die perf van die hanteerder.