Hi there and welcome! I'm Jason Johnston, one of the engineers working on Sencha Designer, and today I'm going to be giving a walkthrough of how you can use Designer to set up and use live data in your Sencha based applications. --- Let's begin with a brief overview of the data layer in Sencha frameworks. This may be review for some of you, but it'll be quick. The central object in the data package is the Store. A store is essentially a bucket that holds a collection of data records, and allows iterating over those records. You can control how it iterates -- for example grouping, sorting, or filtering the records. Stores are most commonly used by data-bound view components, such as a DataView or List, which display the store's records in some custom way. Each of the data records has a pre-defined internal structure -- we call this structure a Model. A Model is essentially a specialized Class, and consists of one or more fields with a name and data type, and optionally other advanced properties such as conversion functions. You can define parent-child relationships between models, which we call Associations. A store is also able to load its data from somewhere, for example from an external URL, or from the browser's HTML5 localstorage. The store is instructed how and from where to load its data by configuring it with a Proxy. Examples of proxies are Ajax and JsonP proxies for loading from external URLs, or the localstorage proxy for syncing with the browser's persistent HTML5 local storage, plus several other proxies built in. Often, a proxy needs special instructions on how to interpret the raw data it receives, so that it can be populated into Model instances; this is done by configuring a Reader. Sencha provides readers for interpreting Json, Array, and Xml data. For convenience and reuse, a proxy can also be defined as a property of the Model rather than the Store itself. --- Now that you understand the basic pieces of the Sencha data layer, let's see how you can put it all together within Designer. Here we have an empty Sencha Touch project in Designer -- I'm using the Designer 2 beta release. The project has already been saved to a directory that will be served up on my local web server so we can test it -- standard procedure when setting up a Designer project. Unlike Designer 1, in Designer 2 data stores and all their related objects, such as models, fields, proxies, and readers, are provided as items in the main Toolbox. We can easily filter the toolbox to only show data related items by selecting the Data group. Let's look in the Data Stores section of the toolbox. Here we have the two basic types of stores: Store and TreeStore. All the other items in this section, such as Array Store and Json Store, are simply shortcuts for creating stores with certain combinations of proxy and reader already added. For the purposes of this demonstration we'll do it manually. So let's add a plain Store to our project by dragging the Store item out onto an empty area of the canvas, and you'll see that the store gets added into the Project Inspector tree under Stores. It's given an automatic class name of MyStore, but let's change that to something descriptive of what it's going to hold: Contacts. Let's also change the storeId -- this is a unique string that components will use to reference this store. Now you can see that Designer is telling you something isn't right with this store, so let's click on this icon and see what's up. It's telling us that the store does not have a Model defined, so it doesn't know the structure of the data records it's going to hold. And in fact if you were to try to run this project right now, the Sencha Touch framework would throw an error at you because of it. So let's make the store happy and create a Model for it. Again we drag out a Model from the toolbox, and see that it shows up under Models in the inspector. We'll give it a class name of Contact. A model needs to declare one or more fields that it holds, so we can either drag Field items from the toolbox onto the model, or we can right-click the model and add some fields in bulk. Let's add 4, and give those fields the names 'firstName', 'lastName', 'city', and 'state'. Finally let's associate the model to the store, by selecting the model in the store's 'model' configuration -- and the error icon is now gone. At this point we have a valid store that knows the structure of its records, but it doesn't have any data in it. We have some options here. If it's a static set of data formatted as a JSON array of objects, you can paste that JSON directly into the store's 'data' config. This is fine in simple cases where your data is totally static. But chances are your data is dynamic and you want to load it in on the fly from an external URL somewhere. For this, we need to set up a proxy. Let me show you quickly the data we're going to load. This is just a URL on my local web server that returns a JSON-encoded list of contacts. The list of data items is under a "contacts" root property -- remember this for later -- and you'll see the properties in each record object match the fields we defined for our model. We're going to load this file via an AJAX call, so we'll drag an Ajax Proxy onto our store, and set its 'url' config to the URL of the json file. You can see there are many other configs available for controlling the parameters sent with the ajax request -- these give you a great amount of control over how your data loads -- but for now we'll leave them be. We do, however need to inform the proxy how to interpret the JSON data it gets back, specifically telling it that the array of data objects can be found under that "contacts" root property. To do this, we'll drag a Json Reader onto the proxy, and tell it that the rootProperty is called "contacts". At this point our store should be able to load data. How can we tell? We can have designer do a test load for us! Simply right-click the store in the inspector, and choose Load Data. Once it finishes loading, if it succeeded it will show you this nice little icon with a tooltip telling you how many records were loaded. We see it loaded 7 records which matches our data. If we had done something wrong, for example a typo in the proxy's url, then we would instead get an error icon and clicking it would give us some detail about the error -- in this case it gives us a link to the url it attempted to load so we can check it. --- Now that we have a store with data loading into it successfully, let's use it to populate a List so we can see it in action. Let's find the List component in the toolbox and drag it out onto the canvas. By default it's using a dummy store, so we need to change it to use our Contacts store. Let's modify its item template to display the fields we defined in our store's model. There we have it, our list is displaying the data in our store. Let's save our project and view it in a browser. But first, we need to set the store's autoLoad config to true, so that it will automatically load its data when the app starts up. Otherwise we would need to write code to manually trigger a load, and that's out of the scope of this demo. Now, when we open the project's mounted URL in our browser, we see the data has loaded and populated into our list! What other interesting things can we do? Let's make the store sort the contacts by last name. Sorting is done by adding one or more Sorters to the store -- let's drag a Sorter onto our store, and tell it to sort on the lastName property. Reload the store and now the list is sorted. You can add multiple sorters for multi-tiered sorting. Very similar to sorting is grouping. Let's add a Grouper, to group the records by some common aspect, for instance the person's home city. Switch on the list's grouped config and it starts to show the groupings. --- As a final quick sanity check, let's take a look at the code that Designer has generated for us by switching to Code View. When we select the store we see that it has created a store class for us, with the proxy, reader, sorter, and grouper configurations nested within. Likewise we have a class generated for our Model that contains the fields. And the List component is referencing our store by its storeId. Finally, if we select the Application node in the inspector, we'll see that our model, store, and view are referenced from the main application config -- this is part of Sencha's MVC architecture and beyond the scope of this tutorial, but important since this is how the application knows about your store and model. --- I hope this has been a useful introduction to managing data stores within Designer. We only touched the basics with this demo, to give you a sense of how Designer exposes the features, but if you want to learn more about the powerful capabilities of the Sencha frameworks' data layer I highly recommend checking out the documentation and examples at http://docs.sencha.com, and in the various user forums at http://sencha.com/forum That's it for now. Thanks, and have fun building your Sencha apps!