Friday, January 11, 2013

WebSDK: Olark Web Widget - Part 5 - Wrapping Up

Welcome to Part 5 of this tutorial on converting the Olark notification widget into a Web control for use with Real Studio! If you haven't read Parts 1, 2, 3 & 4, I suggest you do so because we'll be building on the project from last time.

Today we're going to talk about making sure the widget persists while your user moves from WebPage to WebPage in your web app and some basic information about localizing for different languages.



Persistence

Through all of the examples I've given so far, you have only used the Olark widget with a single WebPage. In most cases, when you use a widget like this, you want it to appear and stay visible while your user navigates through your website. While the widget we created in Part 1 would work perfectly for that, The events, methods and properties we implemented in parts 2-4 will all become inaccessible if you ever called WebPage1.close because the control itself would get removed from the session. Because of the construction of the control, it will persist, but you won't be able to interact with it any more.

There are a few ways to handle this. The simplest of all is to attach the widget to the initial page and never close it. If your initial page is a Login page, that's really simple and will take next to nothing in terms of memory.

The next way to do this is to create a blank loading page to which you would attach the Olark widget, set the App.DefaultWebPage property to the new page and then add code to the Shown event to show your initial page. The disadvantage to this is that if your main page is complicated, there may be a significant delay. You may want to add your own "loading" message.



Localization

With the recent addition of dynamic constants to our web framework, why not make it so developers can specify the messages they want displayed? The Olark website has a great blogpost which outlines the different configuration properties to use! Remember that any changes that use olark.configure must be put in the SetupJavascriptFramework event and can't be changed at runtime.

If you want to download a completed version of this project, you can get the project file here. If you want to see the different localizations (I used Google Translate for French, German and Spanish), just set the language code in the Session.Open event like this:



Self.LanguageCode = "de"

...or...

Self.LanguageCode = "fr"

...or...

Self.LanguageCode = "es"


Cleanup

The last thing we recommend doing for all developers using the WebSDK is to add a comment to any SDK related events that you haven't used. In this case the SetupHTML and SetupCSS events have no code in them, but if a developer using your control implemented one or both of these events weird things may happen. To avoid confusion, we ask that you add a simple comment to each unused SDK specific events so the end-developers don't see these events. A simple "//" will suffice.

Wrapping Up

So that's it! As you can see, translating a 3rd-Party control is not a terribly difficult thing to do, but you do need to spend some time learning the API and figuring out how much of it you want to implement. I strongly suggest that you do this in pieces and troubleshoot each section as you write your code. Make sure you save incremental versions of your controls as well, just in case!

If you're interested in seeing my version of the project, you can download it here.

I want to wish everyone good luck in creating and converting controls to our framework... we're looking forward to seeing what types of controls you make!

1 comment:

Wayne Golding said...

Thanks Greg and excellent series.