Digging Into Upshot.js

Coming from a Silverlight / WPF development background, I have a huge interest in figuring out how to be effective with the same MVVM pattern on the web.  I do a fair amount of MVC development as well, and the new Single Page Application framework offers me a great opportunity.

Currently, the documentation is a bit limited, but is forthcoming, and hopefully will bring about a lot of documetation and examples beyond what is currently available.

I did some exploring in upshot.js today, and wanted to report what I found.  Basically, to help understand the architecture of upshot and how we might see it used with knockout.js in the future.

Upshot starts with DataProviders (there are 3 of them total):

  • the default is DataProvider() and uses the /Submit method and the operation you provide it to get data using jQuery’s $.ajax method.
  • the next is riaDataProvider() – similar to the first, but it uses the /json/SubmitChanges method and /json/{your opertion} to get data
  • finally we also have odataDataProvider() – this one is quite different because it does not currently support updating data – it is read-only.

The next thing I wanted to understand was all the different objects available in Upshot and what they are used for.  Here is a basic understanding of the architecture:

  • EntitySource – basically a wrapper of an array of Entities which is observable
  • EntityView – inherits from EntitySource and exposes Change Tracking
  • DataSource – inherits from EntityView and adds Paging, Sorting, and Filtering
  • RemoteDataSource – inherits from DataSource and incorporates your DataProvider
  • LocalDataSource – This wraps the RemoteDataSource and works locally to provide cached/offline access.

Separately, but within your upshot context we also have some basic context:

  • DataContext provides a Root Element to all your entities, and manage tracking and batching for the provider in a single context, the DataContext contains the metadata, EntitySets, and Provider.
  • EntitySet inherits from EntitySource and provides change tracking based upon an entitytype, managing changes and errors/validation for a specific type.  We can have 1 EntitySet per model type in our DataContext.

Finally, we need to understand how we create our models as Entities in javascript so that upshot can mange them.  There are a couple ways that this is accomplished, and one big bug that seems to exist.

  • First of all, we need to provide any metadata that exists on our models in MVC to upshot’s datacontext.  This is done by calling upshot.metadata and providing a json object which resolves this out to a common metadata model.  We have a Html helper in MVC to do this for us.
  • Second, we need to create an object (function) in javascript that will accept the json response for an entity and create a usable entity for upshot. This can be done using the upshot.map function, or creating properties which are ko.observable and mapping each one in manually.
  • Finally, we need to call addEntityProperties() – this applies the properties need to track state on our object.

The Properties added by addEntityProperties are:

  • EntityState (can be: Unmodified, ClientUpdated, ClientAdded, ClientDeleted, ServerUpdating, ServerDeleting, Deleted)
  • EntityError (if the entity has an error)
  • IsUpdated
  • IsAdded
  • IsDeleted
  • IsChanged
  • CanDelete
  • Finally – it also adds a “ValidationError” property to each property to manage the errors associated with each property.

If your model uses a server-generated key, and you are performing adds.  It appears that you cannot use the .map function to create your model at this time.  You need to do a work-around such as:

id = ko.observable(properties.id || 0);

This will assign a value of zero if you have a new object – otherwise your entity will always be in error since the key is required, but not provided.

My next post will be about how to use all this, once I get my working sample /demo together.  Stay tuned!

About these ads
  1. March 8, 2012 at 7:11 AM | #1

    Greetings from a fellow Denverite. Thanks for digging into this. I just watched Steve Sanderson’s presentation the other day and was really intrigued, but was a bit daunted by the lack of docs. I will have to follow your example and dig into the source.

  2. February 24, 2013 at 6:50 PM | #2

    This is the reason I keep coming back to this site.
    I can not believe how many posts I missed since my last visit!

  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s


Get every new post delivered to your Inbox.

Join 76 other followers

%d bloggers like this: