Overriding SkySales Controls

June 13th, 2011

There will come a time at some point in your SkySales development efforts when you’ll need to change some bit of code to work differently than what Navitaire delivers with a fresh New Skies install. Since Navitaire does not ship the SkySales source code to their clients, it can be a bit tricky to leverage 95% of what they’ve done in a control just to make the last 5% conform to your business needs.

Seasoned developers have in their toolbox a handy tool called Reflector that will allow them to examine and even debug into the assemblies that Navitaire ships.  For enhancing and working with SkySales controls, this is an absolute must.

Site Note

Navitaire is aware that their customers routinely decompile the SkySales assemblies.  It’s not a big secret.  If they were concerned about this, they would obfuscate the code to make it very difficult to understand when viewed through a decompiler.  It makes you wonder why they don’t ship the plain code alongside the compiled code.

Being able to snoop through SkySales code is invaluable.  However, there is a danger to having this decompiled code available to the novice developer.

I’ve seen many times where decompiled SkySales control code was taken wholesale from the decompiler and pasted into a new custom control (variables named “num3″ are a dead giveaway).  Modifications are then implemented (usually without comments) to certain portions of the Navitaire code where needed.  Don’t get me wrong, this can be a time saver when a project deadline is looming.  However, what you gain in short-term development speed, you loose in long term maintenance.  Are future developers going to be able to understand all of that code you just dropped into the project?  Will they know exactly where the vendor’s code stops and your custom code stops?  And the biggest question of all:  How will that code be updated when your airline takes an upgrade?

If you’re doing at least a moderate level of customization to your SkySales solution, you’re going to have a situation where you must use some or all of a decompiled control.  But how can you do this with minimal maintenance issues?  Below is the best method I’ve found to have the best of both worlds.

In your project, create a special folder to place any classes you must decompile fully.  Examine the class and determine the best entry point for your modifications.  Once you fully understand what the Navitaire base class is doing, insert events at the points in the base methods where you need to insert your customizations.  Your modifications should be well commented and should be a single event line.  You will then create a new class that will contain your business logic and subscribe to the custom event you created in the parent control.  The following is an example of a custom event:

DisplayingBoardingPass(this, new DisplayingBoardingPassEventArgs(pass, segment, passenger));


This was done for a client in the notoriously monolithic OnActivatedPreRender method for the BoardingPassDisplay control.  In this case, the client just wanted to add some XML data inside the boarding pass node being constructed.  However, because the boarding pass node doesn’t use any events or virtual methods when creating it’s XML structure, the control had to be decompiled in order to allow an insertion at just the right point.  Events will also allow you to pass objects to child classes so you can implement some intended side effects on those base objects.

Now, when it comes time to take the next Navitaire upgrade, the client can reflect on the new BoardingPassDisplay control and run a compare to easily see what has been changed.  Since our modifications consisted of one line here or there, the original code is intact and devoid of the various business logic that creeps into custom controls over time.

While the method described above will work and has been tested as a viable way to reduce maintenance costs through upgrades, we should ask: “Why is this necessary”?  The SkySales team must believe that the methods they have marked as virtual are all any one will need to successfully modify the base control functionality.  This is not the case.  The SkySales controls were not written from an implementers point of view.  I suggest that Navitaire should run through their SkySales controls and sprinkle them with events.  As implementers, we need events in the middle of large loops, before and after objects are committed, and in methods that are not easily overridden because of their reliance on private methods.

Filed under New Skies, SkySales