Geeks With Blogs

News





The SharePoint Hillbilly Fewer Big Words... More Pretty Pictures...

Have you ever come up with an idea and you think “Wow.. this is either brilliant or a total hack that no one under any circumstances should consider!"?

That’s the situation I find myself in today. I either did something so monumentally stupid that Eric Shupps and Andrew Connell would love nothing more than slap me upside the head (which they probably want to do anyway) or it wasn’t totally stupid and you’ll think “Hey… that’s not a bad idea.”.

So… which is it? Well… allow me to explain the situation to you.

The Situation

We are in the process of developing a fairly involved Silverlight application for our current project.  This is an interactive application with animation and links that load different SharePoint pages. It’s pretty fancy and LARGE. I won’t even tell you how large it is because you will do a spit take and ruin your fancy computer. The links in this interactive Silverlight application take users to different SharePoint pages with the content they are seeking.  Overall, nothing complicated technically.

Anyway, because of the size and scope of the application we needed to create a “non” Silverlight version for users to access.  Another requirement was that we give the users the ability to switch between Silverlight and non Silverlight as needed.  Again, this is not a big deal, we created a few pages that were basically image maps that took the users to the correct SharePoint pages just like the Silverlight Application did.

Are you following me so far? Well… here’s the problem.  What happens if the user selects the non Silverlight version, clicks on the image map, goes to a SharePoint page and then clicks a link in the SharePoint page to go back to the non Silverlight application? It doesn’t sound like an issue on the face of it… but take a look at the following flow chart and maybe you can see where some confusion comes in:

image

You start to see the problem? There are links on the SharePoint Pages that take the user back to the “Main” application which is either a page with Silverlight or a page with an Image map.  How do you send the user to the correct place all the time?

You might be thinking the same thing we were? Cookie sand Javascript! Just set a cookie so that you know if the user is wanting Silverlight or not and then write Javascript to redirect based on the cookie. This works, and @cwheeler76 did a good job implementing this, but it starts to get kind of hairy to maintain, and what do you do if a user doesn’t have cookies or Javascript enabled? It just didn’t seem like an ideal solution to me. 

So… what did you do?

So… I had a random thought.. not quite an epiphany… The problem is you need to know at any point in the entire web application if the user is wanting to use the Silverlight or Non Silverlight version and then take that user back to the right page.

Part 1 – Determine if user wants to use Silverlight or Non Silverlight

So.. this is where the hare brained scheme comes in.  When you extend a Web Application you get another IIS Web site (a different URL) but expose the same content to your users. Historically you extend a web application if you want to set up another authentication zone for your users (Some users log in with AD and other log in with FBA for example).  However, you CAN use the same authentication on both.  So, what does extending a web application do for me here??  If I extend our web application and get a new URL I can then use one URL for the “Silverlight” version and another URL for the “Non Silverlight” version and I’ll always know which version a user is using.  You may be thinking that is a lot of overkill, but think about this.  All your links on your SharePoint page are (or at least should be) relative links. This means that regardless of whether you are using the Silverlight or Non-Silverlight version your navigation won’t have to change at all for navigating around, and you will ALWAYS know if a user should be using the Silverlight or non Silverlight version without worrying about cookies or session variables or anything else that might time out on you.

So, now I know if a user is using the “Silverlight” version or “Non Silverlight” version at all times based on their url.  Following me so far?

Part 2 – Redirect users correctly

So, your first thought may be.. “So what! I still have to check that URL everywhere and determine if I need to send the user to the Silverlight page or non Silverlight page! That’s just as much work!. Plus! How in the world do I handle the navigation menu and the bread crumb? This is just a stupid idea you have going here”.

Well..  you might have a point. It may be a stupid idea, but I had another simple solution. A super simple custom web part. We set up the default page for the web application to be the Silverlight Page. I then created a simple web part that looks at the URL (SPContext.Current.Web.Url) and checks if the URL is the URL that we indicate as the “Non Silverlight” URL. If it IS that URL I redirect the user to the non Silverlight page, and everything works from there!  And since the redirect happens on the server side there is no noticeable lag to the users and it doesn’t rely on Javascript. So… basically the flow looks like this:

image

Does that make sense at all? It is 6pm on Friday… my brain is already checked out for the weekend. If a user is using the Silverlight URL then the page loads normally and when they go back to the Default page from a SharePoint page the Silverlight works normally.  However, if a user is using the Non Silverlight URL the default page will automatically direct them to the Non silverlight page, and any time they navigate away from the SharePoint page back to the default page (via links, breadcrumbs, navigation, or even the “back” button) they will automatically get redirected to the Non Silverlight page from that default page.

Conclusion

So, not sure what my conclusion is here. I do know that because of this solution I was able to get the functionality I needed in two steps by:

  1. Extending Web Application
  2. Creating a web part for default page that redirects user based on URL

And the rest just worked. I’m all about the KISS principle and I could not think of anything more easy to maintain and straight forward than this.

Do you have a better idea? I’d love to hear it! Is there some issue here that I didn’t take into account? Here’s your chance to look smart to thousands… well…. hundreds… okay… maybe a dozen people… regardless… here’s your chance to me put it in my place.  :)

Or maybe this is just common sense and thousands of people are already doing it.. in which case I’ve just wasted an hour of my life (and 5 minutes of yours) that I’ll never get back…  sorry!  :)

Posted on Friday, July 30, 2010 5:57 PM | Back to top


Comments on this post: Extending a Web Application… probably not what the designers had in mind…

# re: Extending a Web Application… probably not what the designers had in mind…
Requesting Gravatar...
Create a base URL, myapp.com/silverlight and myapp.com/nonsilverlight.

Then make both apps use relatives URLs, if they click the silverlight/non silverlight button, it replaces the base url.
Left by Randy Walker on Jul 31, 2010 11:36 AM

Your comment:
 (will show your gravatar)


Copyright © Mark Rackley | Powered by: GeeksWithBlogs.net