There are a number of options for connecting your SproutCore application to a server.
Here we give an overview of the options that you have.
endprologue.
WARNING: This is a Draft Copy, and although the information in here is correct, it may be incomplete in places.
SproutCore includes a powerful model layer, called the datastore. SproutCore has special code in it’s controller and view layers to make the datastore the most efficient source of data.
Nevertheless, you don’t have to use the datastore in your application. Like most high-quality frameworks, the datastore is an optional framework in SproutCore (though it is “on” by default).
If you come from a jQuery (or other JS framework), you’re probably used to making your own AJAX calls and handling the response yourself. Toolkits like BackBone work like this. If you have a small app, and feel more comfortable with this approach:
Follow along with the Using a server without the store Guide.
However, if you are going to deal with more than a handful of data, or want to take advantage of relationships between data, then managing it all on your own quickly gets messy. One of SproutCore’s strongest features is it’s Data Store. The Store can hold all of your data in memory allowing you to search through it with Queries. It is also the central place for your data, allowing you to bind many different views to the same record and have changes propagated easily.
Connecting your store to a server can be one of the most daunting tasks in creating your app:
- How do I know when to send a message to the server?
- Do I have to rewrite my server?
There are some different choices depending on what setup you already have (if any).
If you are coming to SproutCore with a server side app that you already have running, the fastest way of getting going is to contact your server and update the store to match based on the response. For example, if you want to update a record in the store, you would ask the server to update the record and then when the update is successful, you would update the store locally.
This is possible because SproutCore’s datastore framework allows for nested stores. With a nested store, edits are “buffered” in the nested store. You would send the changes in the nested store to the server, and when it responds, update the base store and clear (or destroy) the nested store.
This makes your “base” store a read-only copy of the server. You can push new data from the server into the base store at any time, update existing data, or delete data. Any changes to data are made in a nested store where they can easily be aborted or cleared.
This puts the server 100% in control of the “base” store. There are techniques to keep your base store easily up to date, and to refresh parts of the store when needed. Very sophisticated apps can be built with this approach, and it is the most appropriate way to build a SproutCore application if you already have an existing server-based MVC app.
We will have a guide for this soon.
The downside to this approach is that your app will have to wait on responses from the server, meaning that you don’t have a truly responsive user experience. See the next section if this is a concern.
The final approach puts a SproutCore data store in 100% control.
This method of connecting to the server is to use SproutCore’s default method of a DataSource. The Store is designed to interact with the DataSource, letting it know when things have changed. When using a dataSource you can treat your Store like a local copy of your server. You can ask for records, save records or create records directly in the store, and your dataSource will then take care of propogating these changes to your server.
This method will give you the most interactive setup, allowing your user to keep clicking, and not have to wait on your servers responses before moving on. If your going for the best user experience in an app, this is the way to go.
Have a look at the Connecting With a DataSource Guide.
- March 2, 2011: initial version by Geoffrey Donaldson and Erich Ocean
- March 22, 2011: minor spelling corrections by Topher Fangio