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

docs(01_templates.md): typos 

Fix spelling errors in 01_templates.md

Closes #585
This commit is contained in:
Jorge Cruz 2015-02-08 23:02:41 -08:00 committed by Misko Hevery
parent 320c089dcc
commit 4ceb865632
1 changed files with 31 additions and 31 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

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

@ -8,7 +8,7 @@ The design of template syntax has these properties:
* All data-binding expressions are easily identifiable. (i.e. there is never an ambiguity wether the value should be
interpreted as string literal or as an expression.)
* All events and their statments are easily identifiable.
* All events and their statements are easily identifiable.
* All places of DOM instantiation are easily identifiable.
* All places of variable declaration is esily identifiable.
@ -300,7 +300,7 @@ keeping `null` and `undefined` as empty strings.
## Inline Templates
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 than instantiat these templates into Views. The
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.
<table>
@ -370,8 +370,8 @@ NOTE: Only Instantiator directives can be placed on the template element. (Decor
### Template Microsyntax
Often times it is necessary to encode a lot of different bindings into a template to controll how the instantiation
of the templates occures. One such example is foreach.
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.
```
<form #foo=form>
@ -389,8 +389,8 @@ Where:
* `#person` exports the implicit `foreach` item.
* `#i=index` exports item index as `i`.
The above example is explicit but quite wordy, for this reason in most situatios a short hand version of the
syntax is prefferable.
The above example is explicit but quite wordy, for this reason in most situations a short hand version of the
syntax is preferable.
```
<ul>
@ -399,7 +399,7 @@ syntax is prefferable.
```
Notice how each key value pair is translated to `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 opional in the short version
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.
```
@ -408,7 +408,7 @@ which allows us to further shorten the text.
</ul>
```
We can also optionaly use `var` instead of `#` and add `:` to `foreach` which creates the following recomended
We can also optionally use `var` instead of `#` and add `:` to `foreach` which creates the following recommended
microsyntax for `foreach`.
```
@ -432,18 +432,18 @@ microsyntax: ([[key|keyExpression|varExport][;|,]?)*
Where
* `expression` is an angular expression as defined in section: Expressions
* `local` is a local identifiar for local variables.
* `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 varibles for further binding. If no `internal` name
* `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
which properties as well as which varibales are exported for binding.
which properties as well as which variables are exported for binding.
NOTE: the `template` attribute must be present to make it clear to the user that a sub-template is being created. This
goes allong the philosophy that the developer should be able to reason about the template without understanding the
goes along the philosophy that the developer should be able to reason about the template without understanding the
semantics of the instantiator directive.
@ -470,7 +470,7 @@ Where:
dash-case is converted into camel-case `someEvent`.
* `statement` is a valid statement (as defined in section below).
By default angular anly listens to the element on the event, and ignores events which bubble. To listen to bubbled
By default angular only listens to the element on the event, and ignores events which bubble. To listen to bubbled
events (as in the case of clicking on any child) use the bubble option (`(^event)` or `on-bubble-event`) as shown
bellow.
@ -511,7 +511,7 @@ bind to custom events of Custom Elements, whos event names are not known ahead o
## Expressions, Statements and Formatters
Angular templates contain expressions for binding to data and statments for binding to events. Expressions and statments
Angular templates contain expressions for binding to data and statements for binding to events. Expressions and statements
have different semantics.
@ -527,15 +527,15 @@ Angular are:
<div template="if: expression">...</div>
```
Expressions are simplified version of expression in the langugage in which you are writing your application. (i.e.
expressions fallow JS syntax and semantics in JS and Dart syntax and semantics in Dart). Unlike expressions in the
langugage, binding expressions behave differently in following ways:
Expressions are simplified version of 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:
* *Must be defined*: Anlike Angular v1, Angular v2 will throw an error on dereferencing fields which are not defined.
* *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).
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 langugage.
* *Safe dereference*: Expressions `user.name` where `user` is null will throw `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.
@ -559,32 +559,32 @@ class Greeter {
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.
* `name; name.length`: Not allowed because of multiple statments.
* `name; name.length`: Not allowed because of multiple statements.
### Statements
Statements can be used to bind to events only. Statements represent actions to trigger as a response to an event.
Examples of where statments can be used in Angular are:
Examples of where statements can be used in Angular are:
```
<div (click)="statments">...</div>
<div on-click="statments">...</div>
<div (click)="statements">...</div>
<div on-click="statements">...</div>
```
Statements are similar to statments in the langugage in which you are writing your application. (i.e.
statments follow JS syntax and semantics in JS and Dart syntax and semantics in Dart). Unlike statments in the
langugage, binding expressions behave differently in following ways:
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:
* *Unsafe dereference*: Expressions `user.verify()` where `user` is `null` will throw `NullPointerException` in the
langugage as well as in statments. (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 statments,
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 statemnet. (i.e. no `doA(); doB()`)
* *Multiple statements OK*: Statements can be composed from more than one statement. (i.e. no `doA(); doB()`)
* *Assignments OK*: Event bindings can have side effects and hence assignments are allowed.
* *No keywords*: Statements can not contain keywords such as: `var`, `if`, and so on.
* *No Formatters*: Angular statements can not contain formatters. (Formatters are only usefull for data binding)
* *No Formatters*: Angular statements can not contain formatters. (Formatters are only useful for data binding)
## Further Reading
* [Template Syntax Constraints and Reasoning](https://docs.google.com/document/d/1HHy_zPLGqJj0bHMiWPzPCxn1pO5GlOYwmv-qGgl4f_s)
* [Template Syntax Constraints and Reasoning](https://docs.google.com/document/d/1HHy_zPLGqJj0bHMiWPzPCxn1pO5GlOYwmv-qGgl4f_s)