使用Ember.js构建Web应用实战

需积分: 3 32 浏览量更新于2024-07-18 收藏 11.75MB PDF 举报

"Buliding Web Apps with Ember.js - 一本关于使用Ember.js构建Web应用的书籍，由Jesse Cravens和Thomas Q. Brady撰写，涵盖了Ember.js框架的基础和高级概念，包括MVC架构、路由、模板、模型、控制器和视图等。" 在Web开发领域，Ember.js是一个强大的JavaScript框架，它基于模型-视图-控制器（MVC）架构模式，用于构建可扩展的单页应用程序。这本书《Building Web Apps with Ember.js》是为那些希望深入理解并利用Ember.js构建全栈、浏览器端应用程序并与后端交互的web开发者准备的。作者Jesse Cravens和Thomas Q. Brady通过实践引导读者了解Ember.js的核心特性。书中通过一个实例——名为"Rock'n'Roll Call"的音乐家索引应用的原型开发，逐步讲解了Ember.js的应用。在这个过程中，读者将学习到： 1. **路由（Routers）**：Ember.js中的路由负责管理应用程序的不同状态，创建URL与特定视图之间的映射，使应用程序具有可导航性。 2. **模板（Templates）**：Ember.js采用Handlebars作为模板引擎，允许开发者编写声明式代码来表示数据如何呈现。通过Handlebars，可以创建动态和响应式的用户界面。 3. **模型（Models）**：模型是应用程序的数据层，用于封装和管理业务逻辑。Ember的数据绑定机制使得模型和视图之间的数据同步变得简单。 4. **控制器（Controllers）**：控制器作为模型和视图之间的中间人，处理用户输入并更新视图。它们也可以扩展模型的属性和方法。 5. **视图（Views）**：视图负责渲染模板，并处理用户交互。它们与控制器协作，更新UI并发送用户事件。 6. **Ember的约定优于配置（Convention Over Configuration, CoC）**：Ember.js遵循一套明确的约定，减少了开发者需要编写的代码量，提高了开发效率。例如，文件结构、命名规范等都有预设的约定。此外，书籍还涵盖了工作流管理、样板代码的创建，以及如何利用Ember的"开发者体验"（Developer Ergonomics）写出更简洁的代码。通过学习这些内容，开发者能够更好地掌握Ember.js，构建出表现如同桌面软件的生产级Web应用，同时了解如何与各种后端技术集成，如API接口的使用和数据持久化策略。《Building Web Apps with Ember.js》是一本全面介绍Ember.js的书籍，对于想要提升JavaScript应用开发技能，特别是对构建高性能、响应式Web应用感兴趣的开发者来说，是一份宝贵的学习资料。

www.it-ebooks.info

MobileMe) applications to check your email, locate and even remotely disable your

phone with “Find My Phone,” or, most recently, create Pages, Numbers, or Keynote

documents on the Web, you’ve used SproutCore. These are great examples of ambi‐

tious web applications: ones that look and act like desktop applications, but happen to

be delivered via web technologies.

Such applications differ from much of web development in several important ways.

Ambitious Web Applications Are Not Documents

We tend to think that any sentence that starts with, “When Tim Berners-Lee” can be

safely ignored, unless written by Sir Berners-Lee, but this time you’ll just have to trust

us. When Sir Tim Berners-Lee created the World Wide Web, he was pretty clear

about the use case he was building for. The backbone of his invention was the Hyper‐

text Transport Protocol (HTTP). He was creating a better way to share documents. In

his own words, he was “thinking about all the documentation systems out there as

being possibly part of a larger imaginary documentation system.” This powerful tech‐

nology allowed a browser to turn a URL, provided by the user, into a unique address

to a server, which could be located anywhere in the world, and even to a specific

document on that server, which could then be retrieved and rendered for the user.

Browsing a site like Wikipedia is a canonical example of this model. When you click a

link on a Wikipedia page or search for an entry on the site, the browser sends a re‐

quest to load a new document—from a new URL. The entire page is replaced with the

new content, and the URL shown to the user in the address bar changes. Although

this is still a remarkable feat, it bears little resemblance to the expectations of a

modern “web application.” In the years since the birth of the Web, we’ve come to ex‐

pect a lot from desktop applications, from real-time data manipulations to eye-

catching renderings and animations. In recent years, we’ve come to expect “web ap‐

plications” to be no different.

Ambitious Web Applications Are Stateful

By design, the building blocks of the Web are stateless. “State,” for our purposes any‐

way, refers to data that changes and must be persisted in your application. For in‐

stance, if your user has checked a checkbox in your web form, you don’t want to un‐

check that checkbox accidentally, just because you’ve forgotten. You want to remem‐

ber that the state in which you found the checkbox last was “checked,” and that it

should stay that way until a legitimate reason for it to change—the user clicks it again,

or some logical scenario requires it be toggled or unchecked—comes along. Since

HTTP is a stateless protocol, there’s nothing being passed back and forth between

your browser and the server that describe this sort of state data. If you’re simply navi‐

gating from document to document, no state is necessary. If you’re building an appli‐

cation, however, you need to know things such as:

2 | Chapter 1: Introducing Ember.js and Ambitious Web Applications

www.it-ebooks.info

• Is this user logged in?

• Has this order been placed?

• Has this message been sent?

Over the years, web developers have figured out a number of hacks for persisting

state across sessions, using protocols that weren’t designed to enable such a thing.

We’ve used URL-encoded state variables, cookies, and the like to keep track of what

the user has done and is doing across multiple HTTP requests.

Those of us old enough to have used the Web in those days remember the pain of

typing in a long expense report, email, blog post, or some more important document,

only to have it disappear into the ether(net) when one of these state-persistence hacks

failed. Until we filled this gap in the Web’s feature set, it would remain a document-

delivery platform. When we’d truly solved this problem, the Web became an applica‐

tion platform. The solution to this problem was the XMLHTTPRequest, or XHR, a nigh-

magical new capability that allowed your application logic to request data from or

send data to the server without itself being unloaded and reloaded.

Microsoft gets a lot of flak from the web-development community, mostly for the sins

visited on the world in the form of Internet Explorer versions previous to 8. To be

sure, there were some serious oversights in those software releases. However, Micro‐

soft is responsible, at least in part, for several of the Web’s biggest advancements. In‐

ternet Explorer 5.0 for the Macintosh was the first browser to fully support CSS, for

instance. It was also Microsoft that invented the XHR.

The XHR abstracts the very soul of the browser; it allows JavaScript to make an

HTTP request, just as the browser did historically, and deal directly with the re‐

sponse. This puts JavaScript—thereby, the JavaScript developer, not the browser itself

—in control of the user experience. The user can enter a URL, such as http://

mail.google.com, into the browser’s address bar, and the browser will load the Gmail

application. From then on, the Gmail application’s JavaScript code is able to make ad‐

ditional HTTP requests to acquire more data—individual email documents, attach‐

ments, updated copies of the user’s address book, and gobs more—without reloading

the page. If you don’t need to reload the page, it’s not necessary to jump through as

many hoops to preserve state. Much has been written about how this made the Web

more responsive, how it made web applications look and act more like desktop soft‐

ware. Gmail and Google Maps dazzled us with their desktop-grade experience and

performance. Crucially, though, the XHR had the subtle effect of gaining our trust in

the Web as a platform for application delivery.

With XHR, when a user hits “send” in an email application, for instance, the applica‐

tion can fire off a request to deliver the email data to the server. If this XHR fails, the

page and all its data—including the email the user has written—remain on the page

and in memory. The application can simply try again to deliver the data. This, in our

What Is an “Ambitious Web Application”? | 3

www.it-ebooks.info

opinion, fundamentally changed the Web. In combination with its newfound perfor‐

mance, this reliability made the Web a “real” application platform.

The trouble, then, became managing all the state that was not being flushed with reg‐

ular page reloads.

Ambitious Web Applications Are Long-Lived

Modern web applications are now long-lived, meaning the application could be open

in a browser instance for hours at a time without reloading the page. The upside, as

we’ve celebrated, is that you can load gobs of additional data from the server without

having to reload your application every time. The downside is that you now have to

manage those gobs of data. If you simply keep adding data without releasing any of it,

you will fill up your RAM in short order, locking up the browser and showing your

user a “busy” cursor.

Ember, through features and through conventions, helps you take advantage of long-

lived application development while avoiding memory leaks. Ember’s view manage‐

ment automatically cleans up unused variables and bindings for you as views are

shown and hidden. Ember’s conventions for navigating from one view to another also

encourage you to pass objects from one to another, saving you the trip to the server to

reload data for a particular view, if it has already been loaded, and saving you from

inadvertently having two or more copies of the same object in memory.

And potential memory leaks aren’t the only challenge. The kind of application that

sticks around for several hours won’t likely all fit within a jQuery ready callback.

Without some smart structure to your codebase, adding and maintaining features

that could be used at any time and repeatedly can become quite difficult.

What’s in a Name?

So, imagine you’re a web developer in 2005, and you’ve decided you want to use XHR

to completely overhaul the web-based software you develop at work. You’re going to

be in a lot of meetings with lots of people who would not describe themselves as tech

savvy, attempting to convince them to allow you to extend deadlines, hire more devel‐

opers, and redesign user interfaces because of this new feature available to you. You

click your presentation remote, and a slide appears in front of the room that says,

“Extensible Markup Language (XML) Hypertext Transport Protocol (HTTP) Request,

or XHR.” OK, it actually takes two slides, but you never get to the second slide be‐

cause there are too many questions, and you get interrupted too many times by stake‐

holders trying to sound smart by yelling their own explanations of how “the Internet

is a series of tubes” over you.

If you were Jesse James Garrett, this didn’t happen to you, because you instead came

up with a catchy, clever explanation of the technology and wrote an article entitled

4 | Chapter 1: Introducing Ember.js and Ambitious Web Applications

www.it-ebooks.info

剩余186页未读，继续阅读

Johnshi1

粉丝: 0
资源: 9

使用Ember.js构建Web应用实战

Ember.js.Web.Development.with.Ember.

Deliver.Audacious.Web.Apps.with.Ember2

大学生职业生涯规划书Word模板范文就业求职简历应聘工作PPT医疗康复专业

基于Java的学生信息管理系统的实现与操作

基于单片机控制的填块切割装置的设计_孟紫腾.pdf

ImageNet-1K数据集索引和对应的中英文表单

B站叫叫兽粉丝专属-YOLOv11改进免费送

400w微型逆变器, 基于stm32g474实现 设计方案，不是成品 带有源代码、原理图(AD)、PCB(AD)

全球与中国清洁型漱口水市场现状及未来发展趋势（2024版）.docx

新文科建设赋能地方高校汉语言文学师范生培养的思考.pdf

最新资源

400w微型逆变器, 基于stm32g474实现设计方案，不是成品带有源代码、原理图(AD)、PCB(AD)