Take the 2-minute tour ×
SharePoint Stack Exchange is a question and answer site for SharePoint enthusiasts. It's 100% free, no registration required.

I have a several site collections in the same web application and I need to handle events when user goes from one site collection to another. I need it for specific actions, like setting "lcid" cookie for changing default language of site and claims values to user properties mapping.

Currently I'm using custom HTTP module, which handles all PostAuthorize web application requests and checks current user and site collection, holds last visited site for each user in collection and fires a custom event for subscribers, when detects transition between site collections.

But I think this approach slows down performance of web application. And from logs I see that there are to many PostAuthorize requests even when user simply clicks a link to page in other site collection. Also, in similar cases sometimes there is a series of requests to "next" site collection, then to "previous", and then again to "next". Also there are some issues with SharePoint Designer (can't edit page) become when this module is active.

Could you give me a advice with better approaches for this task? Thanks in advance.

share|improve this question
    
just an idea (never tested): use a custom control, that you put on all page (maybe using delegate control AdditionalPageHead). In this control, you can check the Request.UrlReferrer value and handle this info. –  Steve B Sep 17 '11 at 10:10
add comment

2 Answers

Is this really important? LCID should be handled by the user profile itself (user language).

Per design page views are not tracked (audit) and the argument here are again performance. Even if you threw in a webcontrol that monitored usage, your caching strategy would be limited. You could consider setting some of the values in a cookie, or doing the check client side to avoid performance issues?

share|improve this answer
    
+1, it seems to be mere wrong direction of investigation. There are many much more native ways to get current LCID in SharePoint, than use some custom cookies for this. I think, the most correct way is to fetch it from Thread.CurrentThread object, in this case you will fit SharePoint on-fly localization. If you need it client-side, you can use, for example, L_Menu_LCID global variable. –  Andrey Markeev Sep 18 '11 at 16:19
    
I have a one site collection with large text content in one language, and a second site collection with same content in other language. Second was made by making backup of first and then restore it on other URL (path) and content was translated manually. So default language (and "lcid" cookie value) of this second site collection is still as in first. What I need is that when user comes to second site collection language must be other than default for it. User must be able to see content in many languages simply clicking on link, also UI (ribbon, menus) must be in same language as content. –  Oleg Savelyev Sep 18 '11 at 17:04
    
Couldnt you just set the LCID in the second site collection after translating it, since it is in a different path the path itself could also be used to determine language –  Anders Rask Sep 18 '11 at 17:31
    
By default "lcid" cookie value refers to site collection default language. It's changed in runtime only when user manually selects language in top-right corner control. Default site collection language can be set only on its creation. There is a dirty solution to change it directly in database, but sometimes it causes errors. Of course I can use JavaScript in master pages to change "lcid" cookie value. –  Oleg Savelyev Sep 18 '11 at 17:43
add comment

As a general approach (Answering your question about when a user navigates to new page a different site collection within the same web application)...

  1. Create a new control that checks SPContext.Current.Site.ID when it loads, and stores the current site ID in session state or cache. If the previously stored siteID guid does not match the current guid, you know they've navigated to another site collection. You can ignore Postbacks.
  2. Create a feature that provisions the new control as a delegate using the AdditionalPageHead control Id, scoped at the Web Application level. That way all master pages which (should) include that control Id will load the control and run your code.

IMHO, this would be a better approach than using an http module, which is really a solution of last resort.

share|improve this answer
    
Just noticed someone else had actually suggested the same thing in a comment on the question. I will add that I have actually used the approach before and it does work. –  Jon Lester Sep 23 '11 at 13:11
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.