Home >CMS Tutorial >WordPress >Embracing the Embers: Part 4
In my previous tutorial, I introduced how to use Ember.Object
to define models and work with datasets. In this section, we'll take a closer look at how Ember uses the Handlebars template framework to define your app's user interface.
Most server-side developers are accustomed to using templates to define tags that will be dynamically populated. If you've ever used ASP.NET, ColdFusion, PHP, or Rails, you definitely know what I'm talking about.
JavaScript client-side templates have really started to gain popularity recently, especially because of its focus on building more desktop-like experiences. This means that more processing is done on the client side, and data is primarily pulled through server-side API requests.
I remember writing about client-side templates not too long ago when the jQuery template plugin was first released. Nearly three years later, it's still the most read post on my blog, showing just how high interest in client-side templates is. Since then, many other frameworks have been released, providing rich features and supporting communities. Handlebars is one of the more popular options and is the framework chosen by the Ember project for its templating needs. This makes sense since Handlerbars was created by Ember.js co-founder and core team member Yehuda Katz. But please note that I'm not going to do a comparison between template frameworks, I'm going to focus strictly on Handelbars since that's what Ember.js uses by default.
In the previous article, I showed some very basic templates in code:
<script type="text/x-handlebars"> <h2><strong>{{firstName}} {{lastName}}</strong></h2> </script>
Two things that stand out are the script tag's type declaration and the curly braces, which act as delimiters for expressions that Handlebars will act on. This is very typical syntax, which I will discuss in detail shortly, and which you will use consistently when building Ember templates.
Although Handlebars use special syntax, at the end of the day you're actually mostly using standard HTML markup. Handlebars are used to inject content into this tag to present the data to the user. It does this by parsing the delimited expression and replacing it with the data you asked Handlebars to use. For Ember, Handlebars provides hooks and Ember uses them. This data usually comes from your controller (remember, the controller acts as the interface to the model).
The first thing any template needs is a script tag definition. Most of you have probably defined script tags to load JavaScript libraries. In fact, you've already done this, loading Handlebars into your Ember project:
<script src="js/libs/jquery-1.9.1.js"></script> <script src="js/libs/handlebars-1.0.0-rc.3.js"></script> <script src="js/libs/ember-1.0.0-rc.1.js"></script> <script src="js/app.js"></script>
Slightly different than using it to define templates. First, we specify the type
attribute of "text/x-handlebars". The browser ignores this type
, but leaves the text available for inspection and allows Ember to recognize the template within the application. Additionally, Ember uses a data attribute called "data-template-name" that Ember can use to associate specific parts of the application with templates. For example, the following declaration defines a template named "employee":
<script type="text/x-handlebars" data-template-name="employee"> ... </script>
When your application starts, Ember scans the DOM for type="text/x-handlebars
, compiles the templates it finds, and stores them in a property of the Ember object , the property is named Ember.TEMPLATES
and use it to find out what is rendered for a given route. This is why it is so important to follow Ember's naming convention. In the example above, this template will automatically be associated to the employee routes and controllers you create in your application. Again, I can't stress too much how these naming conventions will make your development easier.
Ember relies on the URL to determine the resources to use and the templates to render. Let's say you have a profile page with the URL "/profile". You'll have a resource called profile
that will load resources specific to that URL (like a route object), and you'll also have a template with the same name. We reviewed defining resources and routing objects in Part 2 of the Ember series, so if you're not sure what I'm talking about, be sure to jump back there and refresh your knowledge.
When you visit that URL, Ember knows it needs to load these resources and parse the templates you defined. It does this through its naming convention, knowing that because you go to "/profile" it needs to load the resource defined in profile
and render it named data-template-name=" profile"
template.
Looking at the naming convention again, you'll see that routes, controllers, and templates are all tied together with the same URL name, but the template is spelled in lowercase. This allows Ember to manage everything behind the scenes without having to do a lot of wiring.
还需要注意的是,如果您声明的模板没有 data-template-name
属性,Ember 将假定它是应用程序范围的模板 - 通常用作站点范围模板来创建用户界面元素,例如页眉、页脚和导航。如果您没有为应用程序甚至资源(例如 URL)显式定义模板,Ember 会自动为您执行此操作,以确保应用程序的稳定性和一致性。
下一步是包含您的标记和用于表示数据的分隔表达式。表达式通过双花括号进行分隔,这使得它们可以通过从控制器传递的数据轻松识别和解析。这是一个例子:
<script type="text/x-handlebars"> <h2><strong>{{firstName}} {{lastName}}</strong></h2> </script>
在这种情况下,{{firstName}}
和 {{lastName}}
表达式将被 Ember 解析并替换为实际数据。此外,Ember 设置了观察者,以便当您的数据发生变化时,您的模板会自动更新,并将更新反映给应用程序的用户。
到目前为止,我已经向您展示了一个非常简单的示例,但要点是:
这为您构建用户界面的方式提供了很大的灵活性。让我们继续看看可用的功能。
请记住,Ember 利用了 Handlebars,因此您可以在此处访问其完整的表达式。为了使几乎任何东西变得有用,条件表达式是必须的;车把提供了相当多的选择。
假设我有一个如下所示的 JSON 数据集:
"items": [{ "title": "Tearable Cloth Simulation in JavaScript", "url": "http://codepen.io/stuffit/pen/KrAwx", "id": 5592679, "commentCount": 20, "points": 127, "postedAgo": "1 hour ago", "postedBy": "NathanKP" }, { "title": "Netflix now bigger than HBO", "url": "http://qz.com/77067/netflix-now-bigger-than-hbo/", "id": 5592403, "commentCount": 68, "points": 96, "postedAgo": "2 hours ago", "postedBy": "edouard1234567" }
如果我想确保 title
数据可用,我可以使用 #if
表达式添加条件“if”语句:
{{#if item.title}} <li>{{item.title}} - {{item.postedAgo}} by {{item.postedBy}}</li> {{/if}}
这会检查 item.title
是否未定义,并继续处理 title
、postedAgo
和 postedBy
数据表达式的后续表达式。
由于该数据集包含多个“记录”,因此可以安全地假设我们可能希望循环 item
的每个元素。这就是 {{#each}}
表达式发挥作用的地方。它允许您枚举对象列表。因此,再次记住模板是标记和 Handlebars 表达式的组合,我们可以使用 #each
表达式来循环遍历 Ember 模型对象中可用的每个项目。请记住,Ember 模型是从控制器派生的,控制器通过 Ember 的命名约定与模板关联。
<ul> {{#each item in model}} {{#if item.title}} <li>{{item.title}} - {{item.postedAgo}} by {{item.postedBy}}</li> {{/if}} {{/each}} </ul>
这会渲染出类似于以下内容的内容:
<ul> <li>Tearable Cloth Simulation in JavaScript - 1 hour ago by NathanKP</li> <li>Netflix now bigger than HBO - 2 hours ago by edouard1234567</li> <li>Fast Database Emerges from MIT Class, GPUs and Student's Invention - 33 minutes ago by signa11</li> <li> Connecting an iPad retina LCD to a PC - 6 hours ago by noonespecial</li> </ul>
显着的优势是 Ember 隐含的观察者规范,它将在更新时更新您的数据。
如果您的条件表达式需要更复杂,您将需要创建一个计算属性。这允许您基于可以将复杂代码条件应用于数据的方法创建属性。假设我只想显示标题为“JavaScript 中的可撕裂布料模拟”的数据。我需要设置几件事:
我需要做的第一件事是创建新的控制器,它将包装循环的每个项目并在其中创建计算属性:
App.TitleController = Ember.ObjectController.extend({ titleMatch: function() { return this.get('title') === "Tearable Cloth Simulation in JavaScript"; }.property() });
查看代码,我们对 Ember.ObjectController
进行子类化以创建控制器。这是控制器,它将包装模板中循环的每个项目。接下来,我们创建一个名为 titleMatch
的方法,它使用 get()
方法来拉回当前标题,将其与我定义的文本进行比较,然后返回一个布尔值。最后,调用 Ember property() 方法将 titleMatch 方法定义为计算属性。
完成此操作后,我们将更新模板的 {{#each}}
表达式,以使用我们创建的新控制器来表示每个项目。这是通过使用 itemController 指令来完成的。需要理解的关键一点是 itemController
是 Ember 中的一个关键短语,旨在将控制器与模板的项目关联起来。不要将其与实际的控制器名称混淆(就像我最初所做的那样)。控制器名称分配给 itemController
,如下所示:
<ul> {{#each item in model itemController="title"}} {{#if titleMatch}} <li>{{foo.title}} - {{foo.postedAgo}} by {{foo.postedBy}}</li> {{/if}} {{/each}} </ul>
同样,命名约定规定,在模板中分配名称时,我们使用小写。在本例中,我们将 TitleController
分配给 itemController
。
现在,当循环每个项目时,计算属性 titleMatch
用于评估标题并在匹配时显示数据。
创建动态模板不仅仅是吐出文本。有时,UI 的外观需要受到正在处理的数据的影响。显示图像或建立链接就是很好的例子。
将数据绑定到元素需要使用特殊的 Ember 助手来帮助定义属性的上下文,并确保在数据更改时正确更新属性。对于元素属性,{{bindAttr}}
帮助器用于填充属性的值。如果我们需要动态指定图像的 URL,我们将使用以下语法:
<img {{bindAttr src="logoUrl"}} alt="Embracing the Embers: Part 4">
对于不接收值的属性也可以这样做,例如disabled
:
<input type="checkbox" {{bindAttr disabled="isAdministrator"}}>
在这种情况下, isAdminstrator
可以是基于控制器中的方法的计算属性,或者只是一个普通的对象属性,为您在定义禁用复选框的条件方面提供了很大的灵活性。这种灵活性也适用于定义类名。如果我想使用条件语句来定义是否应将类应用于我的元素,我可以使用以下代码:
<div {{bindAttr class="isUrgent"}}> Warning! </div>
根据布尔状态,我的标记将是:
<div {{bindAttr class="is-urgent"}}> Warning! </div>
对于 true
条件,或:
<div> Warning! </div>
对于 false
条件。请注意,当我为该类指定 isUrgent
时,Ember 对该名称进行了 dasher 处理,并将该类呈现为 is-urgent
。如果您希望根据结果指定自己的类,可以使用类似于三元语句的条件表达式:
<div {{bindAttr class="isUrgent:urgent:normal"}}>
这将根据 isUrgent
的条件值返回该类的 urgent
或 normal
。
模板将成为用户界面的基础,因此花时间阅读 Ember 和 Handlebars 站点上的文档以充分了解它们的整体功能非常重要。即使您不使用 Ember,Handlebars 也是一个适合您日常使用的出色框架,并且值得投资学习如何使用它。
Gabriel Manricks 在 Nettuts+ 上编写了一篇关于 Handlebars 的精彩教程,您可以使用它来加快框架的速度。
The above is the detailed content of Embracing the Embers: Part 4. For more information, please follow other related articles on the PHP Chinese website!