Because of changes in jQuery, we need to use element().prop() instead of element().attr() to retrieve className and other element properties.
Additionally all attribute selectors (e.g. input[name=value]) must have value quoted if it contains dots (".").
we commonly assign stuff in if statments like this:
if (variable = someFn()) {
//do something with variable
}
This results in lint and IDE warnings (did you mean ==?).
It is better to be explicit about our intention and wrap the assignement
into parens:
if ((variable = someFn())) {
//do something with variable
}
Doing so suppresses warnings + is easier to understand the intention.
I verified that the closure compiler strips the extra parens, so there
is no byte overhead for this safety practice.
We should use this style going forward...
The support for the 'z' formatting flag was removed becase the timezone
info can't be retrieved from the browser apis (except for en-US locale
on some but not all browsers). For this reason we don't want to support
this flag at all.
Related to this, since the 'long' and 'longtime' datetime formats require
the 'z' flag in the formatting string, we are removing support for this
format as well.
- filter.number, filter.currency and filter.date are injected with
$locale service so that we can just swap the service to localize these
- date filter was beefed up in order to support literal strings found in
localization rules
- Speed improvements (about 4x on flush phase)
- Memory improvements (uses no function closures)
- Break $eval into $apply, $dispatch, $flush
- Introduced $watch and $observe
Breaks angular.equals() use === instead of ==
Breaks angular.scope() does not take parent as first argument
Breaks scope.$watch() takes scope as first argument
Breaks scope.$set(), scope.$get are removed
Breaks scope.$config is removed
Breaks $route.onChange callback has not "this" bounded
both numbers and currency need to be formatted using a generic pattern
which can be replaced for a different pattern when angular is working in
a non en-US locale
for now only en-US locale is supported, but that will change in the
future
- add support for full,long, medium, short datetime formats in en
Breaks MMMMM. now we don't support MMMMM anymore as old implementation differs
from Unicode Locale Data format we are following.
- removed support for fullDateTime and fullTime as it means too much
trouble with full timeZone names
- added docs for the new features
the flag must be in all src and test files so that we get the benefit of
running in the strict mode even in jstd
the following script was used to modify all files:
for file in `find src test -name "*.js"`; do
echo -e "'use strict';\n" > temp.txt
cat $file >> temp.txt
mv temp.txt $file
done
Support new date format, specifically day of week/Month of year in string
e.g. {{ someDate | data:"EEE, MMM d, yyyy" }} -> "Wed, Jul 10, 2011"
Closes#396
camelcase is used for other angular functions and forEach is also
used by EcmaScript standard.
- rename the internal as well as the external function name
- tweak the implementation of the function so that it doesn't
clober it self when we extend the angular object with an
object that has a forEach property equal to this forEach function
Closes#85
- improve json filter example
- improve filter overview doc
- improving validator overview jsdocs
- simplify number filter examples and make them live + add specs
- various doc fixes
Support ISO 8601 extended format datetime strings (YYYY-MM-DDTHH:mm:ss.SSSZ) as defined
in EcmaScript 5 throughout angular. This means that the following apis switched from
YYYY-MM-DDTHH:mm:ssZ to YYYY-MM-DDTHH:mm:ss.SSSZ (note the added millis) when representing dates:
- angular.Date.toString
- angular.String.toDate
- JSON serialization and deserialization (used by json filter, $xhr and $resource)
Sanitization works in two phases:
1) We parse the HTML into sax-like events (start, end, chars).
HTML parsing is very complex, and so it may very well be that what
most browser consider valid HTML may not pares properly here,
but we do best effort. We treat this parser as untrusted.
2) We have safe sanitizeWriter which treats its input (start, end, chars)
as untrusted content and escapes everything. It only allows elements
in the whitelist and only allows attributes which are whitelisted.
Any attribute value must not start with 'javascript:'. This check
is performed after escaping for entity (&xAB; etc..) and ignoring
any whitespace.
- Correct linky filter to use safeHtmlWriter
- Correct html filter to use safeHtmlWriter
Close#33; Close#34
