Morning Session 2: Advanced Web Forms Practices – Part II

OK, so this actually started a bit last session, but want to keep everything together, so here we go with Part 2! May try to make this stuff less wordy, but it's a good session.

Morning Session 2: Advanced Web Forms Practices – Part II
Miguel Castro
Solutions Architect

2. Swappable State Storage

Can store data in Session, Application, Cache, Cookies, etc. So what if you want to swap storage of a var from one to the other? Have to find all instances and change them -- a bit tedious.
ASP.NET Provider Model has a solution.
Separation of concerns! Woohoo!

Static factory class for entry point to all storage methods
Provider base class defines public interface
One provider implementation class for each type of storage
Configuration section listing available and default provider.

Side note: He was doing an example and just manually added a namespace. I Heart Resharper.

Goal is to be able to do something like this:

StateStorage.Store("MyKey", "Hello World");
-- Is it using Session? Application? Cookies? Who cares?

So define a config section that defines several state storage providers, defining a class for each one. One of the providers is flagged as the default provider. Have to write configuration classes of course very similar to the last SSL example. ASP actually provides a class (ProviderSettingsCollection) for defining a basic provider using only a provider and type.

Single static factory class (StateStorage above) will read all the config information and get all the providers and assign a default provider.

Each provider extends a single base class that provides the Store method -- storing however you want. (Note .NET provides a ProviderBase class that your base class should extend) Also has abstract methods for things like Store that you want your provider to support. Individual providers extend that base class and implement the abstract methods as needed. Note can use the providers to uniquify the keys used for storage, or even uniquify a key in the application state for a single user. Don't know why you would do the second one - storing user specific data in application instead of session. But whatever.

And can target a specific provider in code by creating a physical provider from the list of providers in the StateStorage class.

I like it, but not as much as the SSL stuff. Lot of code to solve a not-that-hard problem. More cool code than useful code, but the concept of using the ASP provider model is a good one.

3. Nav Flow

Wizard-like scenario for multiple pages.
Includes nav buttons
Prevents step-skipping
Ability to manage pages and their order
Minimal code from page
Leverages Swappable State Storage above.
Even includes a custom control for dropping nav onto any page in process.

Define a configuration section with a group of pages. He likes his config files. I'm still a little out on how much I love the idea of doing so much stuff in config files.
Allows for defining which state storage provider (from above) to use for storing things like where you are in the process (for validating and preventing skipping).

Static NavigationManager has methods for:
1. Marking current step
2. Navigating forward and backward.
3. Validate if current page is a valid place to be.

Big warning about the Back Button here. May screw around with the validation. He says in eCommerce you should just threaten to double charge people if they use the back button. Haha.

My thoughts: Nice in that it's easy to insert pages or reorder them. Not sure how often that stuff changes drastically, but still a much easier way to handle this than doing all of this info right in the page itself. Could probably also do something like create a couple alternate NavFlows to A/B test some different alternatives (i.e. does fewer steps in the checkout increase conversion?) or provide a different navigation for an express checkout.

Could definitely see using this or something like it for checkout, although I'm (like I said) still not sure if it's maybe better to put the "configuration" inside of code instead. Little more work and requires a compile, but you gain some valuable things like better debugging.

4. Mobile Page Routing

Really quick section on routing mobile users to a mobile version of the site...and potentially vice versa.
Good design allows for forcing normal version even from mobile browser (i.e. full internet on iPhone) and keeps user there via a cookie or something.

More config settings to define the default mobile page. State storage provider again to store cookie (or whatever) for forcing full version browsing.

Another HttpModule that checks if mobile browser is accessing site.
Provides a class called BrowserInfo that has IsMobile property (see cd).

This section was very rushed, but worth checking out later. This has potential to be a key initiative going forward.

Great couple of sessions. Lots of really good and really useful info.