[MUSIC]

In this lecture we will discuss a sample service, a resource service.

That's going to take care of the details of communicating with our back end Rail

server for our overall Angular application on behalf of a particular resource.

I'm going to refer to this service as in a skeletal mode at the moment.

We're going to go through the very first time and fill in the important details,

but we will revisit this service and

add a few things to it as we encounter some issues in the upcoming use cases.

The service will be based off of ngRource which provides a rest based

interface above the HTTP service.

And this will play nicely with our back end Rail service,

which complies with many REST principles.

And we'll express our service to the application using and Angular factory.

Before we get started with code,

let me just go through a block diagram of some of the things we'll be developing.

We already have our backend Rail server.

And we have the startings of our Angular application.

And after Angular has come up and the user has navigated to a particular page that

has certain elements, let's say sd-foos.

Angular will take a look at those extension elements and

try to locate them in directives.

In this case a foo directive registered under the name of sd-foos.

Note the difference in naming case between the camelCase sdFoos and

the spin-case sd-foos.

There are many different options of what the directive can do, but in this case,

it's going to declare an HTML template and a controller.

The HTML template has much of the data representation of what will

be part of the view.

The controller has what's referred to as a view model.

It too has data, and it's mostly the volatile data that comes from the backend.

And it also has call backs that can be invoked on certain events.

Those call backs will rely on the service that we're going to develop here.

And Angular will inject that service into the controller when it's instantiated.

Although I have shown arrows between many of these components,

they don't necessarily instantiate each other manually.

Many times it's just a configuration setup and they are injected by Angular.

When an event comes in to an event on the foo HTML page, Angular may interpret

that event as something that needs to be called onto the controller.

The controller, of course, depending on what the callback method is programmed

to do, will make use of the foo service in order to access the data on the backend,

managed within Rails.

Rails will go though all of its interaction

in order to satisfy the request and provide a response.

The service then, assuming it's successful response,

indicates that success through a success call back to the controller.

And then the controller uses that data that came back in order to modify

its view model, the data it manages, the volatile data.

And then changes to the view model causes Angular to

re-evaluate the HTML page causing the affected areas to be updated.

In this particular lecture we going to start with the foo service.

The next thing I'm going to add is a service to

directly contact the backend API server.

So create a new file, and in order to implement this service,

I'm going to use a factory.

And because it's in the foos module,

this is in the spa-demo.foos module I include that.

In order for the template to play nice,

I'm going to start out by just calling that foo and I'm going to come back and

edit that in a second, after I finish saving it.

It's a foos.service.js.

It's not an ERB file because it doesn't need any kind of expansion.

Okay and now that the template's expanded I can go ahead and say, spa-demo.foos.

Foo is my resource name.

I'm going to go with the naming convention of whatever my backend resource is,

it's going to be that name, singular with a capital f.

Let me get rid of much of this for now and start out with some of the injections.

We know that we're going to take advantage of the resource ngResource, and

the other things that we're going to take advantage of is the spa-demo.APP_CONFIG.

One of the advantages of injecting APP_CONFIG is we can leave this file as

a straight JavaScript file.

And leave all ERB processing to the APP_CONFIG.

So now, I've taken care of the injection.

Let me pass the parameters in.

Okay, so what I'm going to do is return a resource and

the resource has three parameters,

one string, and two hash kind of properties.

The string, we will base part of the string off of

the server URL that we created earlier.

And then we will extend that string with api/foos, okay?

And then one additional piece is that we are going

to add this definition of colon a name to this URI.

So that if we do supply a parameter to these calls

of ID that's where it's going to get stuck.

But the resource is smart enough to know that if it's doing a query

it can lope off the :id and just use api/foos if we are talking gets,

and deletes, and individual objects.

It's smart enough to use the :id, okay?

And then the second parameter is, well, what if we have

an instance of this resource, and it has a payload inside of it?

Well, what we'd like to be able to do is take and

map the id of that payload to this, the URI.

If it's mentioned in the URI, well, it's passed in the URI.

If it's not then it's passed as a query parameter.

This is when we're asking ngResource to automatically pull the information out of

the instance data of the object.

The last parameter has to do with a configuring certain method calls.

And not quite sure why they didn't just put this particular one in as a default.

Let me define it like this, but when we call update there

is no method specifically assigned to that and we need to map that to PUT.

We could also map it to PATCH which is implemented by the Rails server, but

let's stop there.

So I've defined a PUT method, I've defined a mapping of ID,

I've defined my URI and based that off of server URL.

We'll have to come back, but that pretty much implements the skeletal portion

of the resource which makes up the bulk of our overall service of foos.

One of the things we need to make sure that we don't forget

before we get too far away is to add the service to the manifest.

Or for developing external to add it to the index.html.

So in summary we built a sample service to the contact our resource on the backend.

We used Angular factory to build that service.

We know from our work in course five that there are actually various choices

we could use.

A factory, a service, or a provider.

We chose the factory in which we'll just implement it that way now.

That factory returned a very magical $resource,

something that's capable of doing a lot.

The actual resource itself represents the collection of foos.

So if we want to query the foos, if we want to do anything on the collection.

We can just take the returned object and call a method on it.

Instances of the resource.

If we new up the $resource, that represents an individual foo.

And that instance state inside of it can be used to fill in URI information or

query parameters in order to contact the back end.

That $resource of course, is part of ngResource.

And during the construction of this service,

we configured our ngResource resource in order to contact our Rail

server on the backend through a modifiable application config object.

What's next?

Let's build the starting point of the controller that'll make use of this

service.

Let's limit it to just CRUD actions.

Sample Resource Service Skeleton

毕业项目：旅游照片 Web 应用

与讲师见面