 OK. So we're going to talk about, nominally, we're going to talk about Ember data. We're not going to talk about Ember data in the broad stroke sense. What I want to talk about is a problem that I ran into, how I went about solving it, and hopefully it's something that you can either benefit from or contribute to. I, my Twitter handle is Yankee in London. I'm kind of relatively new to the Twitter scene. My old ex-fiance's roommate created Twitter. I was actually supposed to be involved in reviewing a project back in San Francisco in the early days that was a precursor to Twitter. But I'm now getting it. I think Twitter is a good thing. And I'm signed up, so if you want to get a hold of me, that's probably the best way these days. So let me just give you a little backdrop on what I've been doing. So as I mentioned in the beginning, I'm not an Ember expert. But I have now, this is my second application that I've built with Ember. The first one was a front-end interface. It was more of an experiment, a little bit of a play, to see how Ember might work. And in a sense, this is a little bit similar. I've got a architecture where the primary focus from the client side has been iOS. And it's iOS communicating through a RESTful API to a couch base back end. And so we're early days, so the administration of some of the couch base documents was easy enough to use the tools that come with couch base going in there and mucking around with some of the JSON. But at some point, the idea occurred to me that an administrative interface might be a good way to start to become more familiar with Ember, start to really understand whether Ember data is the right solution for what I'm trying to do. And it became more necessitated by the fact that in couch base, I was starting to do more advanced things with lookups that some of the business logic that was tied into the back end, it was no longer really that convenient just to go in and play with the data directly. So having the same business logic that the iOS app or any client would have when data's been manipulated be available to the administrative application was attractive. So I did that. And the first thing I did was I think anyone who's done an Ember application is really simple to go through and iterate through a set of arrays. So you get a model, and you're an array controller, and you can just go through. And it's very easy to, in this case, if I want to manage, say, reference data in an application, I'll flip back and forth a little bit here. I'll show you just so you can see it a little bit more the interface. So I'm not going to go through all of this. But in this application, the idea of an action is something that a person can do. And as I said, it's just a standard REST-based API. So you can make your GET request with no ID and get back a list of the different actions that are available. You can ask for a specific one. You can add one using posts. PUT is an update, so on and so forth. It's all fairly basic. What I'd like to be able to do, though, is have the administrative interface go in and use this API and start to manipulate the couch base records behind that. So let go back into now. So getting a table of actions is easy. Using an array controller, go to the model. I can see all the data that's there. But if I want to go into an actual record, my assumption was is that it would also be easy to iterate through the properties. And actually, that isn't kind of automatic. There are some libraries out there, libraries called SWAG that helps you go through iterate through object properties. And it's not hard to create helpers that allow you to work or components that would allow you to go through different objects. But in terms of getting out the properties that you'd want for a record in Ember data, you have to put it together yourself. And really what I was looking for is really actually quite simple. It was just, I want to know what is the name of the property. I want to know what is its value. And I want to have a bound connection to it. And I'd like to know what type of information that is. I mean, type in the most basic sense. And so if it's defined in the model as being a string, I want to know it's a string, or a number, or a date, or whatever it's defined as. Potentially, there's also some additional meta information I might want to add on to that as well. And if we have time, I can show you that there's also ways of extending this beyond that. But these three attributes are the key thing that I want to build my administrative interface on. The idea would be is that I can have a model neutral approach. I can just throw the name of model. And it will go through and display all the attributes, use the appropriate widgets, so that if it's an array, it'll give me some sort of control that works the rays. If it's a Boolean, so it'll give me an off switch or whatever is appropriate for the type of data that's there. So this is really, I think, another way of saying it's pretty small. But what I want to be able to do is have someone build a model and then have the screen built automatically so that the administrative interface just kind of grows with the model as it's being developed. So I went into, first, you go into the EmberJS website. There is the guide section. And you can get a certain distance with that. And pretty quickly, there was clear that the questions I was asking weren't getting answered there. So I went to the API section, which is the next point of reference. And in the API section, there are quite a few things that are available. So there's a number of static methods and data types related to the model object. And in their own ways, they all sort of answer around this question. In terms of those three attributes I talked about, none of these talk about the value. They're all talking about trying to address the type. Is this a relationship? Is this an attribute? If it's an attribute, what type of attribute is it? If it's a relationship, what type of relationship is it? But I just found, in many ways, kind of structurally not very well suited for what I wanted. The way I would like to view it is just there's a list of things in my model. Because even the relationships to start out with, my model have, let's say, an action is related to, well, this doesn't make any sense. Let's say a unit of measure. So there's a one and many relationship. To start out with, I'm just going to put that as a string field. I think most people, when they model these things, they just put in strings. And then that allows you to, or an array. And that allows you to kind of have ultimate flexibility. Then you can start to tune it to a has many relationship or owned by relationship later on. So when I looked at the outputs of this structurally, it was a little bit weird in that it would list, one of these, let's see, attributes would only list attributes. Relationships would only list relationships, which I guess makes sense. There's one of them here, and I guess it's not here. There's another one that says, list all fields. But when you start getting fields, that comes close to what I want. It's now the full list of things that are part of that model. But the problem with that is that the type then becomes auto. I mean, for the type on a attribute, the type is just attribute instead of, say, in string. So you lose that resolution there. You call one API to get that. You say, oh, it's an attribute, and then I have to call another one to find out what type it is. Again, it's all not terrible. It's just not exactly out of the box. It's not certainly available to the templating engine in the way I wanted it to be. And then in terms of value binding and promises, this is something that is starting to make a lot of sense to me, but it's also something that I'm not perfect at yet. So my realization was that trying to bind to an actual record was creating difficulties because the model itself, if it wasn't held in memory, the reference to the record itself would go away. So what I had to do is I actually had to bind to the right, I'll show you an example because it's easier for me just to show you than talk through it. But so in the case of iterating, this is readable. So if I have a binding, which really what I'm interested in is the type or the value, I can't simply bind to that attribute and pass along this object. I have to instead include the actual record and then make a relative binding from that record over to the field. That makes sense. In any case, that's doing that. And now I've went through the guides, the API, and the discussion lists and finally come up with this solution. And it does work. So I get a bound reference to the values. And in summary, I was able to create a mixin that gets my simple answer. It gets me to give me the type, give me a binding to the value, and give me a reference to the name. And based on time, what I was thinking is I can show you, I can just go through the exercise of building from a kind of completely blank project, the controller calling the API, getting a list of items, and then showing you the model neutral way of going through this. And I hope that'll work. Or I can just show you the endpoint where kind of the conclusion, I'll probably show you that anyways at the end. I think we're going through pretty quickly. What are we trying to end at? So I'm going to try going through the actual coding exercise then. So the starting point is at zero. So we're really starting here with a project, which I'll keep the debugger over in the right-hand side so we can look at that throughout the exercise. I'll make this a little bit bigger so we can read. And all we have is a single template which says, check out this cool sexy admin functionality. And if I click on that, it will go to the admin route which has nothing. So pretty much starting at zero. Let's look at that in code. So in code, we have what you'd expect. There is a reference to the REST model. I won't go into that, but it's pretty basic stuff, just connecting it up to the API that I showed you earlier. And, well, here, let's just look at it quickly. So it's as simple as specifying that there is a prefix on the API, and then there's an array element that I'm doing a serialization for. But other than that, it's just plain vanilla of using the REST adapter as it comes out of the box. So that's our starting point. So there is a semblance of being able to talk to this API. There is a route called administration, and there is an administration item route. And the idea is that on the admin route, what we're going to want to do is set up just a text field where we can type in a model, and then it'll use that model to go and pull out down all the records for us. So we can choose a record, and then it'll tell us all the properties in that table. So that's what we want to do. And I've cheated a little bit to make this a little bit faster, and I've created some models for us. So if I save that, go back to the blank admin page again. And if I go to the data side here, now you'll see that there's three models do exist, it's definitions. There's nothing in there. But we have something called an action, which we talked about earlier. We have units of measures and unit of measure systems, which we may not get to, but if we want to talk about how relationships versus attributes are set up, we can use that as an example of that. So models are set up in our definition now, but no interactivity. So the next thing I'm going to do is add in, I forgot my cheat sheet. We're going to create a controller and a template, which is just for the index. Again, this is for the array controller. It's going to just show us the list of different IDs within whatever model we specify. So I'm going to save that. When we come up back over here, now the template's been updated, so it allows us to put in the model name. And if we go back and look at data, our options are action, unit of measure, unit of measure system. I'm going to choose action, which point is going to say, yep, that's a valid table. And it'll give me a list of different IDs that are available, and I can choose whatever I want. So let's just choose eight, launch. Now, by clicking on that, you'll see that we've navigated to the next route. So the next route is an item. And the goal here now is to introspect. And of course, this is the magic. This is the part that I was struggling with, is how do I go through dynamically and figure out what are the properties, what are the types of those properties. And hopefully, this is the part that works. Now, I was coding as I came over here because I didn't give myself enough time for this talk. But OK, so let's see now. So actually, one thing to note, too, is that you notice here that in loading the actions prior, we have loaded up all 100 or 116 action records that are all in here. And what I'm going to do is now bring in the item controller. And let's take a look at what this is actually doing. So I think at first, it's not going to work. But so basically what this is going to do is it's going to map back to the index controller. So it's going to say, what is the model that you're using? And what is the ID that you have? And then it's going to ask for a promise or for that record in the form of promise and put it into the content field. So that's the goal of this item controller. And then in terms of the template, really simple, it's just we'll come to the second. The model super meta is going to be effectively the iterator that will go through each one of the properties. And again, we're going to ask for the name. We'll use a text field for the value. And what type of field it is. So I think I like that order better. So this is the original problem I was trying to solve. And if I go back to the web browser, I don't think it's going to be solved right now. I'm going to, should have already reloaded, but I'll just reload it for the sake of arguments. And in fact, yes, I have some sort of an error. And why is that? And the reason is because we don't have a mix-in, I think. So right up here, you can see that it was expecting some sort of mix-in. That was the mix-in that I mentioned earlier that kind of solves this problem. So let's go back and add it in. Doesn't really matter where I put it. So now, with this mix-in being associated with the product, I also have to go into the item controller. Oh, actually, in that case, it's already referenced here. It just wasn't included in the project. So it should work now. This is what I was afraid of. So the items comes up. The template is loaded. If we look at the controller, we can see that the mix-in's properties are all here. This is what I was scrambling with the last five minutes. I realized that this, in the new environment that I've set up, does not seem to work. The idea here, and I'll show you it working in a second because it does work. There's something a little bit squiggly going on, is that the model fields will give us the straight list values of all the attributes and relationships. And then, SuperMeta just brings that in, along with the bounded values as well, to give us the simple objects that the template can iterate through. So ultimately, this is an example of what the end product looks like. So here is a list of a table. This is the actions table that we were looking at before. We can choose an item, all the properties, if that thing come in. It identifies the type of information based on the type. If it's a Boolean, for instance, it will put in some sort of a flag for a Boolean user interface. If it's like synonyms is an array, so it can come up with a multi-selector of whatever I like. And I can go back to the list and see that I didn't save it. So it's noticing that the record is dirty. So it allows me to come back here and just save it there. Likewise, I can delete records. But it just allows now for a simple way of me just pointing at any new model that comes into the system and having a quick way of viewing the attributes, clicking into them, and then checking out the various properties. So that's it. Well, actually, I guess one thing we didn't. Let's see if I can give you an example of it now. I think I've simplified the model right now. One of the things I started to do, I mean, I think most people when they start using number data, they use, as I said, the strings for a lot of the relationships. So for instance, if I take a model which has a relationship units of measure, demo problems, OK, I'll have to explain it. So when I put in a unit, a measure has a system of units of measure. So for instance, a kilometer is part of the metric system. So it has a relationship to metric. And right now, I just have it listed as a string. So therefore, I can say it's part of the string metrics, or I can say string comma imperial, if I think it should be associated with the imperial system as well. And that model works. It doesn't really take full advantage of what you're getting out of Ember data. So obviously, you want to start to use the built-in relationship functionality that Ember data brings. And this simple model, this mix that I've talked about, will certainly expose that information. So it's not a problem. You can visually see what are the relationships, what kind of relationships are they. But my first experience with them was that this is for what I'm trying to do, which is just a functional goal of being able to administrate this data easily. It was more hassle than it was worth to start out with. So it works. It does what I need it to do, as it is, over the course of the next couple of weeks. I probably will try to find some time to start getting the Ember data working the way it should be working. And it's more complete fashion. But I'll stop there. What questions do people have? Have you looked at how the Ember Inspector implements a zone-like data section? Because obviously, that lets you edit data as well and save it and such. Yeah, that's a good point. No, I haven't. I mean, so I haven't looked into the code, if that's your mind. Because effectively, what I would say is that the problem that was solved here is not a hugely complex problem. It's just, in fact, it's a relatively simple problem. But it's so simple that I would actually expect it to be more out of the box. I would think that in the same way that with an array controller, we can simply iterate through that, I would think that we'd just come out of the box. And maybe it will at some point in the future. It was sort of a fun way to try to get underneath the covers and maybe looking at the source would have been a good way of figuring that out. Other questions? Jamie? I think that's a little bit more about the line sketching. I can. I think it's probably more of a beer conversation. The short version is it's sort of an intersection of the health care and wellness space that's taking place. For those of you, I think probably a lot of you who are reading the tabloids these days about Apple's new iWatch or whatever it will be called, they're making even more popular a space that two years ago pretty much didn't exist. My focus is within that kind of realm. And it's more focused on connecting the individual to a set of professional services like personal trainers, dieticians, physiotherapists, and allowing for them to interact in a more effective way. There's a very strong evidence to suggest that people who want to create behavior change do it much more effectively with those sorts of actors involved. And I think they're all very keen on working on a data level with people, but they just don't have the tools to do it right now. OK. Well, we may be done. We may be beer time. OK. Well, let's break. Thank you.