Sample Resource Service Skeleton

Loading...

来自 Johns Hopkins University 的课程

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

17 个评分

Johns Hopkins University

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

17 个评分

课程 6（共 6 门，Specialization Ruby on Rails Web Development）

In this Capstone project for the Photo Tourist you will implement a Ruby on Rails web application that makes use of both a relational and NoSQL database for the backend and expose the data through services to the Internet using Web services and a responsive user interface operating in a browser from a desktop and mobile device. You will have a chance to revisit and apply what you have learned in our previous courses to build and deploy a fully functional web application to the cloud accessible to your co-workers, future employers, friends, and family. In developing the Photo Tourist web application, you will get to work with different data types and data access scenarios (e.g., fielded data display and update, image upload/download, text search, access controlled information) to provide your users the ability to show off their photos and information from trips they have taken and to seek out photos and information from trips taken by others. Using the application you develop, your users will be able to • Create an account • Upload and download photos to the site and make them accessible to others • Provide descriptions of trips and photos that others can read • Organize photos by location and trip, • Find photos based on location • Find photos based on text searches of descriptions • Locate the place where the photo was taken on a map

从本节课中

SPA Development Setup

In this module, you will develop an AngularJS web application for the purposes of managing a resource hosted by a Rails server. As a part of that, you will learn the details of the Rails Asset Pipeline for hosting web applications, key features to address when moving from development to production, and different deployment options that you have within this course. You will complete an end-to-end AngularJS/Rails application to manage the resource on the Rails server you developed and deployed as a part of module one (1). This application will consist of AngularJS 1.x, UI-Router, and ngResource modules as well as a sample service, directive, controller, and web page to manage the resource. You will learn the details of the Rails Asset Pipeline as an option for deploying web assets like AngularJS web applications and what features it provides and how to conform to its conventions to get those features. Novice and intermediate developers are encouraged to use the Asset Pipeline approach in this module and throughout the course for simplicity and consistency with the examples in follow-on modules as this will be the development approach used by all follow-on modules. You will optionally learn how to leverage node package manager, bower, and gulp to establish an external development environment that parallels many of the capabilities provided by Asset Pipeline (e.g., minification to reduce bandwidth requirements and concatenation to reduce the number of separate server HTTP connections). You may leverage this environment to form a deployment to Github, like performed during courses four (4) and five (5) except with deployment considerations addressed. Although there is a functional gulpfile developed during the module, you are encouraged to treat this as an optional topic. Additionally, you can optionally learn how to use a hybrid of external development and Rails by using Rails as a web server and deploying your web application to the public directory and forming a single development tree and deployment artifact to Heroku. Like the pure external development approach, you are encouraged to treat this approach as an optional topic.

Sample Resource CRUD Module5:32

Sample Resource Service Skeleton8:56

Sample Resource CRUD Controller Skeleton4:49

Sample Directive and Template Page11:22

Sample CSS Styling5:06

List Resource Instances3:25

Create Resource Instance8:32

Select and Update/Delete Resource Instance6:37

Sample Application in External Environments2:28

SPA Application Deployments8:03

CORS Revisited7:47

与讲师见面

Jim Stafford
Adjunct Professor, Graduate Computer Science
Computer Science, Whiting School of Engineering

[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.

探索我们的目录

免费加入并获得个性化推荐、更新和优惠。

Coursera 致力于普及全世界最好的教育，它与全球一流大学和机构合作提供在线课程。

© 2018 Coursera Inc. 保留所有权利。

通过 App Store 下载

通过 Google Play 获取