iSharkFly-Docs
/
angular-docs-cn
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

docs(core): fix some typos

This commit is contained in:
Gerd Jungbluth 2015-02-14 20:06:20 +01:00 committed by Misko Hevery
parent 08850a579b
commit 4d1254d6df
4 changed files with 89 additions and 89 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

86
modules/angular2/docs/core/01_templates.md
View File

@ -4,16 +4,16 @@ Templates are markup which is added to HTML to declarativly describe how the app
projected to DOM as well as which DOM events should invoke which methods on the controller. Templates contain
syntax which is core to Angular and allows for data-binding, event-binding, template-instantiation.
The design of template syntax has these properties:
The design of the template syntax has these properties:
* All data-binding expressions are easily identifiable. (i.e. there is never an ambiguity wether the value should be
* All data-binding expressions are easily identifiable. (i.e. there is never an ambiguity whether the value should be
interpreted as string literal or as an expression.)
* All events and their statements are easily identifiable.
* All places of DOM instantiation are easily identifiable.
* All places of variable declaration is esily identifiable.
* All places of variable declaration is easily identifiable.
The above properties guarantee that the templates are easy to parse by tools (such as IDEs) and reason about by people.
At no point is it necessary to understand which directives are active and what are their symantics in order to reason
The above properties guarantee that the templates are easily to be parsed by tools (such as IDEs) and reasoned about by people.
At no point is it necessary to understand which directives are active and what are their semantics in order to reason
about the template runtime characteristics.
@ -21,7 +21,7 @@ about the template runtime characteristics.
## Summary
Below is a summary of the kinds of syntaxes which Angular templating supports. The syntaxes are explained in more
detail in following sections.
detail in the following sections.
<table>
<thead>
@ -222,7 +222,7 @@ Example:
## Property Binding
Binding application model data to the UI, is the most common kinds of bindings in an Angular application. The bindings
Binding application model data to the UI is the most common kind of bindings in an Angular application. The bindings
are always in the form of `property-name` which is assigned an `expression`. The generic form is:
<table>
@ -253,21 +253,21 @@ its value.
Key points:
* The binding is to the element property not the element attribute.
* To prevent custom element from accidentaly reading the literal `expression` on the title element, the attribute name
is escaped. In our case the `title` is escaped to `[title]` through the addition of squre brackets `[]`.
* To prevent custom element from accidentally reading the literal `expression` on the title element, the attribute name
is escaped. In our case the `title` is escaped to `[title]` through the addition of square brackets `[]`.
* A binding value (in this case `user.firstName` will always be an expression, never a string literal)
NOTE: Unlike Angular v1, Angular v2 binds to properties of elements rather than attributes of elements. This is
done to better support custom elements, and allow binding for values other than strings.
done to better support custom elements, and to allow binding for values other than strings.
NOTE: Some editors/server side pre-processors may have trouble generating `[]` arround the attribute name. For this
NOTE: Some editors/server side pre-processors may have trouble generating `[]` around the attribute name. For this
reason Angular also supports a canonical version which is prefixed using `bind-`.
### String Interpolation
Property bindings are the only data bindings which angular supports, but for convenience Angular supports interpolation
Property bindings are the only data bindings which Angular supports, but for convenience Angular supports an interpolation
syntax which is just a short hand for the data binding syntax.
```
@ -280,7 +280,7 @@ is a short hand for:
<span [text|0]=" 'Hello ' + stringify(name) + '!' ">_</span>
```
The above says to bind `'Hello ' + stringify(name) + '!'` expression to the zero-th child of the `span`'s `text`
The above says to bind the `'Hello ' + stringify(name) + '!'` expression to the zero-th child of the `span`'s `text`
property. The index is necessary in case there are more than one text nodes, or if the text node we wish to bind to
is not the first one.
@ -302,7 +302,7 @@ keeping `null` and `undefined` as empty strings.
## Local Varibles
## Local Variables
@ -311,7 +311,7 @@ keeping `null` and `undefined` as empty strings.
Data binding allows updating the DOM's properties, but it does not allow for changing of the DOM structure. To change
DOM structure we need the ability to define child templates, and then instantiate these templates into Views. The
Views can than be inserted and removed as needed to change the DOM structure.
Views than can be inserted and removed as needed to change the DOM structure.
<table>
<tr>
@ -347,7 +347,7 @@ Where:
templates which have more than one root DOM node.
* `instantiating-directive` is required for templates. The instantiating directive is responsible for deciding when
and in which order should child views be inserted into this location. An instantiating directive usually has one or
more bindings and can be represnted as either `instantiating-directive-bindings` or
more bindings and can be represented as either `instantiating-directive-bindings` or
`instantiating-directive-microsyntax` on `template` element or attribute. See template microsyntax for more details.
@ -355,33 +355,33 @@ Example of conditionally included template:
```
Hello {{user}}!
<div template="if: isAdimnistrator">
<div template="if: isAdministrator">
...administrator menu here...
</div>
```
In the above example the `if` instantiator determins if the child view (an instance of the child template) should be
inserted into ther root view. The `if` makes this decision based on if the `isAdimnistrator` binding is true.
In the above example the `if` instantiator determines whether the child view (an instance of the child template) should be
inserted into the root view. The `if` makes this decision based on if the `isAdministrator` binding is true.
The above example is in the shart form, for better clarity let's rewrite it in the canonical form, which is functionaly
The above example is in the short form, for better clarity let's rewrite it in the canonical form, which is functionally
identical.
```
Hello {{user}}!
<template [if]="isAdimnistrator">
<template [if]="isAdministrator">
<div>
...administrator menu here...
</div>
</template>
```
NOTE: Only Instantiator directives can be placed on the template element. (Decorators, and Components are not allowed.)
NOTE: Only Instantiator directives can be placed on the template element. (Decorators and Components are not allowed.)
### Template Microsyntax
Often times it is necessary to encode a lot of different bindings into a template to control how the instantiation
of the templates occurs. One such example is foreach.
of the templates occurs. One such example is `foreach`.
```
<form #foo=form>
@ -408,7 +408,7 @@ syntax is preferable.
</ul>
```
Notice how each key value pair is translated to `key=value;` statement in the `template` attribute. This makes the
Notice how each key value pair is translated to a `key=value;` statement in the `template` attribute. This makes the
repeat syntax a much shorter, but we can do better. Turns out that most punctuation is optional in the short version
which allows us to further shorten the text.
@ -427,8 +427,8 @@ microsyntax for `foreach`.
</ul>
```
The format is intentionally defined freely, so that developers of directives can build expressive microsyntax for
their directives. Following describes a more formal definition.
The format is intentionally defined freely, so that developers of directives can build an expressive microsyntax for
their directives. The following code describes a more formal definition.
```
expression: ... // as defined in Expressions section
@ -441,14 +441,14 @@ microsyntax: ([[key|keyExpression|varExport][;|,]?)*
```
Where
* `expression` is an angular expression as defined in section: Expressions
* `expression` is an Angular expression as defined in section: Expressions
* `local` is a local identifier for local variables.
* `internal` is an internal variable which the directive exports for binding.
* `key` is an attribute name usually only used to trigger a specific directive.
* `keyExpression` is an property name to which the epression will be bound to.
* `varExport` allows exporting of directive internal state as variables for further binding. If no `internal` name
is specified than the exporting is to an implicit variable.
* `microsyntax` allows you to build simple microsyntax which can still clearly identify which expressions bind to
* `keyExpression` is an property name to which the expression will be bound to.
* `varExport` allows exporting of a directive internal state as variable for further binding. If no `internal` name
is specified, the exporting is to an implicit variable.
* `microsyntax` allows you to build a simple microsyntax which can still clearly identify which expressions bind to
which properties as well as which variables are exported for binding.
@ -527,7 +527,7 @@ have different semantics.
### Expressions
Expressions can be used to bind to a properties only. Expressions represent how data should be projected to the View.
Expressions can be used to bind to properties only. Expressions represent how data should be projected to the View.
Expressions should not have any side effects and should be idempotent. Examples of where expressions can be used in
Angular are:
```
@ -537,19 +537,19 @@ Angular are:
<div template="if: expression">...</div>
```
Expressions are simplified version of expression in the language in which you are writing your application. (i.e.
Expressions are a simplified version of an expression in the language in which you are writing your application. (i.e.
expressions follow JS syntax and semantics in JS and Dart syntax and semantics in Dart). Unlike expressions in the
language, binding expressions behave differently in following ways:
language, binding expressions behave differently in the following ways:
* *Must be defined*: Unlike Angular v1, Angular v2 will throw an error on dereferencing fields which are not defined.
For example: `user.name` will throw an error if `user` is defined but it does not have `name` property. If the `name`
property is not known, it must be declared and set to some value such as empty string, `null` (or `undefined` in JS).
For example: `user.name` will throw an error if `user` is defined but it does not have a `name` property. If the `name`
property is not known, it must be declared and set to some value such as an empty string, `null` (or `undefined` in JS).
This is done to allow early detection of errors in the templates.
* *Safe dereference*: Expressions `user.name` where `user` is null will throw `NullPointerException` in the language.
* *Safe dereference*: Expression `user.name` where `user` is `null` will throw a `NullPointerException` in the language.
In contrast Angular will silently ignore `null` on `user`. This is done because Views often have to wait for the data
to arrive from the backend and many fields will be `null` until the data arrives. Safe dereference is so common in the
Views, that we have made it the default.
* *Single expression*: An expression must be a single statemnet. (i.e. no `;`)
Views that we have made it the default.
* *Single expression*: An expression must be a single statement. (i.e. no `;`)
* *No assignments*: Binding expressions can not contain assignments.
* *No keywords*: Binding expressions can not contain keywords such as: `var`, `if`, and so on.
* *Formatters*: Angular expressions can be piped through formatters to further transform the binding value.
@ -567,8 +567,8 @@ class Greeter {
* `name` : Will result in the value of the `name` property on the `Greeter` class.
* `name.length`: Will result in either the length of the `name` string or `undefined` (`null` in Dart) if `name`
property is `null` or `undefined`. Example of: safe dereference.
* `foo`: Will thrown on error because `foo` is not declared on the `Greeter` class. Example of: Must be defined
* `name=1`: Not allowed because fo assignment.
* `foo`: Will throw an error because `foo` is not declared on the `Greeter` class. Example of: Must be defined
* `name=1`: Not allowed because of assignment.
* `name; name.length`: Not allowed because of multiple statements.
@ -584,10 +584,10 @@ Examples of where statements can be used in Angular are:
Statements are similar to statements in the language in which you are writing your application. (i.e.
statements follow JS syntax and semantics in JS and Dart syntax and semantics in Dart). Unlike statements in the
language, binding expressions behave differently in following ways:
language, binding expressions behave differently in the following ways:
* *Unsafe dereference*: Expressions `user.verify()` where `user` is `null` will throw `NullPointerException` in the
language as well as in statements. (In contrast to Safe dereference in Angular expressions.) While angular protects
language as well as in statements. (In contrast to Safe dereference in Angular expressions.) While Angular protects
you from null dereferencing in expressions due to lazy loading of data, no such protection is required for statements,
and doing so would make it harder to detect typos in statements.
* *Multiple statements OK*: Statements can be composed from more than one statement. (i.e. no `doA(); doB()`)

50
modules/angular2/docs/core/02_directives.md
View File

@ -1,16 +1,16 @@
# Directives
Directives are classes which get instantiated as a respones to a particular DOM strcture. By controlling the DOM stracture, what directives are imported, and their selectors, the developer can use the [composition pattern](http://en.wikipedia.org/wiki/Object_composition) to get desirable application behavior.
Directives are classes which get instantiated as a response to a particular DOM structure. By controlling the DOM structure, what directives are imported, and their selectors, the developer can use the [composition pattern](http://en.wikipedia.org/wiki/Object_composition) to get a desirable application behavior.
Directives are the cornerstone af Angular application. We use Directives to break complex problems into smaller more reusable components. Directives, allow the devolper turn HTML into a DSL and than controll the application assembly process.
Directives are the cornerstone of an Angular application. We use Directives to break complex problems into smaller more reusable components. Directives allow the developer to turn HTML into a DSL and then control the application assembly process.
Angular applications do not have a main method. Instead they have a root Component. Dependency Injection than assembles the directives into a working Angular application.
Angular applications do not have a main method. Instead they have a root Component. Dependency Injection then assembles the directives into a working Angular application.
There are three different kinds of directives (described in mored detailed in later sections).
There are three different kinds of directives (described in more detail in later sections).
1. *Decorators*: can be placed on any DOM element and can be combined with other directives.
2. *Components*: Components have encapsulated view and can configure injectors.
3. *Viewport*: Is responsible for adding or removing child views in parent view. (i.e. foreach, if)
2. *Components*: Components have an encapsulated view and can configure injectors.
3. *Viewport*: is responsible for adding or removing child views in a parent view. (i.e. foreach, if)
@ -27,10 +27,10 @@ Angular supports these CSS selector constructs:
* AND operation: `name[attribute]`
* OR operation: `name,.class`
Angular does not support these (and any CSS selector which crosses element boundries):
Angular does not support these (and any CSS selector which crosses element boundaries):
* Descendant: `body div`
* Direct descendant: `body > div`
* Adjascent: `div + table`
* Adjacent: `div + table`
* Sibling: `div ~ table`
* Wildcard: `*`
* ID: `#id`
@ -62,7 +62,7 @@ The simplest kind of directive is a decorator. Directives are usefull for encaps
* Decorators do not introduce new evaluation context.
* Decorators are registered througt the `@Decorator` meta-data annotation.
Here is a triavial example of tooltip decorator. The directive will log a tooltip into the console on every time mouse enters a region:
Here is a trivial example of a tooltip decorator. The directive will log a tooltip into the console on every time mouse enters a region:
```
@Decorator({
@ -88,9 +88,9 @@ Example of usage:
```<span tooltip="Tooltip text goes here.">Some text here.</span>```
The developer of an applacation can now freely use the `tooltip` attribute wherever the behavior is needed. The code above has taught the browser a new reusable and declarative bahavior.
The developer of an application can now freely use the `tooltip` attribute wherever the behavior is needed. The code above has taught the browser a new reusable and declarative behavior.
Notice that databinding will work with this decorator with no further effort as show below.
Notice that data binding will work with this decorator with no further effort as shown below.
```<span tooltip="Greetings {{user}}!">Some text here.</span>```
@ -101,7 +101,7 @@ Notice that databinding will work with this decorator with no further effort as
Component is a directive which uses shadow DOM to create encapsulate visual behavior. Components are tipically used to create UI widgets or to break up the application into smaller components.
* Only one component can be present per DOM element.
* Components CSS selectors usualy trigger on element names. (Best practice)
* Component's CSS selectors usually trigger on element names. (Best practice)
* Component has its own shadow view which is attached to the element as a Shadow DOM.
* Shadow view context is the component instance. (i.e. template expressions are evaluated against the component instance.)
@ -138,7 +138,7 @@ class Pane { | Component controller class
`pane.html`:
```
<div class="outter">
<div class="outer">
<h1>{{title}}</h1>
<div class="inner" [hidden]="!visible">
<content></content>
@ -148,7 +148,7 @@ class Pane { | Component controller class
`pane.css`:
```
.outter, .inner { border: 1px solid blue;}
.outer, .inner { border: 1px solid blue;}
.h1 {background-color: blue;}
```
@ -165,11 +165,11 @@ Example of usage:
## Viewport
Viewport is a directive which can controll instantiation of child views which are then inserted into the DOM. (Examples are `if` and `foreach`.)
Viewport is a directive which can control instantiation of child views which are then inserted into the DOM. (Examples are `if` and `foreach`.)
* Viewports can only be placed on `<template>` elements (or the short hand version which uses `<element template>` attribute.)
* Only one viewport can be present per DOM template element.
* The viewport is is created over the `template` element. This is known as the `ViewContainer`.
* The viewport is created over the `template` element. This is known as the `ViewContainer`.
* Viewport can insert child views into the `ViewContainer`. The child views show up as siblings of the `Viewport` in the DOM.
>> TODO(misko): Relationship with Injection
@ -209,20 +209,20 @@ export class If {
## Dependency Injection
Dependency Injection (DI) is a key aspect of directives. DI allows directives to be assembled into different [compositional](http://en.wikipedia.org/wiki/Object_composition) hieranchies. Angular encourages [composition over inheritance](http://en.wikipedia.org/wiki/Composition_over_inheritance) in the application design (but inheritance based approaches are still supported).
Dependency Injection (DI) is a key aspect of directives. DI allows directives to be assembled into different [compositional](http://en.wikipedia.org/wiki/Object_composition) hierarchies. Angular encourages [composition over inheritance](http://en.wikipedia.org/wiki/Composition_over_inheritance) in the application design (but inheritance based approaches are still supported).
When Angular directives are instantiated, the directive can ask for other related directives to be injected into it. By assembing the directives in different order and subtypes the application behavior can be controlled. A good mental model is that DOM structure controlles the directive instantiation graph.
When Angular directives are instantiated, the directive can ask for other related directives to be injected into it. By assembling the directives in different order and subtypes the application behavior can be controlled. A good mental model is that the DOM structure controls the directive instantiation graph.
Directive instantiation is triggered by the directive CSS selector matching the DOM structure. The directive in its constructor can ask for other directives or application services. When asking for directives the dependency is locating by following the DOM hieranchy and if not found using the application level injector.
Directive instantiation is triggered by the directive CSS selector matching the DOM structure. The directive in its constructor can ask for other directives or application services. When asking for directives the dependency is locating by following the DOM hierarchy and if not found using the application level injector.
To better understand the kinds of injections which are supported in Angular we have broken them down into use case examples.
### Injecting Services
Service injection is the most straight forward kind of injection which Angular supports. It involves a component configureing the `componentServices` and than letting the directive ask for the configured service.
Service injection is the most straight forward kind of injection which Angular supports. It involves a component configuring the `componentServices` and then letting the directive ask for the configured service.
This example ilustrates how to inject `MyService` into `House` directive.
This example illustrates how to inject `MyService` into `House` directive.
```
@ -252,7 +252,7 @@ class House { |
Assume the following DOM structure for `my_app.html`:
```
<div house> | The house attribute triggers the creation of House directive.
<div house> | The house attribute triggers the creation of the House directive.
</div> | This is equivalent to:
| new House(injector.get(MyService));
```
@ -264,13 +264,13 @@ Injecting other directives into directives follows a similar mechanism as inject
There are five kinds of visibilities:
* (no annotation): Inject a directives only if it is on the curent element.
* (no annotation): Inject a directives only if it is on the current element.
* `@ancestor`: Inject a directive if it is at any element above the current element.
* `@parent`: Inject a directive which is direct parent of the current element.
* `@child`: Inject a list of direct children which match a given type. (Used with `Query`)
* `@descendant`: Inject a list of any children which match a given type. (Used with `Query`)
NOTE: if the injection constraint can not be satisfied by the current visibility constraint, than it is forward to normal injector which may provide a default value for the directive or it may throw an error.
NOTE: if the injection constraint can not be satisfied by the current visibility constraint, then it is forward to the normal injector which may provide a default value for the directive or it may throw an error.
Here is an example of the kinds of injections which can be achieved:
@ -330,7 +330,7 @@ Assume the following DOM structure for `my_app.html`:
### Shadow DOM effects on Dependency Injection
Shadow DOM provides encapsulation for components, so as a general rule it does not allow directive injections to cross the shadow DOM boundries.
Shadow DOM provides an encapsulation for components, so as a general rule it does not allow directive injections to cross the shadow DOM boundaries.

2
modules/angular2/docs/core/03_formatters.md
View File

@ -1,7 +1,7 @@
# Formatters
Formatters can be appended on the end of the expressions to translated the value to a different format. Typically used
to controll the stringification of numbers, dates, and other data, but can also be used for ordering, maping, and
to control the stringification of numbers, dates, and other data, but can also be used for ordering, mapping, and
reducing arrays. Formatters can be chained.
NOTE: Formatters are known as filters in Angular v1.

40
modules/angular2/docs/core/10_view.md
View File

@ -51,7 +51,7 @@ And assume following HTML Template:
</div>
```
The above template is compiled by the Compiler to create a ProtoView. The ProtoView is than used to
The above template is compiled by the Compiler to create a ProtoView. The ProtoView is then used to
create an instance of the View. The instantiation process involves cloning the above template and
locating all of the elements which contain bindings and finally instantiating the Directives
associated with the template. (See compilation for more details.)
@ -81,7 +81,7 @@ Note:
* View knows which expressions need to be watched.
* View knows what needs to be updated if the watched expression changes.
* All DOM elements are owned by single instance of the view.
* The structure of the DOM can not change during runtime. To Allow structural changes to DOM we need
* The structure of the DOM can not change during runtime. To allow structural changes to the DOM we need
to understand Composed View.
@ -107,27 +107,27 @@ During the compilation process the Compiler breaks the HTML template into these
and
```
<ul> | protoViewA(SomeContexnt)
<template></template> | protoViewA(SomeContexnt): new ProtoViewPort(protoViewB)
</ul> | protoViewA(SomeContexnt)
<ul> | protoViewA(someContext)
<template></template> | protoViewA(someContext): new ProtoViewPort(protoViewB)
</ul> | protoViewA(someContext)
```
The next step is to compose these two ProtoViews into actual view which is rendered to the user.
The next step is to compose these two ProtoViews into an actual view which is rendered to the user.
*Step 1:* Instantiate `viewA`
```
<ul> | viewA(SomeContexnt)
<template></template> | viewA(SomeContexnt): new Foreach(new ViewPort(protoViewB))
</ul> | viewA(SomeContexnt)
<ul> | viewA(someContext)
<template></template> | viewA(someContext): new Foreach(new ViewPort(protoViewB))
</ul> | viewA(someContext)
```
*Step2:* Instantiate `Foreach` directive which will receive the `ViewContainer`. (The ViewContainer
has a reference to `protoViewA`).
*Step3:* As the `Foreach` unrolls it asks the `ViewContainer` to instantiate `protoViewB` and insert
*Step3:* As the `Foreach` directive unrolls it asks the `ViewContainer` to instantiate `protoViewB` and insert
it after the `ViewPort` anchor. This is repeated for each `person` in `people`. Notice that
```
@ -135,7 +135,7 @@ it after the `ViewPort` anchor. This is repeated for each `person` in `people`.
<template></template> | viewA(someContext): new Foreach(new ViewPort(protoViewB))
<li>{{person}}</li> | viewB0(locals0(someContext))
<li>{{person}}</li> | viewB1(locals0(someContext))
</ul> | viewA(lomeContexnt)
</ul> | viewA(someContext)
```
*Step4:* All of the bindings in the child Views are updated. Notice that in the case of `Foreach`
@ -152,8 +152,8 @@ delegate any unknown references to the parent context.
```
Each View can have zero or more ViewPorts. By inserting and removing child Views to and from the
ViewContainers, the application can mutate the DOM structure to any desirable state. A View contain
individual nodes or complex DOM structure. The insertion points for the child Views, known as
ViewContainers, the application can mutate the DOM structure to any desirable state. A View may contain
individual nodes or a complex DOM structure. The insertion points for the child Views, known as
ViewContainers, contain a DOM element which acts as an anchor. The anchor is either a `template` or
a `script` element depending on your browser. It is used to identify where the child Views will be
inserted.
@ -161,7 +161,7 @@ inserted.
## Component Views
A View can also contain Components. Components contain Shadow DOM for encapsulating their internal
rendering state. Unlike ViewPorts which can contain zero or more Views, the Component always contain
rendering state. Unlike ViewPorts which can contain zero or more Views, the Component always contains
exactly one Shadow View.
```
@ -177,10 +177,10 @@ exactly one Shadow View.
## Evaluation Context
Each View as a context for evaluating its expressions. There are two kinds of contexts:
Each View acts as a context for evaluating its expressions. There are two kinds of contexts:
1. A component controller instance and
2. a Locals context for introducing Local variables into the View.
2. a `Locals` context for introducing local variables into the View.
Let's assume following component:
@ -194,7 +194,7 @@ class Greeter {
}
```
And assume following HTML Template:
And assume the following HTML Template:
```
<div> | viewA(greeter)
@ -205,7 +205,7 @@ And assume following HTML Template:
</div> | viewA(greeter)
```
The above UI is built using a single View, and hence single context `greeter`. It can be expressed
The above UI is built using a single View, and hence a single context `greeter`. It can be expressed
in this pseudo-code.
```
@ -215,7 +215,7 @@ var greeter = new Greeter();
The View contains two bindings:
1. `greeting`: This is bound to the `greeting` property on the `Greeter` instance.
2. `name.value`: This poses a problem. There is no `name` property on `Greeter` instance. To solve
2. `name.value`: This poses a problem. There is no `name` property on the `Greeter` instance. To solve
this we wrap the `Greeter` instance in the `Local` instance like so:
```
var greeter = new Locals(new Greeter(), {name: ref_to_input_element })
@ -224,7 +224,7 @@ var greeter = new Locals(new Greeter(), {name: ref_to_input_element })
By wrapping the `Greeter` instance into the `Locals` we allow the view to introduce variables which
are in addition to the `Greeter` instance. During the resolution of the expressions we first check
the locals, and then `Greeter` instance.
the locals, and then the `Greeter` instance.