Really Annoying session variables!



  • <font size="3">Morning all.</font>

    <font size="3"> </font>

    <font size="3">First Ill start with a bit of detail about my problem:</font>

    <font size="3">I have a web page which is viewable in 4 languages and shows different products depending on what country you are in.</font>

    <font size="3">Your country is determined by you when you first get to the site there is a home page which you select your country on, this then sets a session variable (countryID) and redirects you to the first proper page. This all works and has done for over a year with no problems.</font>

    <font size="3"> </font>

    <font size="3">The issue now is that the client has requested functionality so that when you carry out a search for a product, if it is not available in the country that you are currently viewing a message comes up saying:</font>

    <font size="3">“Sorry no products could be found for [country name], however products have been located in the following locations…” You are then presented with a link that takes you to the search results pages for the country that has the products that you searched for.</font>

    <font size="3">It does this by doing the following:</font>

    <font size="3">1.</font>      <font size="3">Create a new session variable called PrevCountryID and set it to the current countryID</font>

    <font size="3">2.</font>      <font size="3">Change the current countryID (Session Var) to be the countryID of the country where the products are located.</font>

    <font size="3">3.</font>      <font size="3">Redirect you to search results.aspx.</font>

    <font size="3"> </font>

    <font size="3">You are then presented with the search results and you are browsing the (for example) Spanish site.</font>

    <font size="3"> </font>

    <font size="3">This is all fine.</font>

    <font size="3"> </font>

    <font size="3">The problem comes when the user does the following: Clicks the  Back button.</font>

    <font size="3"> </font>

    <font size="3">As the previous page is cached the browser does not post back to the server so although the page that they are on has all of the (for example) UK branding the session variable is still set to spain (For example). This results in the next link that the user click on to redirect them to the Spanish site again…</font>

    <font size="3"> </font>

    <font size="3">There is code on the home page and the search page so that if you land on them and your previous country is not null and not == current country id your current country ID is reset to match your previous countryID, This works but only if you refresh the page after pressing back (to force a post back to the server)</font>

    <font size="3"> </font>

    <font size="3">I am pulling my hair out over this one, I have tried using ajax to trigger a server side event when the page loads – at first I thought that this was all working great, then realised that the method that is invoked by the ajax call cannot access the session variables for the user…</font>

    <font size="3"> </font>

    <font size="3">HELP!!!</font>



  • Best thing IMHO would be not to mess with the session variable, but allow it to be overridden by a query string parameter.  So, for example, if you want to give the user a link to search in a different country, use something like

    http://www.example.com/results.aspx?query=...&country=elbonia
    and in the code, do something like (pseudo-code, I'm not familiar with ASP.NET)
    String country = Request.HasKey("country") ? Request.Get("country") : Session.Get("country");

     



  • I'm with iwpg. Keep the requested country in the link parameters or hidden form fields and use the session variable for the default settings only. Especially when switching from English to Spanish. Avoid setting a session variable to "now I'm Spanish".



  • [quote user="iwpg"] Best thing IMHO would be not to mess with the session variable, but allow it to be overridden by a query string parameter.[/quote]

    Forgot to mention: if you do use this method, make sure you sanitise the input value, to prevent XSS attacks and SQL injection.  The rest of the code probably assumes it's valid, since the user can't mess with it directly, so the easiest thing would be to check once and just use the session value if the query string one isn't valid.



  • [quote user="devy"]<font size="3">
    </font>

    <font size="3">The issue now is that the client has requested functionality so that when you carry out a search for a product, if it is not available in the country that you are currently viewing a message comes up saying:</font>

    <font size="3">“Sorry no products could be found for [country name], however products have been located in the following locations…” You are then presented with a link that takes you to the search results pages for the country that has the products that you searched for.</font>

    <font size="3">It does this by doing the following:</font>

    <font size="3">1.</font>      <font size="3">Create a new session variable called PrevCountryID and set it to the current countryID</font>

    <font size="3">2.</font>      <font size="3">Change the current countryID (Session Var) to be the countryID of the country where the products are located.</font>

    <font size="3">3.</font>      <font size="3">Redirect you to search results.aspx.</font>

    <font size="3"> </font>

    <font size="3">You are then presented with the search results and you are browsing the (for example) Spanish site.</font>

    [/quote]

     I'm not sure what the exact requirements are, but could you just use a user-defined flag that determines whether the search includes all countries or not?  If it were up to me, I'd put an checkbox on the search page like "Restrict results to %HomeCountry%" and have it defaulted to true/checked.  If the user does a restricted search and there are products in other countries that do match, present the user with a message similiar to the proposed message.  If they select yes, uncheck the flag and show all the results.  You can also flag/segregate the products if they are not in the selected home country if that means something (longer lead time, increased shipping, etc). 
     

    To me that seems a whole lot cleaner than swapping country session variables and/or conditionally checking URL query strings and session variables. 



  •  

    I also think that you are approching this problem entirely the wrong way. I see two easy solutions to this:

     1) Split up the session variable rather than trying to encode more information in it that you should.

    CountryID should have the locale of the current user, and it shouldn't change. You wouldn't want to display the additional results with a  Spanish user interface, right? That would be a wtf.
     SearchCountries should have information that tells you which product listings to search. I would allow either a single country, or a value to signify results from 'all' stores should be returned. If you want to get fancy, you could also permit multiple countries (i.e. EN;ES;DE) but there's really nothing gained from doing that.

     With this in place, all you need to do is set the second variable to =all, and reload. Add a button that, on presence of the variable, lets the user limit search to only their country. (Or, as previously already suggested, a dropdown box /checkbox or something)

     

    2) Always return the full results. Leverage dynamic layouts to enhance bussiness data flow and customer satisfaction while integrating the eCommerce more tightly with the target group. Err, I mean.

     Return the results on the search page. Add a second container with the style set to "display: none;" so it's not visible on the page. Now replace your button to 'search all stores' with javascript to grab the container and set the display back to inline/block/whatever. Ta-da, instantly showing up results.

    The cost for that would be transmitting the results every time. If the results need to be split up across several pages, then this might not work well or at all. If you always display results on a single page, then it's perfect.
     



  • [quote user="Nandurius"]

     

    I also think that you are approching this problem entirely the wrong way. I see two easy solutions to this:

     1) Split up the session variable rather than trying to encode more information in it that you should.

    CountryID should have the locale of the current user, and it shouldn't change. You wouldn't want to display the additional results with a  Spanish user interface, right? That would be a wtf.

    [/quote]

    Nope the requirement is that the user search is executed on the selected country first, then on all other countries so you get search results like ebay:

    We found 15 products matching your search criteria in th UK,
    We also found similar products in the following countries: Spain (5), France (2) etc...

    The user can then click on the spanish link to see the products that are avaliable in spain, they can then order these products and pay additional carriage if they want to.

    [quote user="Nandurius"] 

    2) Always return the full results. Leverage dynamic layouts to enhance bussiness data flow and customer satisfaction while integrating the eCommerce more tightly with the target group. Err, I mean.

    [/quote]

    Yup - thats what is happening - but if you view a spanish product you get the spanish interface - that's what the client wanted.

    This is all sorted now, more or less.

     



  • but if you view a spanish product you get the spanish interface - that's what the client wanted.

    Someone on your team advised against this, I hope? Because that's a very silly requirement, if people from country Y need to see products form country X.

     



  • I'm kinda just shooting from the hip here, so if this ends up being more WTF-y than I realize, I'm sorry:

     

    I might have a second Session variable named something like TempCountryID.  When a user decides to view results in a different country, set TempCountryID to that country's ID.  Then, on any given page, when you are deciding which country's interface to show, look at the the TempCountryID variable.  If it's null, then use the CountryID.  If TempCountryID is not null, then use it instead, and then immediately clear it.  This way when the user clicks the back button it won't matter that a postback doesn't occur, because the TempCountryID variable as already been cleared and won't be used on any other pages, unless the user performs some action that sets it again.

     

    Of course, this won't work if you want the user to able click around and continue browsing the site with the interface corresponding to TempCountryID after displaying the initial results, because the TempCountryID variable gets cleared immediately.

     

    I also agree that displaying the "other country" results in the interface for that "other country" is kind of a WTF.  If I'm from 'merica and y'all's US store doesn't have the thingy-ma-bob I'm looking for, but your store in Spain does, I want to be able to buy it from your store in Spain without being required to learn how to read Spanish first.  But as I am slowly beginning to realize, client requirements don't often intersect with common sense.



  • Well, I'm afraid the whole thing is a big wtf. From the initial solution to this whole thread it just seems wrong.


Log in to reply