Compare commits
852 Commits
v0.9.14
...
g3-v1.0.0rc1
| Author | SHA1 | Date | |
|---|---|---|---|
| 1faafa3158 | |||
| 08bfea183a | |||
| f13dd3393d | |||
| bca96e7c7c | |||
| 9b1aff905b | |||
| 252d4548f9 | |||
| 6abafcb424 | |||
| 2315d9b361 | |||
| 8fd1b74872 | |||
| 02091b2c1e | |||
| 25cd774abf | |||
| c70ead0aa1 | |||
| 716b5fd3e2 | |||
| 8b8fdddc0b | |||
| ce4b630524 | |||
| 13f31602f3 | |||
| 7b52586f7c | |||
| e9e3ee012b | |||
| de9464c143 | |||
| 31cd580310 | |||
| d34f3bc7a6 | |||
| 027801a00a | |||
| 66e6c1ce2c | |||
| 4806d28a29 | |||
| 089c0f8b0e | |||
| b6ae6e52f9 | |||
| 9277d12fc0 | |||
| ac5151a469 | |||
| 63be222326 | |||
| a29c2cf70c | |||
| afe617a647 | |||
| f59e4b11f1 | |||
| 5e6ba25201 | |||
| 9134f5ce5a | |||
| 4e6b065a2f | |||
| 5e3db61b1d | |||
| a9ed5745a0 | |||
| 48096048cf | |||
| 317adb36a4 | |||
| 1b9277bf6f | |||
| cce31d4c93 | |||
| 3e5377f4f3 | |||
| 488a03631e | |||
| 716dd5f3f9 | |||
| 83314913e7 | |||
| e0cc84ad7b | |||
| 4a94bb9b34 | |||
| 53aacb35fa | |||
| f4d338d393 | |||
| 0bfaa579c0 | |||
| 00d4427388 | |||
| e0c9551fd7 | |||
| fae84463e4 | |||
| 8fb34f008e | |||
| 5d09a1efd3 | |||
| f54db2ccda | |||
| dd7b0f56fc | |||
| b3750103cc | |||
| b348347dad | |||
| 512db03cc0 | |||
| ee7209fe26 | |||
| 772ddb983b | |||
| 7f6c1093f5 | |||
| 1b4289ce76 | |||
| af21233820 | |||
| 08ad4b6a46 | |||
| 2acd60df4d | |||
| e0ace15cd3 | |||
| 6a98c52c84 | |||
| 6aa3cfc31b | |||
| 64912069ca | |||
| b49ddf9848 | |||
| 1084ccf7ef | |||
| c2989f6cc6 | |||
| 4f797fe5f3 | |||
| bbd3a3fd76 | |||
| e86bafecd2 | |||
| e68c02c537 | |||
| 25d207c48c | |||
| 4370d756e4 | |||
| 4e83399570 | |||
| e7d6106811 | |||
| c4c60c25b4 | |||
| 139e1b09a9 | |||
| 60743fc52a | |||
| 9486590e1b | |||
| e31d1c287d | |||
| f16bd2f747 | |||
| ef7346ff70 | |||
| f6fb31e8ad | |||
| 21c725f1a1 | |||
| e23fa768aa | |||
| d656d11489 | |||
| b37e8a2b14 | |||
| 4c1c50fd9b | |||
| d1558d7924 | |||
| 5b0d068358 | |||
| 230f29d0a7 | |||
| 3171f21591 | |||
| d6e3e1baab | |||
| ffa8441886 | |||
| 5d8528cc2e | |||
| 80edcadb1d | |||
| c27a56f4da | |||
| fbcb7fdd14 | |||
| fa69d10122 | |||
| dd321c5f4d | |||
| 656a495e50 | |||
| 6d0ca95fa0 | |||
| 3df7b8e57f | |||
| 7bd69d0f5b | |||
| 3773323e46 | |||
| 78656fe0df | |||
| cb10ccc44f | |||
| 4a051efb89 | |||
| 1752c8c44a | |||
| 6216dc0465 | |||
| 761b2ed85a | |||
| c8ee631c19 | |||
| cae9ad4ba9 | |||
| 85b2084f57 | |||
| 13b21aaf5a | |||
| 22c1db1744 | |||
| 292a5dae07 | |||
| 6e635012fb | |||
| eb92735c9e | |||
| 776739299b | |||
| 3173d8603d | |||
| 6c4f1391bc | |||
| 58d6da556a | |||
| b6f61a89cf | |||
| 8b32900d72 | |||
| 18a1e860a3 | |||
| 39b3297fc3 | |||
| 1268fc1a44 | |||
| 4804c83b7d | |||
| e2b1d9e994 | |||
| 9ee2cdff44 | |||
| 8af4fde182 | |||
| 5001c1a121 | |||
| 0f6b2ef982 | |||
| 1e258d11d0 | |||
| 81a6601e05 | |||
| 1e96d0af8c | |||
| 97dae0d0a0 | |||
| 84823b2eff | |||
| 517811764d | |||
| 1354718365 | |||
| 56bcc04c54 | |||
| b2052d08a1 | |||
| 7da2bdb82a | |||
| ed78f0d830 | |||
| dbffbefb7c | |||
| 0196411dbe | |||
| 992c790f07 | |||
| f5343c9fd3 | |||
| 0470ff04b4 | |||
| efe33a5e21 | |||
| 7046d6053d | |||
| afc241bd28 | |||
| a507fb7bb3 | |||
| 0ce139c42d | |||
| b00262fffe | |||
| 3f98d6ac99 | |||
| 22309c312f | |||
| fcf95a47d1 | |||
| e1e7aca9a6 | |||
| 039041e3ae | |||
| 3da441b580 | |||
| f9502d2ad3 | |||
| 0356c90af8 | |||
| 0d4def452e | |||
| 897d0f1424 | |||
| 92af30ce6e | |||
| 54581d36df | |||
| b587091b6e | |||
| c49b8a2db5 | |||
| 5cdfe45aa3 | |||
| 16a40c626f | |||
| b7f4d8c3c3 | |||
| 939c8e8fac | |||
| d2ba4c5170 | |||
| 46691c2721 | |||
| e7a23e4b65 | |||
| 15fd735793 | |||
| 985d3d7558 | |||
| 249c89c091 | |||
| 5164ae545b | |||
| e1e0ddb910 | |||
| d648d709f3 | |||
| 9a8dbfef51 | |||
| 28114de8dc | |||
| c6ea1be053 | |||
| 5143e7bf06 | |||
| afd25446d2 | |||
| 3c3e6980b3 | |||
| e0b4b107ee | |||
| 614fd3d55a | |||
| 7146f70636 | |||
| 11cb9423a7 | |||
| c76a120bfe | |||
| b8960c3710 | |||
| 67338ce061 | |||
| 23f8da7cbb | |||
| b911e303ec | |||
| a13b5ed3bc | |||
| 63cca9afbc | |||
| d47ec772c3 | |||
| 5c19766063 | |||
| f2119c7524 | |||
| 08029c7b72 | |||
| 0bf611087b | |||
| acb4338b70 | |||
| cd9a7b9608 | |||
| 1dccaaaaa2 | |||
| 9632f5c1c7 | |||
| bb3be87606 | |||
| 174952e443 | |||
| 6f91ffeb91 | |||
| c594f75b4c | |||
| 50eb7f15b8 | |||
| 212a6ff29a | |||
| 871252ab4c | |||
| 0c534644bc | |||
| c28662d28d | |||
| b97c6e5f74 | |||
| 4e3c05b99e | |||
| 5e4d59adf0 | |||
| fd38655e6c | |||
| b9001e9147 | |||
| d1e7a5394a | |||
| 2090136dd8 | |||
| c9f2b1eec5 | |||
| 163e05ed36 | |||
| 2986a09c0d | |||
| bb2e7488fa | |||
| 44b2f44f93 | |||
| 1d14760c6d | |||
| baa7af0df0 | |||
| f43c226c67 | |||
| 0e1fa2aefe | |||
| 3d0ce0ebe9 | |||
| b00da987a9 | |||
| 188bdf7768 | |||
| dbd880cc0a | |||
| bf8e0540f8 | |||
| 78b6e8a446 | |||
| b656552d68 | |||
| 1cdfa3b960 | |||
| 16363d8000 | |||
| 92995bbce9 | |||
| b9707d910e | |||
| 5bbd64ac65 | |||
| caeb1bf899 | |||
| 9b4efa73f9 | |||
| 4aaa2f7f6b | |||
| 6290bd4587 | |||
| e9f81b6631 | |||
| afbe073121 | |||
| 7b705df2b7 | |||
| a4c8ac7126 | |||
| e3e2e4436e | |||
| 972c3e9be0 | |||
| feacf608ee | |||
| fe633dd0cf | |||
| fdcc2dbfd3 | |||
| 5ad0c7d0e4 | |||
| 540701a8d8 | |||
| 4d2d70e7fb | |||
| cd28a2e952 | |||
| 59adadca08 | |||
| 497839f583 | |||
| 5487bdb3d1 | |||
| 3ae3ccf3da | |||
| e9b57f9df8 | |||
| 45f47ff6cd | |||
| 0c8b35681e | |||
| a035e88397 | |||
| 3548fe3139 | |||
| 29f9e2665d | |||
| 8d1944851d | |||
| 3e1a6688c3 | |||
| aba9bb2a24 | |||
| 5857c44e0c | |||
| 8adae2fdf2 | |||
| 955551141d | |||
| 94e1a07b28 | |||
| ac73e8877e | |||
| e88dfb734a | |||
| 8d6dc0b9a7 | |||
| acbd7cdf32 | |||
| 035c751076 | |||
| 186a840cd3 | |||
| b09595a3c1 | |||
| f6d98f1472 | |||
| 5279de0e70 | |||
| 8fe77b69e8 | |||
| 1cc6bee4ce | |||
| a8aa193c6b | |||
| e45b013143 | |||
| ea18f4548d | |||
| 57c37a21d1 | |||
| 74fac45f48 | |||
| f0fa5e6376 | |||
| c283bf6035 | |||
| b3c17f3fdc | |||
| 9c06394376 | |||
| 085e3c611f | |||
| 4b35a59c6a | |||
| 7cb03c5ab9 | |||
| 78c7066422 | |||
| 923da410bd | |||
| a87f2fb9e4 | |||
| c27aba4354 | |||
| dd9151e522 | |||
| 3972d2a89b | |||
| cb6f832f38 | |||
| 6022f3df39 | |||
| 7c11531902 | |||
| c6d2549a52 | |||
| bee6060e4b | |||
| 16597e8b52 | |||
| f684f20c99 | |||
| bd04316a89 | |||
| ed36b9da3b | |||
| c925f8a657 | |||
| 4c10d33eb4 | |||
| 9062996a0e | |||
| 411c1ae77e | |||
| d12df0d360 | |||
| d9b58f23f6 | |||
| 03dd8c4f4c | |||
| 48697a2b86 | |||
| 93b777c916 | |||
| 5c70ff72e2 | |||
| 5e663c3dc7 | |||
| 260725efcd | |||
| 4afad1da29 | |||
| eb01fe593d | |||
| fc7834f9ac | |||
| e4303a1f3a | |||
| 1e00db8daa | |||
| aaa0179758 | |||
| f5ef3724ce | |||
| e60601be4f | |||
| e2663f62b0 | |||
| 9f9ed4c5ff | |||
| 66fc268aeb | |||
| 1d966f8a65 | |||
| ddf6f1143f | |||
| 2636105c5e | |||
| c0b557a96c | |||
| 84873e7f4e | |||
| 95fdb1231f | |||
| ef875ad0cf | |||
| 615841a5d3 | |||
| 7d0c256ecd | |||
| 6cbe096dbf | |||
| 21602b5cd6 | |||
| 4ae671ac88 | |||
| 28ed5ba465 | |||
| 02dc81bae0 | |||
| 445680f601 | |||
| bf729d550b | |||
| dc8ffa51b7 | |||
| d7ba5bc83b | |||
| 950d02b4d4 | |||
| 578e38e0af | |||
| af7c51ee1d | |||
| 25d1822bd8 | |||
| 3945f884c5 | |||
| d5ccabce60 | |||
| bb948176aa | |||
| 163c799eff | |||
| 7da70af1ae | |||
| 836e4c1428 | |||
| eabedba34d | |||
| b4add97c17 | |||
| bacc31bea9 | |||
| ad90c3574f | |||
| e28171d5e4 | |||
| ce73ed091b | |||
| 90ac8d57b0 | |||
| 6eb1179505 | |||
| 9b85757102 | |||
| c6c3949b14 | |||
| e175db37c6 | |||
| f38010d3a2 | |||
| 7fc18b263d | |||
| fabc9f77a3 | |||
| c17c731fdc | |||
| 3692885810 | |||
| 5d43439dbe | |||
| a46f2a0db3 | |||
| 3217a249e1 | |||
| 78f394fd17 | |||
| e82e64d57b | |||
| 8978e066b5 | |||
| 833eb3c844 | |||
| 07926ff1ef | |||
| e801faba2e | |||
| ee6af9a978 | |||
| 74379df6c4 | |||
| fe65dd926c | |||
| 669b53ede2 | |||
| b0c3f28e8f | |||
| 9810dc0993 | |||
| ab5df20dfa | |||
| d83a92c121 | |||
| d0425de29e | |||
| ad5e42cf82 | |||
| 9ed1126adb | |||
| 7a19eb84aa | |||
| 718741acab | |||
| ec8bb675b4 | |||
| 8e32f3fd35 | |||
| 02332107e5 | |||
| afc81b554e | |||
| 26e8ab3693 | |||
| 28ccc76aa1 | |||
| b3c4cb7cff | |||
| 4af4378b11 | |||
| 8611ebe6a0 | |||
| 8f46a3c9ac | |||
| 66fdb36ecb | |||
| f0f5ffa9aa | |||
| 2bc7afd3ba | |||
| a4b45397e0 | |||
| de4e06ed73 | |||
| fd822bdaf9 | |||
| 4f78fd692c | |||
| df6d2ba326 | |||
| ccda436f94 | |||
| e86c435349 | |||
| 1942861472 | |||
| b96e978178 | |||
| bda2bba2be | |||
| ca08c004c8 | |||
| 25a62b58db | |||
| 97e3ec4d1b | |||
| 75f11f1fc4 | |||
| e134a8335f | |||
| 8ee32a75f0 | |||
| f6a8ad87ee | |||
| 7e6ff401b8 | |||
| 7aeb6a24f7 | |||
| e1ecc34edd | |||
| 29d36e94e1 | |||
| 091c173632 | |||
| c115fa9924 | |||
| b7a7fc7065 | |||
| 21b2a5bd21 | |||
| ca1e45beaf | |||
| 084b83ffa9 | |||
| bf5e5f7bc9 | |||
| 2e9fed7b6c | |||
| ea3228e311 | |||
| 2eb49147d6 | |||
| 13f92de624 | |||
| 2bc39bb0b4 | |||
| 62ae7fccbc | |||
| 3ace81b92a | |||
| 9acf45127e | |||
| 6883e8c7a0 | |||
| 7ae536d053 | |||
| 2170c06924 | |||
| 0e5a24c584 | |||
| 4e8f0d6e9f | |||
| f9b6b61468 | |||
| 555f415290 | |||
| 3800d17703 | |||
| 009059dd1b | |||
| 6b7ddf414d | |||
| 8259f10138 | |||
| ab407de54d | |||
| 0d7fe97aff | |||
| a2a830e227 | |||
| 8336f3f0ba | |||
| e14ac2c3b0 | |||
| a13653c814 | |||
| 8017340cd1 | |||
| 17d1aef66a | |||
| 1856f62cb1 | |||
| 7e1f364177 | |||
| aac68bf2ba | |||
| 4b4292edb8 | |||
| 292d5d1421 | |||
| 66dec77555 | |||
| 8fa79066e2 | |||
| 909415d5ed | |||
| 4421f3d435 | |||
| 22cb600280 | |||
| 5ba227c7cd | |||
| f37f0ea16e | |||
| 91ccb4ba6e | |||
| d0f459c56f | |||
| cbedf55641 | |||
| 988ed451b5 | |||
| fc2f188d4d | |||
| 4b1913c5ec | |||
| 06534413d3 | |||
| e54909f5ef | |||
| 79f2512ba7 | |||
| b0eb831bce | |||
| 7f0b97e02c | |||
| fc7f1ef6a0 | |||
| 8bae2a5ecb | |||
| 30e5f6274a | |||
| bc6e0cc954 | |||
| 8d11db0757 | |||
| 2a8fe56997 | |||
| 622c3ec974 | |||
| db78aa1ce1 | |||
| 986608fe76 | |||
| 31b8624121 | |||
| a5607e3061 | |||
| ff2cb86d5d | |||
| 825cbadf80 | |||
| 93f96a16f6 | |||
| c763b009ac | |||
| e5da0c956b | |||
| 3c80cf3df6 | |||
| ad3cc16eef | |||
| 08d09ecbaa | |||
| 456c7f62c5 | |||
| c9e7fb894b | |||
| 4a9ccc0abc | |||
| bceadd8e30 | |||
| 545b31aa2e | |||
| e068addadb | |||
| 0da4902e9d | |||
| 3ba90003b4 | |||
| 5927b23ef3 | |||
| 452607fc64 | |||
| 19401280ae | |||
| 08a33e7bb3 | |||
| 30753cb131 | |||
| dbf8afcba0 | |||
| 446f6b233f | |||
| e3fad0feb3 | |||
| 0f6e199d98 | |||
| 15e6105779 | |||
| ee38918059 | |||
| 94e3b28d24 | |||
| 38e6d1e313 | |||
| 607de75fa4 | |||
| db04241beb | |||
| 774db0aecb | |||
| dc0b0c77c7 | |||
| 6114c8f504 | |||
| b99b0a8072 | |||
| 431b748cac | |||
| de34ca0b64 | |||
| 793ecb4817 | |||
| 1d45e65f4a | |||
| 2bbef363e4 | |||
| 035ad72726 | |||
| 9d808239b3 | |||
| ef01362e44 | |||
| 6c30601ad8 | |||
| 37b5c5cfe9 | |||
| 966cbd4cf8 | |||
| 8534b7c7c0 | |||
| 6802a76007 | |||
| 7ec8a89362 | |||
| 34f174066f | |||
| 530dc412c4 | |||
| 3f99cdbdc3 | |||
| 13e7df68a6 | |||
| 42062dab34 | |||
| 1c9fc1e1de | |||
| 8bc7beacd8 | |||
| 842741ee99 | |||
| 40ad543d27 | |||
| 06835a462a | |||
| 142cffcf64 | |||
| 862d78c1d9 | |||
| 6f8904e027 | |||
| 4dc9e6416a | |||
| 4f6e947e49 | |||
| 15efbbdc1f | |||
| 67a3315e1d | |||
| 8f0dcbab80 | |||
| 1f4b417184 | |||
| 2d8d5aef29 | |||
| eb758bc605 | |||
| 761997e082 | |||
| aacd5b672e | |||
| 8d64793717 | |||
| 908f59a5df | |||
| a45d383da2 | |||
| c1a681d6f4 | |||
| f4df421b44 | |||
| bdef462ccc | |||
| a79231dea6 | |||
| 3e54a1b18a | |||
| 4b90f65614 | |||
| b5594a773a | |||
| f39420e7d7 | |||
| 72e46548b8 | |||
| 9dea9de449 | |||
| bee78a8492 | |||
| f3e04fbd6a | |||
| 00ea08e0ab | |||
| 31b59efa96 | |||
| 17251372b1 | |||
| f768954f38 | |||
| 3237f8b995 | |||
| 7802c90e13 | |||
| c348f2cad6 | |||
| f3456dc282 | |||
| ee04141a5a | |||
| 66fec10dc3 | |||
| ae75c35746 | |||
| 0cf5535333 | |||
| fdd5d9471f | |||
| 0782422d1f | |||
| 8fa066190a | |||
| e90b741c94 | |||
| 3af1e7ca2e | |||
| 0fbaa2f12a | |||
| ad3b8d7bcf | |||
| 3ea2416f80 | |||
| 9636160332 | |||
| 2b2df4754d | |||
| 120701b9d9 | |||
| fe5240732d | |||
| b98c23274b | |||
| 4c6d26a38f | |||
| c43ce91b25 | |||
| b7cf7f2a79 | |||
| ef7cf60ebd | |||
| 7974e7eb5f | |||
| f9b4c9da64 | |||
| 83ac1193f2 | |||
| 7a3fdda965 | |||
| b4f18fc295 | |||
| da464683aa | |||
| a0b35161a6 | |||
| a8f4d87be5 | |||
| 57ea8156a1 | |||
| 6289d18e61 | |||
| 9e37ebe635 | |||
| 345c01c81b | |||
| 975aef2ad2 | |||
| c863514660 | |||
| 86a6cc7152 | |||
| 8f3276bbcd | |||
| 2428907259 | |||
| 8a8a2cf462 | |||
| 47efe44a1d | |||
| c52e749a6e | |||
| 4ab3596295 | |||
| 106674ac1e | |||
| 330d1a870d | |||
| 7e2e7b07b6 | |||
| ce80576e0b | |||
| 10da625ed9 | |||
| 9ee9ca13da | |||
| bb39d34279 | |||
| e09a78438f | |||
| 1e890863e5 | |||
| 76a500179d | |||
| 7b32c71386 | |||
| 28e84ca167 | |||
| 41250e9cf9 | |||
| 77ba539f63 | |||
| 952225f020 | |||
| 35f9f527d3 | |||
| 30bd04feaa | |||
| 25a77c58c1 | |||
| 75721223b5 | |||
| f606ffed4b | |||
| b49035a8c5 | |||
| 86ff9dee23 | |||
| 6dc22fe575 | |||
| 68ab0f9b02 | |||
| d7e0915e62 | |||
| b3d5d2caa9 | |||
| c02ef92630 | |||
| 1e8448b9e5 | |||
| c5f3a413bc | |||
| d3fb5b411e | |||
| 75bc59ee4b | |||
| 6aee2938a7 | |||
| 2043fd43fa | |||
| ce4f27aa7b | |||
| 8e915f5545 | |||
| 8e6e09a4bc | |||
| f3323ec18e | |||
| b5a510a343 | |||
| 9ec45ad5c4 | |||
| 8e880fcb77 | |||
| b74163dc1d | |||
| bad62d87a1 | |||
| 65b6e48742 | |||
| fee3717892 | |||
| d0edc11704 | |||
| f9f0905f4a | |||
| 92ebf11b2a | |||
| e6ee994764 | |||
| c8ee00cb2b | |||
| 7460a7ef61 | |||
| 3c87611188 | |||
| b842642b57 | |||
| d428c9910e | |||
| f8529672f6 | |||
| e83465c362 | |||
| f370be85cb | |||
| 5dbf0cc8a2 | |||
| e4a00626d8 | |||
| 91a34a7027 | |||
| af285dd370 | |||
| 89e001b18a | |||
| 4f2f3c9cbf | |||
| c1abc03cf3 | |||
| 04a62e83bc | |||
| f9f95879f0 | |||
| 8cad231bd2 | |||
| 0e17ade959 | |||
| bb67ee8d28 | |||
| 2a12f7dcaa | |||
| 20ce797906 | |||
| cc9f1fdf38 | |||
| f243c6aeda | |||
| 26e651996a | |||
| f57536ddb6 | |||
| 73e3f4c10c | |||
| ec6d106d4a | |||
| fab4ada3c8 | |||
| d6eba8f39f | |||
| 4295b3dded | |||
| a23d15ad3a | |||
| 66f3317bef | |||
| a4dd9ca769 | |||
| d6e4636618 | |||
| e0ee3a0726 | |||
| e670a812fa | |||
| 517ada2662 | |||
| 88ae927857 | |||
| bb7228e2d9 | |||
| 25b3438fd7 | |||
| f21b9214e6 | |||
| 80ea329d5f | |||
| 6e0ff5fa96 | |||
| 4cdce2d30b | |||
| 48e69ed4d1 | |||
| c35b0a7907 | |||
| 805bb5bb6e | |||
| 4224e8e371 | |||
| 6319ba2ed0 | |||
| dd44e00ddd | |||
| 6e4a501127 | |||
| c7dbe4d98b | |||
| 3069566073 | |||
| bd9a7b9fd7 | |||
| 759e6ea8ed | |||
| c4989d8979 | |||
| af710c3ac1 | |||
| e89ef35d05 | |||
| 2ba3c3ee57 | |||
| c6dbdde6dc | |||
| f8417b48be | |||
| 7f1e2e4846 | |||
| 5533e48dea | |||
| 16d0354f93 | |||
| 350ee31107 | |||
| 2da07127e4 | |||
| d05e839920 | |||
| 22dee3e278 | |||
| bc2ca384b1 | |||
| 2380943106 | |||
| 297c9b5b89 | |||
| 43b2cd45f0 | |||
| e389911a35 | |||
| fd357b4cd2 | |||
| 924ffafc51 | |||
| 3616716615 | |||
| 76df0db598 | |||
| e21a868524 | |||
| 7fe46e8d7e | |||
| 864da8b553 | |||
| d62b8407cf | |||
| 8cb84eac68 | |||
| 2e0e732cad | |||
| 22f9354c21 | |||
| 0c75a96917 | |||
| 14407921c7 | |||
| 8920381b44 | |||
| 3751f172b3 | |||
| 3776e08db0 | |||
| c1debfb81d | |||
| 0fb37b08e7 | |||
| 8fa598fa00 | |||
| 91f9efed49 | |||
| 2094bc8f61 | |||
| 9701f0735b | |||
| a1f3725c0f | |||
| 4ac234833a | |||
| 9d9117384f | |||
| 525e444a0f | |||
| fd112877f8 | |||
| 6181ca600d | |||
| 11e9572b95 | |||
| b6bc6c2ddf | |||
| ea6b87c24b | |||
| e205bd7137 | |||
| bd7e68f12f | |||
| 0a604bdb90 | |||
| 4738d49e1c | |||
| 9fdb09ebf8 | |||
| 1eebb771e3 | |||
| 9250fce19c | |||
| 9a69677551 | |||
| b6db58c647 | |||
| 4b0f2dfe0c | |||
| dad2603752 | |||
| 50076b571d | |||
| aa64d37a23 | |||
| 2e5199997c | |||
| b2f5299e0e | |||
| 805e083c24 | |||
| 1abdc097b2 | |||
| 9f56af9c15 | |||
| c5f0342ad8 | |||
| b85e95709d | |||
| cc5dfaf0ab | |||
| 9272a1a472 | |||
| f85c82acd6 | |||
| 35bb19856c | |||
| 97bdf979a1 | |||
| 64938a2e81 | |||
| e7c22e8153 | |||
| b2dc2ce0b5 | |||
| 498ad0a3be | |||
| cfc18efd28 | |||
| 97573c3930 | |||
| 8bb9f12961 | |||
| ce0fbc6a77 | |||
| 3d388498e5 | |||
| 3d787ab6f4 | |||
| 81063a748c | |||
| 9462b556a3 | |||
| 8e6ecd98ae | |||
| 1d7adac7a5 | |||
| 72ad726efa | |||
| 0d2d7025e6 | |||
| d517bcad5b | |||
| e5419db6c7 | |||
| 754d2541c4 | |||
| 9bd2c3967b | |||
| 38ec6519a3 |
@@ -0,0 +1,10 @@
|
||||
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
|
||||
<launchConfiguration type="org.eclipse.ui.externaltools.ProgramBuilderLaunchConfigurationType">
|
||||
<booleanAttribute key="org.eclipse.debug.ui.ATTR_LAUNCH_IN_BACKGROUND" value="false"/>
|
||||
<booleanAttribute key="org.eclipse.ui.externaltools.ATTR_BUILDER_ENABLED" value="false"/>
|
||||
<stringAttribute key="org.eclipse.ui.externaltools.ATTR_BUILD_SCOPE" value="${working_set:<?xml version="1.0" encoding="UTF-8"?> <resources> <item path="/angular.js/perf" type="2"/> <item path="/angular.js/src" type="2"/> </resources>}"/>
|
||||
<stringAttribute key="org.eclipse.ui.externaltools.ATTR_LOCATION" value="${workspace_loc:/angular.js/perf.sh}"/>
|
||||
<stringAttribute key="org.eclipse.ui.externaltools.ATTR_RUN_BUILD_KINDS" value="full,incremental,auto,"/>
|
||||
<booleanAttribute key="org.eclipse.ui.externaltools.ATTR_TRIGGERS_CONFIGURED" value="true"/>
|
||||
<stringAttribute key="org.eclipse.ui.externaltools.ATTR_WORKING_DIRECTORY" value="${workspace_loc:/angular.js}"/>
|
||||
</launchConfiguration>
|
||||
@@ -2,7 +2,14 @@ build/
|
||||
angularjs.netrc
|
||||
jstd.log
|
||||
.DS_Store
|
||||
gen_docs.disable
|
||||
test.disable
|
||||
regression/temp*.html
|
||||
performance/temp*.html
|
||||
.idea/workspace.xml
|
||||
*~
|
||||
angular.js.tmproj
|
||||
node_modules
|
||||
jsTestDriver*.conf
|
||||
angular.xcodeproj
|
||||
.idea
|
||||
|
||||
Generated
-67
@@ -1,67 +0,0 @@
|
||||
IMPORTANT: THIS IS TO CERTIFY THE RIGHT TO USE THE JETBRAINS SOFTWARE PRODUCT, GRANTED BY JETBRAINS S.R.O. UNDER THE TERMS AND CONDITIONS OF THE LICENSE AGREEMENT INCLUDED WITH THE SOFTWARE. PLEASE SAVE A COPY OF THIS EMAIL FOR FUTURE REFERENCES.
|
||||
|
||||
========LICENSE DETAILS========
|
||||
|
||||
Type: Open Source License
|
||||
Reference No*: LC-93161-D352729080
|
||||
Date of Issue: 3 November 2010
|
||||
Expiration Date: 3 November 2011
|
||||
Number of Authorized Users: not limited
|
||||
|
||||
* Please quote this reference when contacting JetBrains
|
||||
|
||||
===========LICENSEE============
|
||||
|
||||
Name: angularjs
|
||||
Customer ID: 93161
|
||||
Address:
|
||||
|
||||
=======SOFTWARE PRODUCT========
|
||||
|
||||
Product Name: WebStorm
|
||||
Licensed Version: 1.0 and any new product release which is made generally available before 3 November 2011
|
||||
|
||||
The software is shipped electronically and is available for download from:
|
||||
http://www.jetbrains.com/webstorm/download/
|
||||
|
||||
Your WebStorm license includes a 1-year upgrade subscription qualifying you for free upgrades to any new versions of WebStorm released by JetBrains during your upgrade subscription period starting on your license issue date and ending on 3 November 2011. To check availability of the new versions of WebStorm, please visit http://www.jetbrains.com.
|
||||
|
||||
For running any new version of WebStorm released by JetBrains during your upgrade subscription period, please use the included below licensing details.
|
||||
|
||||
You can renew your upgrade subscription before or after its expiration. Your new subscription period will start on the date following the expiration date of your current upgrade subscription.
|
||||
|
||||
=========INSTALLATION==========
|
||||
|
||||
Run WebStorm and follow the Installation Wizard's instructions. To register for use of the software or change your existing registration details, go to Help/Register menu of the software and enter the included below the User Name and License Key(s) into the registration dialog:
|
||||
|
||||
User Name: angularjs
|
||||
|
||||
===== LICENSE BEGIN =====
|
||||
93161-03112010
|
||||
00000jBsEx59XVlc79fV"aAqWXQ09e
|
||||
jQsg5TNp5X4HGhc10LNBdu!!ejRcFG
|
||||
7h3S6T09YcRWs23TH0RgaM87!HqmQo
|
||||
===== LICENSE END =====
|
||||
|
||||
===DOCUMENTATION AND SUPPORT===
|
||||
|
||||
WebStorm documentation:
|
||||
http://www.jetbrains.com/webstorm/documentation/
|
||||
|
||||
Available support resources:
|
||||
http://www.jetbrains.com/support/
|
||||
|
||||
Technical support contact:
|
||||
support@jetbrains.com
|
||||
|
||||
Contact for the license renewal requests:
|
||||
opensource@jetbrains.com
|
||||
|
||||
For questions, please contact:
|
||||
sales@jetbrains.com
|
||||
|
||||
|
||||
JetBrains Sales Team
|
||||
http://www.jetbrains.com
|
||||
"Develop with pleasure!"
|
||||
|
||||
Generated
-9
@@ -1,9 +0,0 @@
|
||||
<?xml version="1.0" encoding="UTF-8"?>
|
||||
<module type="WEB_MODULE" version="4">
|
||||
<component name="NewModuleRootManager">
|
||||
<content url="file://$MODULE_DIR$" />
|
||||
<orderEntry type="inheritedJdk" />
|
||||
<orderEntry type="sourceFolder" forTests="false" />
|
||||
</component>
|
||||
</module>
|
||||
|
||||
Generated
-5
@@ -1,5 +0,0 @@
|
||||
<?xml version="1.0" encoding="UTF-8"?>
|
||||
<project version="4">
|
||||
<component name="Encoding" useUTFGuessing="true" native2AsciiForPropertiesFiles="false" />
|
||||
</project>
|
||||
|
||||
Generated
-11
@@ -1,11 +0,0 @@
|
||||
<?xml version="1.0" encoding="UTF-8"?>
|
||||
<project version="4">
|
||||
<component name="DependencyValidationManager">
|
||||
<option name="SKIP_IMPORT_STATEMENTS" value="false" />
|
||||
</component>
|
||||
<component name="ProjectRootManager" version="2" />
|
||||
<component name="SvnBranchConfigurationManager">
|
||||
<option name="mySupportsUserInfoFilter" value="true" />
|
||||
</component>
|
||||
</project>
|
||||
|
||||
Generated
-9
@@ -1,9 +0,0 @@
|
||||
<?xml version="1.0" encoding="UTF-8"?>
|
||||
<project version="4">
|
||||
<component name="ProjectModuleManager">
|
||||
<modules>
|
||||
<module fileurl="file://$PROJECT_DIR$/.idea/angular.js.iml" filepath="$PROJECT_DIR$/.idea/angular.js.iml" />
|
||||
</modules>
|
||||
</component>
|
||||
</project>
|
||||
|
||||
Generated
-68
@@ -1,68 +0,0 @@
|
||||
<?xml version="1.0" encoding="UTF-8"?>
|
||||
<project version="4">
|
||||
<component name="CodeStyleSettingsManager">
|
||||
<option name="PER_PROJECT_SETTINGS">
|
||||
<value>
|
||||
<option name="USE_SAME_INDENTS" value="true" />
|
||||
<option name="OTHER_INDENT_OPTIONS">
|
||||
<value>
|
||||
<option name="INDENT_SIZE" value="2" />
|
||||
<option name="CONTINUATION_INDENT_SIZE" value="4" />
|
||||
<option name="TAB_SIZE" value="2" />
|
||||
<option name="USE_TAB_CHARACTER" value="false" />
|
||||
<option name="SMART_TABS" value="false" />
|
||||
<option name="LABEL_INDENT_SIZE" value="0" />
|
||||
<option name="LABEL_INDENT_ABSOLUTE" value="false" />
|
||||
</value>
|
||||
</option>
|
||||
<ADDITIONAL_INDENT_OPTIONS fileType="js">
|
||||
<option name="INDENT_SIZE" value="4" />
|
||||
<option name="CONTINUATION_INDENT_SIZE" value="8" />
|
||||
<option name="TAB_SIZE" value="4" />
|
||||
<option name="USE_TAB_CHARACTER" value="false" />
|
||||
<option name="SMART_TABS" value="false" />
|
||||
<option name="LABEL_INDENT_SIZE" value="0" />
|
||||
<option name="LABEL_INDENT_ABSOLUTE" value="false" />
|
||||
</ADDITIONAL_INDENT_OPTIONS>
|
||||
<ADDITIONAL_INDENT_OPTIONS fileType="jsp">
|
||||
<option name="INDENT_SIZE" value="4" />
|
||||
<option name="CONTINUATION_INDENT_SIZE" value="8" />
|
||||
<option name="TAB_SIZE" value="4" />
|
||||
<option name="USE_TAB_CHARACTER" value="false" />
|
||||
<option name="SMART_TABS" value="false" />
|
||||
<option name="LABEL_INDENT_SIZE" value="0" />
|
||||
<option name="LABEL_INDENT_ABSOLUTE" value="false" />
|
||||
</ADDITIONAL_INDENT_OPTIONS>
|
||||
<ADDITIONAL_INDENT_OPTIONS fileType="sass">
|
||||
<option name="INDENT_SIZE" value="2" />
|
||||
<option name="CONTINUATION_INDENT_SIZE" value="8" />
|
||||
<option name="TAB_SIZE" value="4" />
|
||||
<option name="USE_TAB_CHARACTER" value="false" />
|
||||
<option name="SMART_TABS" value="false" />
|
||||
<option name="LABEL_INDENT_SIZE" value="0" />
|
||||
<option name="LABEL_INDENT_ABSOLUTE" value="false" />
|
||||
</ADDITIONAL_INDENT_OPTIONS>
|
||||
<ADDITIONAL_INDENT_OPTIONS fileType="xml">
|
||||
<option name="INDENT_SIZE" value="4" />
|
||||
<option name="CONTINUATION_INDENT_SIZE" value="8" />
|
||||
<option name="TAB_SIZE" value="4" />
|
||||
<option name="USE_TAB_CHARACTER" value="false" />
|
||||
<option name="SMART_TABS" value="false" />
|
||||
<option name="LABEL_INDENT_SIZE" value="0" />
|
||||
<option name="LABEL_INDENT_ABSOLUTE" value="false" />
|
||||
</ADDITIONAL_INDENT_OPTIONS>
|
||||
<ADDITIONAL_INDENT_OPTIONS fileType="yml">
|
||||
<option name="INDENT_SIZE" value="2" />
|
||||
<option name="CONTINUATION_INDENT_SIZE" value="8" />
|
||||
<option name="TAB_SIZE" value="4" />
|
||||
<option name="USE_TAB_CHARACTER" value="false" />
|
||||
<option name="SMART_TABS" value="false" />
|
||||
<option name="LABEL_INDENT_SIZE" value="0" />
|
||||
<option name="LABEL_INDENT_ABSOLUTE" value="false" />
|
||||
</ADDITIONAL_INDENT_OPTIONS>
|
||||
</value>
|
||||
</option>
|
||||
<option name="USE_PER_PROJECT_SETTINGS" value="true" />
|
||||
</component>
|
||||
</project>
|
||||
|
||||
Generated
-15
@@ -1,15 +0,0 @@
|
||||
<component name="ProjectRunConfigurationManager">
|
||||
<configuration default="false" name="gen_docs" type="BashConfigurationType" factoryName="Bash">
|
||||
<option name="INTERPRETER_OPTIONS" value="" />
|
||||
<option name="INTERPRETER_PATH" value="/bin/bash" />
|
||||
<option name="WORKING_DIRECTORY" value="$PROJECT_DIR$" />
|
||||
<option name="PARENT_ENVS" value="true" />
|
||||
<envs />
|
||||
<module name="angular.js" />
|
||||
<option name="SCRIPT_NAME" value="$PROJECT_DIR$/gen_docs.sh" />
|
||||
<option name="PARAMETERS" value="" />
|
||||
<RunnerSettings RunnerId="BashRunner" />
|
||||
<ConfigurationWrapper RunnerId="BashRunner" />
|
||||
<method />
|
||||
</configuration>
|
||||
</component>
|
||||
Generated
-15
@@ -1,15 +0,0 @@
|
||||
<component name="ProjectRunConfigurationManager">
|
||||
<configuration default="false" name="rake compile" type="BashConfigurationType" factoryName="Bash">
|
||||
<option name="INTERPRETER_OPTIONS" value="" />
|
||||
<option name="INTERPRETER_PATH" value="/System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/bin/ruby" />
|
||||
<option name="WORKING_DIRECTORY" value="$PROJECT_DIR$" />
|
||||
<option name="PARENT_ENVS" value="true" />
|
||||
<envs />
|
||||
<module name="angular.js" />
|
||||
<option name="SCRIPT_NAME" value="/usr/bin/rake" />
|
||||
<option name="PARAMETERS" value="compile" />
|
||||
<RunnerSettings RunnerId="BashRunner" />
|
||||
<ConfigurationWrapper RunnerId="BashRunner" />
|
||||
<method />
|
||||
</configuration>
|
||||
</component>
|
||||
Generated
-7
@@ -1,7 +0,0 @@
|
||||
<?xml version="1.0" encoding="UTF-8"?>
|
||||
<project version="4">
|
||||
<component name="VcsDirectoryMappings">
|
||||
<mapping directory="" vcs="Git" />
|
||||
</component>
|
||||
</project>
|
||||
|
||||
@@ -30,6 +30,16 @@
|
||||
</dictionary>
|
||||
</arguments>
|
||||
</buildCommand>
|
||||
<buildCommand>
|
||||
<name>org.eclipse.ui.externaltools.ExternalToolBuilder</name>
|
||||
<triggers>auto,full,incremental,</triggers>
|
||||
<arguments>
|
||||
<dictionary>
|
||||
<key>LaunchConfigHandle</key>
|
||||
<value><project>/.externalToolBuilders/JSTD_perf.launch</value>
|
||||
</dictionary>
|
||||
</arguments>
|
||||
</buildCommand>
|
||||
</buildSpec>
|
||||
<natures>
|
||||
<nature>org.eclipse.wst.jsdt.core.jsNature</nature>
|
||||
|
||||
+941
-41
File diff suppressed because it is too large
Load Diff
@@ -1,5 +1,10 @@
|
||||
Angular
|
||||
======
|
||||
AngularJS
|
||||
=========
|
||||
|
||||
* Web site: http://angularjs.org
|
||||
* Tutorial: http://docs.angularjs.org/#!/tutorial
|
||||
* API Docs: http://docs.angularjs.org
|
||||
* Developer Guide: http://docs.angularjs.org/#!/guide
|
||||
|
||||
Compiling
|
||||
---------
|
||||
@@ -7,6 +12,8 @@ Compiling
|
||||
|
||||
Running Tests
|
||||
-------------
|
||||
rake server:start
|
||||
rake test
|
||||
./server.sh # start the server
|
||||
open http://localhost:9876/capture # capture browser
|
||||
./test.sh # run all unit tests
|
||||
|
||||
|
||||
|
||||
@@ -1,60 +1,8 @@
|
||||
require 'yaml'
|
||||
include FileUtils
|
||||
|
||||
ANGULAR = [
|
||||
'src/Angular.js',
|
||||
'src/JSON.js',
|
||||
'src/Compiler.js',
|
||||
'src/Scope.js',
|
||||
'src/Injector.js',
|
||||
'src/parser.js',
|
||||
'src/Resource.js',
|
||||
'src/Browser.js',
|
||||
'src/sanitizer.js',
|
||||
'src/jqLite.js',
|
||||
'src/apis.js',
|
||||
'src/filters.js',
|
||||
'src/formatters.js',
|
||||
'src/validators.js',
|
||||
'src/service/cookieStore.js',
|
||||
'src/service/cookies.js',
|
||||
'src/service/defer.js',
|
||||
'src/service/document.js',
|
||||
'src/service/exceptionHandler.js',
|
||||
'src/service/hover.js',
|
||||
'src/service/invalidWidgets.js',
|
||||
'src/service/location.js',
|
||||
'src/service/log.js',
|
||||
'src/service/resource.js',
|
||||
'src/service/route.js',
|
||||
'src/service/updateView.js',
|
||||
'src/service/window.js',
|
||||
'src/service/xhr.bulk.js',
|
||||
'src/service/xhr.cache.js',
|
||||
'src/service/xhr.error.js',
|
||||
'src/service/xhr.js',
|
||||
'src/directives.js',
|
||||
'src/markups.js',
|
||||
'src/widgets.js',
|
||||
'src/AngularPublic.js',
|
||||
]
|
||||
|
||||
ANGULAR_SCENARIO = [
|
||||
'src/scenario/Scenario.js',
|
||||
'src/scenario/Application.js',
|
||||
'src/scenario/Describe.js',
|
||||
'src/scenario/Future.js',
|
||||
'src/scenario/ObjectModel.js',
|
||||
'src/scenario/Describe.js',
|
||||
'src/scenario/Runner.js',
|
||||
'src/scenario/SpecRunner.js',
|
||||
'src/scenario/dsl.js',
|
||||
'src/scenario/matchers.js',
|
||||
'src/scenario/output/Html.js',
|
||||
'src/scenario/output/Json.js',
|
||||
'src/scenario/output/Xml.js',
|
||||
'src/scenario/output/Object.js',
|
||||
]
|
||||
content = File.open('angularFiles.js', 'r') {|f| f.read }
|
||||
files = eval(content.gsub(/\};(\s|\S)*/, '}').gsub(/angularFiles = /, '').gsub(/:/, '=>'));
|
||||
|
||||
BUILD_DIR = 'build'
|
||||
|
||||
@@ -64,6 +12,16 @@ task :default => [:compile, :test]
|
||||
desc 'Init the build workspace'
|
||||
task :init do
|
||||
FileUtils.mkdir(BUILD_DIR) unless File.directory?(BUILD_DIR)
|
||||
|
||||
v = YAML::load( File.open( 'version.yaml' ) )
|
||||
match = v['version'].match(/^([^-]*)(-snapshot)?$/)
|
||||
|
||||
NG_VERSION = Struct.new(:full, :major, :minor, :dot, :codename).
|
||||
new(match[1] + (match[2] ? ('-' + %x(git rev-parse HEAD)[0..7]) : ''),
|
||||
match[1].split('.')[0],
|
||||
match[1].split('.')[1],
|
||||
match[1].split('.')[2].sub(/\D+.*$/, ''),
|
||||
v['codename'])
|
||||
end
|
||||
|
||||
|
||||
@@ -78,145 +36,228 @@ desc 'Compile Scenario'
|
||||
task :compile_scenario => :init do
|
||||
|
||||
deps = [
|
||||
'lib/jquery/jquery-1.4.2.js',
|
||||
'lib/jquery/jquery.js',
|
||||
'src/scenario/angular.prefix',
|
||||
ANGULAR,
|
||||
ANGULAR_SCENARIO,
|
||||
files['angularSrc'],
|
||||
files['angularScenario'],
|
||||
'src/scenario/angular.suffix',
|
||||
]
|
||||
|
||||
concat = 'cat ' + deps.flatten.join(' ')
|
||||
|
||||
File.open(path_to('angular-scenario.js'), 'w') do |f|
|
||||
f.write(%x{#{concat}})
|
||||
f.write(%x{#{concat}}.gsub('"NG_VERSION_FULL"', NG_VERSION.full))
|
||||
f.write(gen_css('css/angular.css') + "\n")
|
||||
f.write(gen_css('css/angular-scenario.css'))
|
||||
end
|
||||
end
|
||||
|
||||
desc 'Compile JSTD Scenario Adapter'
|
||||
task :compile_jstd_scenario_adapter => :init do
|
||||
|
||||
desc 'Generate IE css js patch'
|
||||
task :generate_ie_compat => :init do
|
||||
css = File.open('css/angular.css', 'r') {|f| f.read }
|
||||
deps = [
|
||||
'src/jstd-scenario-adapter/angular.prefix',
|
||||
'src/jstd-scenario-adapter/Adapter.js',
|
||||
'src/jstd-scenario-adapter/angular.suffix',
|
||||
]
|
||||
|
||||
# finds all css rules that contain backround images and extracts the rule name(s), content type of
|
||||
# the image and base64 encoded image data
|
||||
r = /\n([^\{\n]+)\s*\{[^\}]*background-image:\s*url\("data:([^;]+);base64,([^"]+)"\);[^\}]*\}/
|
||||
concat = 'cat ' + deps.flatten.join(' ')
|
||||
|
||||
images = css.scan(r)
|
||||
File.open(path_to('jstd-scenario-adapter.js'), 'w') do |f|
|
||||
f.write(%x{#{concat}}.gsub('"NG_VERSION_FULL"', NG_VERSION.full))
|
||||
end
|
||||
|
||||
# create a js file with multipart header containing the extracted images. the entire file *must*
|
||||
# be CRLF (\r\n) delimited
|
||||
File.open(path_to('angular-ie-compat.js'), 'w') do |f|
|
||||
f.write("/*\r\n" +
|
||||
"Content-Type: multipart/related; boundary=\"_\"\r\n" +
|
||||
"\r\n")
|
||||
|
||||
images.each_index do |idx|
|
||||
f.write("--_\r\n" +
|
||||
"Content-Location:img#{idx}\r\n" +
|
||||
"Content-Transfer-Encoding:base64\r\n" +
|
||||
"\r\n" +
|
||||
images[idx][2] + "\r\n")
|
||||
end
|
||||
|
||||
f.write("--_--\r\n" +
|
||||
"*/\r\n")
|
||||
|
||||
# generate a css string containing *background-image rules for IE that point to the mime type
|
||||
# images in the header
|
||||
cssString = ''
|
||||
images.each_index do |idx|
|
||||
cssString += "#{images[idx][0]}{*background-image:url(\"mhtml:' + jsUri + '!img#{idx}\")}"
|
||||
end
|
||||
|
||||
# generate a javascript closure that contains a function which will append the generated css
|
||||
# string as a stylesheet to the current html document
|
||||
jsString = "(function(){ \r\n" +
|
||||
" var jsUri = document.location.href.replace(/\\/[^\/]+(#.*)?$/, '/') + " +
|
||||
" document.getElementById('ng-ie-compat').src; \r\n" +
|
||||
" var css = '#{cssString}' \r\n" +
|
||||
" var s = document.createElement('style'); \r\n" +
|
||||
" s.setAttribute('type', 'text/css'); \r\n" +
|
||||
" if (s.styleSheet) { \r\n" +
|
||||
" s.styleSheet.cssText = css; \r\n" +
|
||||
" } else { \r\n" +
|
||||
" s.appendChild(document.createTextNode(css)); \r\n" +
|
||||
" } \r\n" +
|
||||
" document.getElementsByTagName('head')[0].appendChild(s); \r\n" +
|
||||
"})();\r\n"
|
||||
|
||||
f.write(jsString)
|
||||
# TODO(vojta) use jstd configuration when implemented
|
||||
# (instead of including jstd-adapter-config.js)
|
||||
File.open(path_to('jstd-scenario-adapter-config.js'), 'w') do |f|
|
||||
f.write("/**\r\n" +
|
||||
" * Configuration for jstd scenario adapter \n */\n" +
|
||||
"var jstdScenarioAdapter = {\n relativeUrlPrefix: '/build/docs/'\n};\n")
|
||||
end
|
||||
end
|
||||
|
||||
|
||||
desc 'Compile JavaScript'
|
||||
task :compile => [:init, :compile_scenario, :generate_ie_compat] do
|
||||
task :compile => [:init, :compile_scenario, :compile_jstd_scenario_adapter] do
|
||||
|
||||
deps = [
|
||||
'src/angular.prefix',
|
||||
ANGULAR,
|
||||
files['angularSrc'],
|
||||
'src/angular.suffix',
|
||||
]
|
||||
|
||||
File.open(path_to('angular.js'), 'w') do |f|
|
||||
concat = 'cat ' + deps.flatten.join(' ')
|
||||
f.write(%x{#{concat}})
|
||||
|
||||
content = %x{#{concat}}.
|
||||
gsub('"NG_VERSION_FULL"', NG_VERSION.full).
|
||||
gsub('"NG_VERSION_MAJOR"', NG_VERSION.major).
|
||||
gsub('"NG_VERSION_MINOR"', NG_VERSION.minor).
|
||||
gsub('"NG_VERSION_DOT"', NG_VERSION.dot).
|
||||
gsub('"NG_VERSION_CODENAME"', NG_VERSION.codename).
|
||||
gsub(/^\s*['"]use strict['"];?\s*$/, ''). # remove all file-specific strict mode flags
|
||||
gsub(/'USE STRICT'/, "'use strict'") # rename the placeholder in angular.prefix
|
||||
|
||||
f.write(content)
|
||||
f.write(gen_css('css/angular.css', true))
|
||||
end
|
||||
|
||||
%x(java -jar lib/closure-compiler/compiler.jar \
|
||||
--compilation_level SIMPLE_OPTIMIZATIONS \
|
||||
--language_in ECMASCRIPT5_STRICT \
|
||||
--js #{path_to('angular.js')} \
|
||||
--js_output_file #{path_to('angular.min.js')})
|
||||
|
||||
FileUtils.cp_r 'i18n/locale', path_to('i18n')
|
||||
|
||||
File.open(path_to('angular-loader.js'), 'w') do |f|
|
||||
concat = 'cat ' + [
|
||||
'src/loader.prefix',
|
||||
'src/loader.js',
|
||||
'src/loader.suffix'].flatten.join(' ')
|
||||
|
||||
content = %x{#{concat}}.
|
||||
gsub('"NG_VERSION_FULL"', NG_VERSION.full).
|
||||
gsub(/^\s*['"]use strict['"];?\s*$/, '') # remove all file-specific strict mode flags
|
||||
|
||||
f.write(content)
|
||||
end
|
||||
|
||||
%x(java -jar lib/closure-compiler/compiler.jar \
|
||||
--compilation_level SIMPLE_OPTIMIZATIONS \
|
||||
--language_in ECMASCRIPT5_STRICT \
|
||||
--js #{path_to('angular-loader.js')} \
|
||||
--js_output_file #{path_to('angular-loader.min.js')})
|
||||
|
||||
|
||||
end
|
||||
|
||||
|
||||
desc 'Generate docs'
|
||||
task :docs do
|
||||
task :docs => [:init] do
|
||||
`node docs/src/gen-docs.js`
|
||||
File.open(path_to('docs/.htaccess'), File::RDWR) do |f|
|
||||
text = f.read
|
||||
f.truncate 0
|
||||
f.rewind
|
||||
f.write text.sub('"NG_VERSION_FULL"', NG_VERSION.full)
|
||||
end
|
||||
end
|
||||
|
||||
|
||||
desc 'Create angular distribution'
|
||||
task :package => [:clean, :compile, :docs] do
|
||||
v = YAML::load( File.open( 'version.yaml' ) )['version']
|
||||
match = v.match(/^([^-]*)(-snapshot)?$/)
|
||||
version = match[1] + (match[2] ? ('-' + %x(git rev-parse HEAD)[0..7]) : '')
|
||||
tarball = "angular-#{NG_VERSION.full}.tgz"
|
||||
|
||||
tarball = "angular-#{version}.tgz"
|
||||
|
||||
pkg_dir = path_to("pkg/angular-#{version}")
|
||||
pkg_dir = path_to("pkg/angular-#{NG_VERSION.full}")
|
||||
FileUtils.rm_r(path_to('pkg'), :force => true)
|
||||
FileUtils.mkdir_p(pkg_dir)
|
||||
|
||||
['src/angular-mocks.js',
|
||||
path_to('angular.js'),
|
||||
path_to('angular-loader.js'),
|
||||
path_to('angular.min.js'),
|
||||
path_to('angular-ie-compat.js'),
|
||||
path_to('angular-scenario.js')
|
||||
path_to('angular-loader.min.js'),
|
||||
path_to('angular-scenario.js'),
|
||||
path_to('jstd-scenario-adapter.js'),
|
||||
path_to('jstd-scenario-adapter-config.js'),
|
||||
].each do |src|
|
||||
dest = src.gsub(/^[^\/]+\//, '').gsub(/((\.min)?\.js)$/, "-#{version}\\1")
|
||||
dest = src.gsub(/^[^\/]+\//, '').gsub(/((\.min)?\.js)$/, "-#{NG_VERSION.full}\\1")
|
||||
FileUtils.cp(src, pkg_dir + '/' + dest)
|
||||
end
|
||||
|
||||
FileUtils.cp_r path_to('docs'), "#{pkg_dir}/docs-#{version}"
|
||||
FileUtils.cp_r path_to('i18n'), "#{pkg_dir}/i18n-#{NG_VERSION.full}"
|
||||
FileUtils.cp_r path_to('docs'), "#{pkg_dir}/docs-#{NG_VERSION.full}"
|
||||
|
||||
File.open("#{pkg_dir}/docs-#{version}/index.html", File::RDWR) do |f|
|
||||
File.open("#{pkg_dir}/angular-mocks-#{NG_VERSION.full}.js", File::RDWR) do |f|
|
||||
text = f.read
|
||||
f.truncate 0
|
||||
f.rewind
|
||||
f.write text.sub('angular.min.js', "angular-#{version}.min.js")
|
||||
f.write text.sub('"NG_VERSION_FULL"', NG_VERSION.full)
|
||||
end
|
||||
|
||||
File.open("#{pkg_dir}/docs-#{version}/docs-scenario.html", File::RDWR) do |f|
|
||||
File.open("#{pkg_dir}/docs-#{NG_VERSION.full}/index.html", File::RDWR) do |f|
|
||||
text = f.read
|
||||
f.truncate 0
|
||||
f.rewind
|
||||
f.write text.sub('angular-scenario.js', "angular-scenario-#{version}.js")
|
||||
f.write text.sub('angular.min.js', "angular-#{NG_VERSION.full}.min.js").
|
||||
sub('/build/docs/', "/#{NG_VERSION.full}/docs-#{NG_VERSION.full}/")
|
||||
end
|
||||
|
||||
|
||||
File.open("#{pkg_dir}/docs-#{NG_VERSION.full}/index-jq.html", File::RDWR) do |f|
|
||||
text = f.read
|
||||
f.truncate 0
|
||||
f.rewind
|
||||
f.write text.sub('angular.min.js', "angular-#{NG_VERSION.full}.min.js").
|
||||
sub('/build/docs/', "/#{NG_VERSION.full}/docs-#{NG_VERSION.full}/")
|
||||
end
|
||||
|
||||
|
||||
File.open("#{pkg_dir}/docs-#{NG_VERSION.full}/index-nocache.html", File::RDWR) do |f|
|
||||
text = f.read
|
||||
f.truncate 0
|
||||
f.rewind
|
||||
f.write text.sub('angular.min.js', "angular-#{NG_VERSION.full}.min.js").
|
||||
sub('/build/docs/', "/#{NG_VERSION.full}/docs-#{NG_VERSION.full}/")
|
||||
end
|
||||
|
||||
|
||||
File.open("#{pkg_dir}/docs-#{NG_VERSION.full}/index-jq-nocache.html", File::RDWR) do |f|
|
||||
text = f.read
|
||||
f.truncate 0
|
||||
f.rewind
|
||||
f.write text.sub('angular.min.js', "angular-#{NG_VERSION.full}.min.js").
|
||||
sub('/build/docs/', "/#{NG_VERSION.full}/docs-#{NG_VERSION.full}/")
|
||||
end
|
||||
|
||||
|
||||
File.open("#{pkg_dir}/docs-#{NG_VERSION.full}/index-debug.html", File::RDWR) do |f|
|
||||
text = f.read
|
||||
f.truncate 0
|
||||
f.rewind
|
||||
f.write text.sub('../angular.js', "../angular-#{NG_VERSION.full}.js").
|
||||
sub('/build/docs/', "/#{NG_VERSION.full}/docs-#{NG_VERSION.full}/")
|
||||
end
|
||||
|
||||
|
||||
File.open("#{pkg_dir}/docs-#{NG_VERSION.full}/index-jq-debug.html", File::RDWR) do |f|
|
||||
text = f.read
|
||||
f.truncate 0
|
||||
f.rewind
|
||||
f.write text.sub('../angular.js', "../angular-#{NG_VERSION.full}.js").
|
||||
sub('/build/docs/', "/#{NG_VERSION.full}/docs-#{NG_VERSION.full}/")
|
||||
end
|
||||
|
||||
File.open("#{pkg_dir}/docs-#{NG_VERSION.full}/docs-scenario.html", File::RDWR) do |f|
|
||||
text = f.read
|
||||
f.truncate 0
|
||||
f.rewind
|
||||
f.write text.sub('angular-scenario.js', "angular-scenario-#{NG_VERSION.full}.js")
|
||||
end
|
||||
|
||||
File.open("#{pkg_dir}/docs-#{NG_VERSION.full}/appcache.manifest", File::RDWR) do |f|
|
||||
text = f.read
|
||||
f.truncate 0
|
||||
f.rewind
|
||||
f.write text.sub('angular.min.js', "angular-#{NG_VERSION.full}.min.js").
|
||||
sub('/build/docs/', "/#{NG_VERSION.full}/docs-#{NG_VERSION.full}/")
|
||||
end
|
||||
|
||||
File.open("#{pkg_dir}/docs-#{NG_VERSION.full}/appcache-offline.manifest", File::RDWR) do |f|
|
||||
text = f.read
|
||||
f.truncate 0
|
||||
f.rewind
|
||||
f.write text.sub('angular.min.js', "angular-#{NG_VERSION.full}.min.js").
|
||||
sub('/build/docs/', "/#{NG_VERSION.full}/docs-#{NG_VERSION.full}/")
|
||||
end
|
||||
|
||||
|
||||
%x(tar -czf #{path_to(tarball)} -C #{path_to('pkg')} .)
|
||||
|
||||
FileUtils.cp path_to(tarball), pkg_dir
|
||||
FileUtils.mv pkg_dir, path_to(['pkg', NG_VERSION.full])
|
||||
|
||||
puts "Package created: #{path_to(tarball)}"
|
||||
end
|
||||
|
||||
|
||||
Vendored
+191
@@ -0,0 +1,191 @@
|
||||
angularFiles = {
|
||||
'angularSrc': [
|
||||
'src/Angular.js',
|
||||
'src/loader.js',
|
||||
'src/AngularPublic.js',
|
||||
'src/JSON.js',
|
||||
'src/Injector.js',
|
||||
'src/Resource.js',
|
||||
'src/jqLite.js',
|
||||
'src/apis.js',
|
||||
'src/service/anchorScroll.js',
|
||||
'src/service/browser.js',
|
||||
'src/service/cacheFactory.js',
|
||||
'src/service/compiler.js',
|
||||
'src/service/controller.js',
|
||||
'src/service/cookieStore.js',
|
||||
'src/service/cookies.js',
|
||||
'src/service/defer.js',
|
||||
'src/service/document.js',
|
||||
'src/service/exceptionHandler.js',
|
||||
'src/service/filter.js',
|
||||
'src/service/filter/filter.js',
|
||||
'src/service/filter/filters.js',
|
||||
'src/service/filter/limitTo.js',
|
||||
'src/service/filter/orderBy.js',
|
||||
'src/service/interpolate.js',
|
||||
'src/service/location.js',
|
||||
'src/service/log.js',
|
||||
'src/service/resource.js',
|
||||
'src/service/parse.js',
|
||||
'src/service/q.js',
|
||||
'src/service/route.js',
|
||||
'src/service/routeParams.js',
|
||||
'src/service/scope.js',
|
||||
'src/service/sanitize.js',
|
||||
'src/service/sniffer.js',
|
||||
'src/service/window.js',
|
||||
'src/service/http.js',
|
||||
'src/service/httpBackend.js',
|
||||
'src/service/locale.js',
|
||||
'src/directive/directives.js',
|
||||
'src/directive/a.js',
|
||||
'src/directive/booleanAttrDirs.js',
|
||||
'src/directive/form.js',
|
||||
'src/directive/input.js',
|
||||
'src/directive/ngBind.js',
|
||||
'src/directive/ngClass.js',
|
||||
'src/directive/ngCloak.js',
|
||||
'src/directive/ngController.js',
|
||||
'src/directive/ngEventDirs.js',
|
||||
'src/directive/ngInclude.js',
|
||||
'src/directive/ngInit.js',
|
||||
'src/directive/ngNonBindable.js',
|
||||
'src/directive/ngPluralize.js',
|
||||
'src/directive/ngRepeat.js',
|
||||
'src/directive/ngShowHide.js',
|
||||
'src/directive/ngStyle.js',
|
||||
'src/directive/ngSwitch.js',
|
||||
'src/directive/ngTransclude.js',
|
||||
'src/directive/ngView.js',
|
||||
'src/directive/script.js',
|
||||
'src/directive/select.js',
|
||||
'src/directive/style.js'
|
||||
],
|
||||
|
||||
'angularScenario': [
|
||||
'src/scenario/Scenario.js',
|
||||
'src/scenario/Application.js',
|
||||
'src/scenario/Describe.js',
|
||||
'src/scenario/Future.js',
|
||||
'src/scenario/ObjectModel.js',
|
||||
'src/scenario/Describe.js',
|
||||
'src/scenario/Runner.js',
|
||||
'src/scenario/SpecRunner.js',
|
||||
'src/scenario/dsl.js',
|
||||
'src/scenario/matchers.js',
|
||||
'src/scenario/output/Html.js',
|
||||
'src/scenario/output/Json.js',
|
||||
'src/scenario/output/Xml.js',
|
||||
'src/scenario/output/Object.js'
|
||||
],
|
||||
|
||||
'jstd': [
|
||||
'lib/jasmine/jasmine.js',
|
||||
'lib/jasmine-jstd-adapter/JasmineAdapter.js',
|
||||
'lib/jquery/jquery.js',
|
||||
'test/jquery_remove.js',
|
||||
'@angularSrc',
|
||||
'example/personalLog/*.js',
|
||||
'test/testabilityPatch.js',
|
||||
'test/matchers.js',
|
||||
'src/scenario/Scenario.js',
|
||||
'src/scenario/output/*.js',
|
||||
'src/jstd-scenario-adapter/*.js',
|
||||
'src/scenario/*.js',
|
||||
'src/angular-mocks.js',
|
||||
'test/scenario/*.js',
|
||||
'test/scenario/output/*.js',
|
||||
'test/jstd-scenario-adapter/*.js',
|
||||
'test/*.js',
|
||||
'test/service/*.js',
|
||||
'test/service/filter/*.js',
|
||||
'test/directive/*.js',
|
||||
'example/personalLog/test/*.js'
|
||||
],
|
||||
|
||||
'jstdExclude': [
|
||||
'test/jquery_alias.js',
|
||||
'src/angular-bootstrap.js',
|
||||
'src/scenario/angular-bootstrap.js'
|
||||
],
|
||||
|
||||
'jstdScenario': [
|
||||
'build/angular-scenario.js',
|
||||
'build/jstd-scenario-adapter-config.js',
|
||||
'build/jstd-scenario-adapter.js',
|
||||
'build/docs/docs-scenario.js'
|
||||
],
|
||||
|
||||
'jstdMocks': [
|
||||
'lib/jasmine/jasmine.js',
|
||||
'lib/jasmine-jstd-adapter/JasmineAdapter.js',
|
||||
'build/angular.js',
|
||||
'src/angular-mocks.js',
|
||||
'test/matchers.js',
|
||||
'test/angular-mocksSpec.js'
|
||||
],
|
||||
|
||||
'jstdPerf': [
|
||||
'lib/jasmine/jasmine.js',
|
||||
'lib/jasmine-jstd-adapter/JasmineAdapter.js',
|
||||
'angularSrc',
|
||||
'src/angular-mocks.js',
|
||||
'perf/data/*.js',
|
||||
'perf/testUtils.js',
|
||||
'perf/*.js'
|
||||
],
|
||||
|
||||
'jstdPerfExclude': [
|
||||
'src/angular-bootstrap.js',
|
||||
'src/scenario/angular-bootstrap.js'
|
||||
],
|
||||
|
||||
'jstdJquery': [
|
||||
'lib/jasmine/jasmine.js',
|
||||
'lib/jasmine-jstd-adapter/JasmineAdapter.js',
|
||||
'lib/jquery/jquery.js',
|
||||
'test/jquery_alias.js',
|
||||
'@angularSrc',
|
||||
'example/personalLog/*.js',
|
||||
'test/testabilityPatch.js',
|
||||
'test/matchers.js',
|
||||
'src/scenario/Scenario.js',
|
||||
'src/scenario/output/*.js',
|
||||
'src/jstd-scenario-adapter/*.js',
|
||||
'src/scenario/*.js',
|
||||
'src/angular-mocks.js',
|
||||
'test/scenario/*.js',
|
||||
'test/scenario/output/*.js',
|
||||
'test/jstd-scenario-adapter/*.js',
|
||||
'test/*.js',
|
||||
'test/service/*.js',
|
||||
'test/directive/*.js',
|
||||
'example/personalLog/test/*.js'
|
||||
],
|
||||
|
||||
'jstdJqueryExclude': [
|
||||
'src/angular-bootstrap.js',
|
||||
'src/scenario/angular-bootstrap.js',
|
||||
'test/jquery_remove.js'
|
||||
]
|
||||
};
|
||||
|
||||
// Execute only in slim-jim
|
||||
if (typeof JASMINE_ADAPTER !== 'undefined') {
|
||||
// SlimJim config
|
||||
files = [JASMINE, JASMINE_ADAPTER];
|
||||
angularFiles.jstd.forEach(function(pattern) {
|
||||
// replace angular source
|
||||
if (pattern === '@angularSrc') files = files.concat(angularFiles.angularSrc);
|
||||
// ignore jstd and jasmine files
|
||||
else if (!/jstd|jasmine/.test(pattern)) files.push(pattern);
|
||||
});
|
||||
|
||||
exclude = angularFiles.jstdExclude;
|
||||
|
||||
autoWatch = true;
|
||||
autoWatchInterval = 1;
|
||||
logLevel = LOG_INFO;
|
||||
logColors = true;
|
||||
}
|
||||
+5
-82
@@ -1,87 +1,10 @@
|
||||
@charset "UTF-8";
|
||||
|
||||
.ng-format-negative {
|
||||
color: red;
|
||||
[ng\:cloak], [ng-cloak], [data-ng-cloak], [x-ng-cloak],
|
||||
.ng-cloak, .x-ng-cloak {
|
||||
display: none;
|
||||
}
|
||||
|
||||
.ng-exception {
|
||||
border: 2px solid #FF0000;
|
||||
font-family: "Courier New", Courier, monospace;
|
||||
font-size: smaller;
|
||||
white-space: pre;
|
||||
}
|
||||
|
||||
.ng-validation-error {
|
||||
border: 2px solid #FF0000;
|
||||
}
|
||||
|
||||
|
||||
/*****************
|
||||
* TIP
|
||||
*****************/
|
||||
#ng-callout {
|
||||
margin: 0;
|
||||
padding: 0;
|
||||
border: 0;
|
||||
outline: 0;
|
||||
font-size: 13px;
|
||||
font-weight: normal;
|
||||
font-family: Verdana, Arial, Helvetica, sans-serif;
|
||||
vertical-align: baseline;
|
||||
background: transparent;
|
||||
text-decoration: none;
|
||||
}
|
||||
|
||||
#ng-callout .ng-arrow-left{
|
||||
background-image: url("data:image/gif;base64,R0lGODlhCwAXAKIAAMzMzO/v7/f39////////wAAAAAAAAAAACH5BAUUAAQALAAAAAALABcAAAMrSLoc/AG8FeUUIN+sGebWAnbKSJodqqlsOxJtqYooU9vvk+vcJIcTkg+QAAA7");
|
||||
background-repeat: no-repeat;
|
||||
background-position: left top;
|
||||
position: absolute;
|
||||
z-index:101;
|
||||
left:-12px;
|
||||
height:23px;
|
||||
width:10px;
|
||||
top:-3px;
|
||||
}
|
||||
|
||||
#ng-callout .ng-arrow-right{
|
||||
background-image: url("data:image/gif;base64,R0lGODlhCwAXAKIAAMzMzO/v7/f39////////wAAAAAAAAAAACH5BAUUAAQALAAAAAALABcAAAMrCLTcoM29yN6k9socs91e5X3EyJloipYrO4ohTMqA0Fn2XVNswJe+H+SXAAA7");
|
||||
background-repeat: no-repeat;
|
||||
background-position: left top;
|
||||
position: absolute;
|
||||
z-index:101;
|
||||
height:23px;
|
||||
width:11px;
|
||||
top:-2px;
|
||||
}
|
||||
|
||||
#ng-callout {
|
||||
position: absolute;
|
||||
z-index:100;
|
||||
border: 2px solid #CCCCCC;
|
||||
background-color: #fff;
|
||||
}
|
||||
|
||||
#ng-callout .ng-content{
|
||||
padding:10px 10px 10px 10px;
|
||||
color:#333333;
|
||||
}
|
||||
|
||||
#ng-callout .ng-title{
|
||||
background-color: #CCCCCC;
|
||||
text-align: left;
|
||||
padding-left: 8px;
|
||||
padding-bottom: 5px;
|
||||
padding-top: 2px;
|
||||
font-weight:bold;
|
||||
}
|
||||
|
||||
|
||||
/*****************
|
||||
* indicators
|
||||
*****************/
|
||||
.ng-input-indicator-wait {
|
||||
background-image: url("data:image/png;base64,R0lGODlhEAAQAPQAAP///wAAAPDw8IqKiuDg4EZGRnp6egAAAFhYWCQkJKysrL6+vhQUFJycnAQEBDY2NmhoaAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACH/C05FVFNDQVBFMi4wAwEAAAAh/hpDcmVhdGVkIHdpdGggYWpheGxvYWQuaW5mbwAh+QQJCgAAACwAAAAAEAAQAAAFdyAgAgIJIeWoAkRCCMdBkKtIHIngyMKsErPBYbADpkSCwhDmQCBethRB6Vj4kFCkQPG4IlWDgrNRIwnO4UKBXDufzQvDMaoSDBgFb886MiQadgNABAokfCwzBA8LCg0Egl8jAggGAA1kBIA1BAYzlyILczULC2UhACH5BAkKAAAALAAAAAAQABAAAAV2ICACAmlAZTmOREEIyUEQjLKKxPHADhEvqxlgcGgkGI1DYSVAIAWMx+lwSKkICJ0QsHi9RgKBwnVTiRQQgwF4I4UFDQQEwi6/3YSGWRRmjhEETAJfIgMFCnAKM0KDV4EEEAQLiF18TAYNXDaSe3x6mjidN1s3IQAh+QQJCgAAACwAAAAAEAAQAAAFeCAgAgLZDGU5jgRECEUiCI+yioSDwDJyLKsXoHFQxBSHAoAAFBhqtMJg8DgQBgfrEsJAEAg4YhZIEiwgKtHiMBgtpg3wbUZXGO7kOb1MUKRFMysCChAoggJCIg0GC2aNe4gqQldfL4l/Ag1AXySJgn5LcoE3QXI3IQAh+QQJCgAAACwAAAAAEAAQAAAFdiAgAgLZNGU5joQhCEjxIssqEo8bC9BRjy9Ag7GILQ4QEoE0gBAEBcOpcBA0DoxSK/e8LRIHn+i1cK0IyKdg0VAoljYIg+GgnRrwVS/8IAkICyosBIQpBAMoKy9dImxPhS+GKkFrkX+TigtLlIyKXUF+NjagNiEAIfkECQoAAAAsAAAAABAAEAAABWwgIAICaRhlOY4EIgjH8R7LKhKHGwsMvb4AAy3WODBIBBKCsYA9TjuhDNDKEVSERezQEL0WrhXucRUQGuik7bFlngzqVW9LMl9XWvLdjFaJtDFqZ1cEZUB0dUgvL3dgP4WJZn4jkomWNpSTIyEAIfkECQoAAAAsAAAAABAAEAAABX4gIAICuSxlOY6CIgiD8RrEKgqGOwxwUrMlAoSwIzAGpJpgoSDAGifDY5kopBYDlEpAQBwevxfBtRIUGi8xwWkDNBCIwmC9Vq0aiQQDQuK+VgQPDXV9hCJjBwcFYU5pLwwHXQcMKSmNLQcIAExlbH8JBwttaX0ABAcNbWVbKyEAIfkECQoAAAAsAAAAABAAEAAABXkgIAICSRBlOY7CIghN8zbEKsKoIjdFzZaEgUBHKChMJtRwcWpAWoWnifm6ESAMhO8lQK0EEAV3rFopIBCEcGwDKAqPh4HUrY4ICHH1dSoTFgcHUiZjBhAJB2AHDykpKAwHAwdzf19KkASIPl9cDgcnDkdtNwiMJCshACH5BAkKAAAALAAAAAAQABAAAAV3ICACAkkQZTmOAiosiyAoxCq+KPxCNVsSMRgBsiClWrLTSWFoIQZHl6pleBh6suxKMIhlvzbAwkBWfFWrBQTxNLq2RG2yhSUkDs2b63AYDAoJXAcFRwADeAkJDX0AQCsEfAQMDAIPBz0rCgcxky0JRWE1AmwpKyEAIfkECQoAAAAsAAAAABAAEAAABXkgIAICKZzkqJ4nQZxLqZKv4NqNLKK2/Q4Ek4lFXChsg5ypJjs1II3gEDUSRInEGYAw6B6zM4JhrDAtEosVkLUtHA7RHaHAGJQEjsODcEg0FBAFVgkQJQ1pAwcDDw8KcFtSInwJAowCCA6RIwqZAgkPNgVpWndjdyohACH5BAkKAAAALAAAAAAQABAAAAV5ICACAimc5KieLEuUKvm2xAKLqDCfC2GaO9eL0LABWTiBYmA06W6kHgvCqEJiAIJiu3gcvgUsscHUERm+kaCxyxa+zRPk0SgJEgfIvbAdIAQLCAYlCj4DBw0IBQsMCjIqBAcPAooCBg9pKgsJLwUFOhCZKyQDA3YqIQAh+QQJCgAAACwAAAAAEAAQAAAFdSAgAgIpnOSonmxbqiThCrJKEHFbo8JxDDOZYFFb+A41E4H4OhkOipXwBElYITDAckFEOBgMQ3arkMkUBdxIUGZpEb7kaQBRlASPg0FQQHAbEEMGDSVEAA1QBhAED1E0NgwFAooCDWljaQIQCE5qMHcNhCkjIQAh+QQJCgAAACwAAAAAEAAQAAAFeSAgAgIpnOSoLgxxvqgKLEcCC65KEAByKK8cSpA4DAiHQ/DkKhGKh4ZCtCyZGo6F6iYYPAqFgYy02xkSaLEMV34tELyRYNEsCQyHlvWkGCzsPgMCEAY7Cg04Uk48LAsDhRA8MVQPEF0GAgqYYwSRlycNcWskCkApIyEAOwAAAAAAAAAAAA==");
|
||||
background-position: right;
|
||||
background-repeat: no-repeat;
|
||||
ng\:form {
|
||||
display: block;
|
||||
}
|
||||
|
||||
@@ -1,15 +0,0 @@
|
||||
@workInProgress
|
||||
@ngdoc overview
|
||||
@name angular.attrMarkup
|
||||
|
||||
@description
|
||||
Attribute markup extends the angular compiler in a very similar way as {@link angular.markup} except
|
||||
that it allows you to modify the state of the attribute text rather then the contest of a node.
|
||||
|
||||
<pre>
|
||||
angular.attrMarkup('extraClass', function(attrValue, attrName, element){
|
||||
if (attrName == 'additional-class') {
|
||||
element.addClass(attrValue);
|
||||
}
|
||||
});
|
||||
</pre>
|
||||
@@ -1,53 +0,0 @@
|
||||
@workInProgress
|
||||
@ngdoc overview
|
||||
@name angular.directive
|
||||
@namespace Namespace for all directives.
|
||||
|
||||
@description
|
||||
A directive is an HTML attribute that you can use in an existing HTML element type or in a
|
||||
DOM element type that you create as {@link angular.widget}, to modify that element's
|
||||
properties. You can use any number of directives per element.
|
||||
|
||||
For example, you can add the ng:bind directive as an attribute of an HTML span element, as in
|
||||
`<span ng:bind="1+2"></span>`. How does this work? The compiler passes the attribute value
|
||||
`1+2` to the ng:bind extension, which in turn tells the {@link angular.scope} to watch that
|
||||
expression and report changes. On any change it sets the span text to the expression value.
|
||||
|
||||
Here's how to define {@link angular.directive.ng:bind ng:bind}:
|
||||
<pre>
|
||||
angular.directive('ng:bind', function(expression, compiledElement) {
|
||||
var compiler = this;
|
||||
return function(linkElement) {
|
||||
var currentScope = this;
|
||||
currentScope.$watch(expression, function(value) {
|
||||
linkElement.text(value);
|
||||
});
|
||||
};
|
||||
});
|
||||
</pre>
|
||||
|
||||
# Directive vs. Attribute Widget
|
||||
Both [attribute widgets](#!angular.widget) and directives can compile a DOM element
|
||||
attribute. So why have two different ways to do the same thing? The answer is that order
|
||||
matters, but we have no control over the order in which attributes are read. To solve this
|
||||
we apply attribute widget before the directive.
|
||||
|
||||
For example, consider this piece of HTML, which uses the directives `ng:repeat`, `ng:init`,
|
||||
and `ng:bind`:
|
||||
<pre>
|
||||
<ul ng:init="people=['mike', 'mary']">
|
||||
<li ng:repeat="person in people" ng:init="a=a+1" ng:bind="person"></li>
|
||||
</ul>
|
||||
</pre>
|
||||
|
||||
Notice that the order of execution matters here. We need to execute
|
||||
{@link angular.directive.ng:repeat ng:repeat} before we run the
|
||||
{@link angular.directive.ng:init ng:init} and `ng:bind` on the `<li/>;`. This is because we
|
||||
want to run the `ng:init="a=a+1` and `ng:bind="person"` once for each person in people. We
|
||||
could not have used directive to create this template because attributes are read in an
|
||||
unspecified order and there is no way of guaranteeing that the repeater attribute would
|
||||
execute first. Using the `ng:repeat` attribute directive ensures that we can transform the
|
||||
DOM element into a template.
|
||||
|
||||
Widgets run before directives. Widgets may manipulate the DOM whereas directives are not
|
||||
expected to do so, and so they run last.
|
||||
@@ -1,49 +0,0 @@
|
||||
@workInProgress
|
||||
@ngdoc function
|
||||
@name angular.element
|
||||
@function
|
||||
|
||||
@description
|
||||
Wraps a raw DOM element or HTML string as [jQuery](http://jquery.com) element.
|
||||
`angular.element` is either an alias for [jQuery](http://api.jquery.com/jQuery/) function if
|
||||
jQuery is loaded or a function that wraps the element or string in angular's jQuery lite
|
||||
implementation.
|
||||
|
||||
Real jQuery always takes precedence (as long as it was loaded before `DOMContentEvent`)
|
||||
|
||||
Angular's jQuery lite implementation is a tiny API-compatible subset of jQuery which allows
|
||||
angular to manipulate DOM. The jQuery lite implements only a subset of jQuery api, with the
|
||||
focus on the most commonly needed functionality and minimal footprint. For this reason only a
|
||||
limited number of jQuery methods, arguments and invocation styles are supported.
|
||||
|
||||
NOTE: All element references in angular are always wrapped with jQuery (lite) and are never
|
||||
raw DOM references.
|
||||
|
||||
## Angular's jQuery lite implements these functions:
|
||||
|
||||
- [addClass()](http://api.jquery.com/addClass/)
|
||||
- [after()](http://api.jquery.com/after/)
|
||||
- [append()](http://api.jquery.com/append/)
|
||||
- [attr()](http://api.jquery.com/attr/)
|
||||
- [bind()](http://api.jquery.com/bind/)
|
||||
- [children()](http://api.jquery.com/children/)
|
||||
- [clone()](http://api.jquery.com/clone/)
|
||||
- [css()](http://api.jquery.com/css/)
|
||||
- [data()](http://api.jquery.com/data/)
|
||||
- [hasClass()](http://api.jquery.com/hasClass/)
|
||||
- [parent()](http://api.jquery.com/parent/)
|
||||
- [remove()](http://api.jquery.com/remove/)
|
||||
- [removeAttr()](http://api.jquery.com/removeAttr/)
|
||||
- [removeClass()](http://api.jquery.com/removeClass/)
|
||||
- [removeData()](http://api.jquery.com/removeData/)
|
||||
- [replaceWith()](http://api.jquery.com/replaceWith/)
|
||||
- [text()](http://api.jquery.com/text/)
|
||||
- [trigger()](http://api.jquery.com/trigger/)
|
||||
|
||||
## Additionally these methods extend the jQuery and are available in both jQuery and jQuery lite
|
||||
version:
|
||||
|
||||
- `scope()` - retrieves the current angular scope of the element.
|
||||
|
||||
@param {string|DOMElement} element HTML string or DOMElement to be wrapped into jQuery.
|
||||
@returns {Object} jQuery object.
|
||||
@@ -1,87 +0,0 @@
|
||||
@workInProgress
|
||||
@ngdoc overview
|
||||
@name angular.filter
|
||||
@namespace Namespace for all filters.
|
||||
@description
|
||||
# Overview
|
||||
Filters are a standard way to format your data for display to the user. For example, you
|
||||
might have the number 1234.5678 and would like to display it as US currency: $1,234.57.
|
||||
Filters allow you to do just that. In addition to transforming the data, filters also modify
|
||||
the DOM. This allows the filters to for example apply css styles to the filtered output if
|
||||
certain conditions were met.
|
||||
|
||||
|
||||
# Standard Filters
|
||||
|
||||
The Angular framework provides a standard set of filters for common operations, including:
|
||||
{@link angular.filter.currency currency}, {@link angular.filter.json json},
|
||||
{@link angular.filter.number number}, and {@link angular.filter.html html}. You can also add
|
||||
your own filters.
|
||||
|
||||
|
||||
# Syntax
|
||||
|
||||
Filters can be part of any {@link angular.scope} evaluation but are typically used with
|
||||
{{bindings}}. Filters typically transform the data to a new data type, formating the data in
|
||||
the process. Filters can be chained and take optional arguments. Here are few examples:
|
||||
|
||||
* No filter: {{1234.5678}} => 1234.5678
|
||||
* Number filter: {{1234.5678|number}} => 1,234.57. Notice the “,” and rounding to two
|
||||
significant digits.
|
||||
* Filter with arguments: {{1234.5678|number:5}} => 1,234.56780. Filters can take optional
|
||||
arguments, separated by colons in a binding. To number, the argument “5” requests 5 digits
|
||||
to the right of the decimal point.
|
||||
|
||||
|
||||
# Writing your own Filters
|
||||
|
||||
Writing your own filter is very easy: just define a JavaScript function on `angular.filter`.
|
||||
The framework passes in the input value as the first argument to your function. Any filter
|
||||
arguments are passed in as additional function arguments.
|
||||
|
||||
You can use these variables in the function:
|
||||
|
||||
* `this` — The current scope.
|
||||
* `this.$element` — The DOM element containing the binding. This allows the filter to manipulate
|
||||
the DOM in addition to transforming the input.
|
||||
|
||||
|
||||
@example
|
||||
The following example filter reverses a text string. In addition, it conditionally makes the
|
||||
text upper-case (to demonstrate optional arguments) and assigns color (to demonstrate DOM
|
||||
modification).
|
||||
|
||||
<doc:example>
|
||||
<doc:source>
|
||||
<script type="text/javascript">
|
||||
angular.filter('reverse', function(input, uppercase, color) {
|
||||
var out = "";
|
||||
for (var i = 0; i < input.length; i++) {
|
||||
out = input.charAt(i) + out;
|
||||
}
|
||||
if (uppercase) {
|
||||
out = out.toUpperCase();
|
||||
}
|
||||
if (color) {
|
||||
this.$element.css('color', color);
|
||||
}
|
||||
return out;
|
||||
});
|
||||
</script>
|
||||
|
||||
<input name="text" type="text" value="hello" /><br>
|
||||
No filter: {{text}}<br>
|
||||
Reverse: {{text|reverse}}<br>
|
||||
Reverse + uppercase: {{text|reverse:true}}<br>
|
||||
Reverse + uppercase + blue: {{text|reverse:true:"blue"}}
|
||||
</doc:source>
|
||||
<doc:scenario>
|
||||
it('should reverse text', function(){
|
||||
expect(binding('text|reverse')).toEqual('olleh');
|
||||
input('text').enter('ABC');
|
||||
expect(binding('text|reverse')).toEqual('CBA');
|
||||
});
|
||||
</doc:scenario>
|
||||
</doc:example>
|
||||
|
||||
|
||||
@@ -1,82 +0,0 @@
|
||||
@workInProgress
|
||||
@ngdoc overview
|
||||
@name angular.formatter
|
||||
@namespace Namespace for all formats.
|
||||
@description
|
||||
# Overview
|
||||
The formatters are responsible for translating user readable text in an input widget to a
|
||||
data model stored in an application.
|
||||
|
||||
# Writting your own Formatter
|
||||
Writing your own formatter is easy. Just register a pair of JavaScript functions with
|
||||
`angular.formatter`. One function for parsing user input text to the stored form,
|
||||
and one for formatting the stored data to user-visible text.
|
||||
|
||||
Here is an example of a "reverse" formatter: The data is stored in uppercase and in
|
||||
reverse, while it is displayed in lower case and non-reversed. User edits are
|
||||
automatically parsed into the internal form and data changes are automatically
|
||||
formatted to the viewed form.
|
||||
|
||||
<pre>
|
||||
function reverse(text) {
|
||||
var reversed = [];
|
||||
for (var i = 0; i < text.length; i++) {
|
||||
reversed.unshift(text.charAt(i));
|
||||
}
|
||||
return reversed.join('');
|
||||
}
|
||||
|
||||
angular.formatter('reverse', {
|
||||
parse: function(value){
|
||||
return reverse(value||'').toUpperCase();
|
||||
},
|
||||
format: function(value){
|
||||
return reverse(value||'').toLowerCase();
|
||||
}
|
||||
});
|
||||
</pre>
|
||||
|
||||
@example
|
||||
<doc:example>
|
||||
<doc:source>
|
||||
<script type="text/javascript">
|
||||
function reverse(text) {
|
||||
var reversed = [];
|
||||
for (var i = 0; i < text.length; i++) {
|
||||
reversed.unshift(text.charAt(i));
|
||||
}
|
||||
return reversed.join('');
|
||||
}
|
||||
|
||||
angular.formatter('reverse', {
|
||||
parse: function(value){
|
||||
return reverse(value||'').toUpperCase();
|
||||
},
|
||||
format: function(value){
|
||||
return reverse(value||'').toLowerCase();
|
||||
}
|
||||
});
|
||||
</script>
|
||||
|
||||
Formatted:
|
||||
<input type="text" name="data" value="angular" ng:format="reverse"/>
|
||||
<br/>
|
||||
|
||||
Stored:
|
||||
<input type="text" name="data"/><br/>
|
||||
<pre>{{data}}</pre>
|
||||
</doc:source>
|
||||
<doc:scenario>
|
||||
it('should store reverse', function(){
|
||||
expect(element('.doc-example-live input:first').val()).toEqual('angular');
|
||||
expect(element('.doc-example-live input:last').val()).toEqual('RALUGNA');
|
||||
|
||||
this.addFutureAction('change to XYZ', function($window, $document, done){
|
||||
$document.elements('.doc-example-live input:last').val('XYZ').trigger('change');
|
||||
done();
|
||||
});
|
||||
expect(element('.doc-example-live input:first').val()).toEqual('zyx');
|
||||
});
|
||||
</doc:scenario>
|
||||
</doc:example>
|
||||
|
||||
@@ -1,66 +0,0 @@
|
||||
@workInProgress
|
||||
@ngdoc overview
|
||||
@name angular.markup
|
||||
|
||||
@description
|
||||
#Overview
|
||||
Markups allow the angular compiler to transform content of DOM elements or portions of this content
|
||||
into other text or DOM elements for further compilation. Markup extensions do not themselves produce
|
||||
linking functions. Think of markup as a way to produce shorthand for a {@link angular.widget widget}
|
||||
or a {@link angular.directive directive}.
|
||||
|
||||
#`{{}}` (double curly) built-in markup
|
||||
`{{}}` markup is a built-in markup, which translates the enclosed expression into an
|
||||
{@link angular.directive.ng:bind ng:bind} directive. It simply transforms
|
||||
|
||||
<pre>
|
||||
{{expression}}
|
||||
</pre>
|
||||
|
||||
to:
|
||||
|
||||
<pre>
|
||||
<span ng:bind="expression"></span>
|
||||
</pre>
|
||||
|
||||
For example `{{1+2}}` is easier to write and understand than `<span ng:bind="1+2"></span>`. The
|
||||
expanded elements are then {@link guide.compiler compiled} normally.
|
||||
|
||||
# Custom markup
|
||||
Let's say you want to define this shorthand for a horizontal rule: `---` for `<hr/>`.
|
||||
|
||||
In other words, this HTML:
|
||||
<pre>
|
||||
header
|
||||
---
|
||||
footer
|
||||
</pre>
|
||||
|
||||
should translate to:
|
||||
<pre>
|
||||
header
|
||||
<hr/>
|
||||
footer
|
||||
</pre>
|
||||
|
||||
Here's how the angular compiler could be extended to achieve this:
|
||||
<pre>
|
||||
angular.markup('---', function(text, textNode, parentElement) {
|
||||
var compiler = this;
|
||||
var index = text.indexOf('---');
|
||||
if (index > -1) {
|
||||
var before = compiler.text(text.substring(0, index));
|
||||
var hr = compiler.element('hr');
|
||||
var after = compiler.text(text.substring(index + 3));
|
||||
textNode.after(after);
|
||||
textNode.after(hr);
|
||||
textNode.after(before);
|
||||
textNode.remove();
|
||||
}
|
||||
});
|
||||
</pre>
|
||||
|
||||
Unlike {@link angular.widget widgets} and {@link angular.directive directives}, in which the
|
||||
compiler matches the name of handler function to a DOM element or attribute name, for markup the
|
||||
compiler calls every markup handler for every text node, giving the handler a chance to transform
|
||||
the text. The markup handler needs to find all the matches in the text.
|
||||
@@ -1,4 +0,0 @@
|
||||
@workInProgress
|
||||
@ngdoc overview
|
||||
@name angular
|
||||
@namespace The exported angular namespace.
|
||||
@@ -1,175 +0,0 @@
|
||||
@workInProgress
|
||||
@ngdoc overview
|
||||
@name angular.service
|
||||
|
||||
@description
|
||||
# Overview
|
||||
Services are substituable objects, which are wired together using dependency injection (DI).
|
||||
Each service could have dependencies (other services), which are passed in constructor.
|
||||
Because JS is dynamicaly typed language, dependency injection can not use static types
|
||||
to identify these dependencies, so each service must explicitely define its dependencies.
|
||||
This is done by `$inject` property.
|
||||
|
||||
|
||||
# Built-in services
|
||||
angular provides a set of services for common operations. These services can be overriden by custom
|
||||
services if needed.
|
||||
|
||||
Like other core angular variables and identifiers, the built-in services always start with `$`.
|
||||
|
||||
* {@link angular.service.$browser $browser}
|
||||
* {@link angular.service.$window $window}
|
||||
* {@link angular.service.$document $document}
|
||||
* {@link angular.service.$location $location}
|
||||
* {@link angular.service.$log $log}
|
||||
* {@link angular.service.$exceptionHandler $exceptionHandler}
|
||||
* {@link angular.service.$hover $hover}
|
||||
* {@link angular.service.$invalidWidgets $invalidWidgets}
|
||||
* {@link angular.service.$route $route}
|
||||
* {@link angular.service.$xhr $xhr}
|
||||
* {@link angular.service.$xhr.error $xhr.error}
|
||||
* {@link angular.service.$xhr.bulk $xhr.bulk}
|
||||
* {@link angular.service.$xhr.cache $xhr.cache}
|
||||
* {@link angular.service.$resource $resource}
|
||||
* {@link angular.service.$cookies $cookies}
|
||||
* {@link angular.service.$cookieStore $cookieStore}
|
||||
|
||||
# Writing your own custom services
|
||||
angular provides only set of basic services, so for any nontrivial application it will be necessary
|
||||
to write one or more custom services. To do so, a factory function that creates a services needs to
|
||||
be registered with angular's dependency injector. This factory function must return an object - the
|
||||
service (it is not called with the `new` operator).
|
||||
|
||||
**angular.service** accepts three parameters:
|
||||
|
||||
- `{string} name` - Name of the service.
|
||||
- `{function()} factory` - Factory function (called just once by DI).
|
||||
- `{Object} config` - Configuration object with following properties:
|
||||
- `$inject` - {Array.<string>} - Array of service ids that this service depends on. These
|
||||
services will be passed as arguments into the factory function in the same order as specified
|
||||
in the `$inject` array. Defaults to `[]`.
|
||||
- `$eager` - {boolean} - If true, the service factory will be called and thus, the service will
|
||||
be instantiated when angular boots. If false, service will be lazily instantiated when it is
|
||||
first requested during instantiation of a dependant. Defaults to `false`.
|
||||
|
||||
The `this` of the factory function is bound to the root scope of the angular application.
|
||||
|
||||
angular enables services to participate in dependency injection (DI) by registering themselves with
|
||||
angular's DI system (injector) under a `name` (id) as well as by declaring dependencies which need
|
||||
to be provided for the factory function of the registered service. The ability to swap dependencies
|
||||
for mocks/stubs/dummies in tests allows for services to be highly testable.
|
||||
|
||||
Here is an example of very simple service. This service requires $window service (it's
|
||||
passed as a parameter to factory function) and it's just a function.
|
||||
|
||||
This service simple stores all notifications and after third one, it displays all of them by
|
||||
window alert.
|
||||
<pre>
|
||||
angular.service('notify', function(win) {
|
||||
var msgs = [];
|
||||
return function(msg) {
|
||||
msgs.push(msg);
|
||||
if (msgs.length == 3) {
|
||||
win.alert(msgs.join("\n"));
|
||||
msgs = [];
|
||||
}
|
||||
};
|
||||
}, {$inject: ['$window']});
|
||||
</pre>
|
||||
|
||||
And here is a unit test for this service. We use Jasmine spy (mock) instead of real browser's alert.
|
||||
<pre>
|
||||
var mock, notify;
|
||||
|
||||
beforeEach(function() {
|
||||
mock = {alert: jasmine.createSpy()};
|
||||
notify = angular.service('notify')(mock);
|
||||
});
|
||||
|
||||
it('should not alert first two notifications', function() {
|
||||
notify('one');
|
||||
notify('two');
|
||||
expect(mock.alert).not.toHaveBeenCalled();
|
||||
});
|
||||
|
||||
it('should alert all after third notification', function() {
|
||||
notify('one');
|
||||
notify('two');
|
||||
notify('three');
|
||||
expect(mock.alert).toHaveBeenCalledWith("one\ntwo\nthree");
|
||||
});
|
||||
|
||||
it('should clear messages after alert', function() {
|
||||
notify('one');
|
||||
notify('two');
|
||||
notify('third');
|
||||
notify('more');
|
||||
notify('two');
|
||||
notify('third');
|
||||
expect(mock.alert.callCount).toEqual(2);
|
||||
expect(mock.alert.mostRecentCall.args).toEqual(["more\ntwo\nthird"]);
|
||||
});
|
||||
</pre>
|
||||
|
||||
# Injecting services into controllers
|
||||
Using services as dependencies for controllers is very similar to using them as dependencies for
|
||||
another service.
|
||||
|
||||
JavaScript is dynamic language, so DI is not able to figure out which services to inject by
|
||||
static types (like in static typed languages). Therefore you must specify the service name
|
||||
by the `$inject` property - it's an array that contains strings with names of services to be
|
||||
injected. The name must match the id that service has been registered as with angular.
|
||||
The order of the services in the array matters, because this order will be used when calling
|
||||
the factory function with injected parameters. The names of parameters in factory function
|
||||
don't matter, but by convention they match the service ids.
|
||||
<pre>
|
||||
function myController($loc, $log) {
|
||||
this.firstMethod = function() {
|
||||
// use $location service
|
||||
$loc.setHash();
|
||||
};
|
||||
this.secondMethod = function() {
|
||||
// use $log service
|
||||
$log.info('...');
|
||||
};
|
||||
}
|
||||
// which services to inject ?
|
||||
myController.$inject = ['$location', '$log'];
|
||||
</pre>
|
||||
|
||||
@example
|
||||
<doc:example>
|
||||
<doc:source>
|
||||
<script type="text/javascript">
|
||||
angular.service('notify', function(win) {
|
||||
var msgs = [];
|
||||
return function(msg) {
|
||||
msgs.push(msg);
|
||||
if (msgs.length == 3) {
|
||||
win.alert(msgs.join("\n"));
|
||||
msgs = [];
|
||||
}
|
||||
};
|
||||
}, {$inject: ['$window']});
|
||||
|
||||
function myController(notifyService) {
|
||||
this.callNotify = function(msg) {
|
||||
notifyService(msg);
|
||||
};
|
||||
}
|
||||
|
||||
myController.$inject = ['notify'];
|
||||
</script>
|
||||
|
||||
<div ng:controller="myController">
|
||||
<p>Let's try this simple notify service, injected into the controller...</p>
|
||||
<input ng:init="message='test'" type="text" name="message" />
|
||||
<button ng:click="callNotify(message);">NOTIFY</button>
|
||||
</div>
|
||||
</doc:source>
|
||||
<doc:scenario>
|
||||
it('should test service', function(){
|
||||
expect(element(':input[name=message]').val()).toEqual('test');
|
||||
});
|
||||
</doc:scenario>
|
||||
</doc:example>
|
||||
@@ -1,77 +0,0 @@
|
||||
@workInProgress
|
||||
@ngdoc overview
|
||||
@name angular.validator
|
||||
@namespace Namespace for all filters.
|
||||
@description
|
||||
# Overview
|
||||
Validators are a standard way to check the user input against a specific criteria. For
|
||||
example, you might need to check that an input field contains a well-formed phone number.
|
||||
|
||||
# Syntax
|
||||
Attach a validator on user input widgets using the `ng:validate` attribute.
|
||||
|
||||
<doc:example>
|
||||
<doc:source>
|
||||
Change me: <input type="text" name="number" ng:validate="integer" value="123">
|
||||
</doc:source>
|
||||
<doc:scenario>
|
||||
it('should validate the default number string', function() {
|
||||
expect(element('input[name=number]').attr('class')).
|
||||
not().toMatch(/ng-validation-error/);
|
||||
});
|
||||
it('should not validate "foo"', function() {
|
||||
input('number').enter('foo');
|
||||
expect(element('input[name=number]').attr('class')).
|
||||
toMatch(/ng-validation-error/);
|
||||
});
|
||||
</doc:scenario>
|
||||
</doc:example>
|
||||
|
||||
|
||||
# Writing your own Validators
|
||||
Writing your own validator is easy. To make a function available as a
|
||||
validator, just define the JavaScript function on the `angular.validator`
|
||||
object. <angular/> passes in the input to validate as the first argument
|
||||
to your function. Any additional validator arguments are passed in as
|
||||
additional arguments to your function.
|
||||
|
||||
You can use these variables in the function:
|
||||
|
||||
* `this` — The current scope.
|
||||
* `this.$element` — The DOM element containing the binding. This allows the filter to manipulate
|
||||
the DOM in addition to transforming the input.
|
||||
|
||||
In this example we have written a upsTrackingNo validator.
|
||||
It marks the input text "valid" only when the user enters a well-formed
|
||||
UPS tracking number.
|
||||
|
||||
@css ng-validation-error
|
||||
When validation fails, this css class is applied to the binding, making its borders red by
|
||||
default.
|
||||
|
||||
@example
|
||||
<doc:example>
|
||||
<doc:source>
|
||||
<script>
|
||||
angular.validator('upsTrackingNo', function(input, format) {
|
||||
var regexp = new RegExp("^" + format.replace(/9/g, '\\d') + "$");
|
||||
return input.match(regexp)?"":"The format must match " + format;
|
||||
});
|
||||
</script>
|
||||
<input type="text" name="trackNo" size="40"
|
||||
ng:validate="upsTrackingNo:'1Z 999 999 99 9999 999 9'"
|
||||
value="1Z 123 456 78 9012 345 6"/>
|
||||
</doc:source>
|
||||
<doc:scenario>
|
||||
it('should validate correct UPS tracking number', function() {
|
||||
expect(element('input[name=trackNo]').attr('class')).
|
||||
not().toMatch(/ng-validation-error/);
|
||||
});
|
||||
|
||||
it('should not validate in correct UPS tracking number', function() {
|
||||
input('trackNo').enter('foo');
|
||||
expect(element('input[name=trackNo]').attr('class')).
|
||||
toMatch(/ng-validation-error/);
|
||||
});
|
||||
</doc:scenario>
|
||||
</doc:example>
|
||||
@@ -1,78 +0,0 @@
|
||||
@workInProgress
|
||||
@ngdoc overview
|
||||
@name angular.widget
|
||||
@namespace Namespace for all widgets.
|
||||
@description
|
||||
# Overview
|
||||
Widgets allow you to create DOM elements that the browser doesn't
|
||||
already understand. You create the widget in your namespace and
|
||||
assign it behavior. You can only bind one widget per DOM element
|
||||
(unlike directives, in which you can use any number per DOM
|
||||
element). Widgets are expected to manipulate the DOM tree by
|
||||
adding new elements whereas directives are expected to only modify
|
||||
element properties.
|
||||
|
||||
Widgets come in two flavors: element and attribute.
|
||||
|
||||
# Element Widget
|
||||
Let's say we would like to create a new element type in the
|
||||
namespace `my` that can watch an expression and alert() the user
|
||||
with each new value.
|
||||
|
||||
<pre>
|
||||
<my:watch exp="name"/>
|
||||
</pre>
|
||||
|
||||
You can implement `my:watch` like this:
|
||||
<pre>
|
||||
angular.widget('my:watch', function(compileElement) {
|
||||
var compiler = this;
|
||||
var exp = compileElement.attr('exp');
|
||||
return function(linkElement) {
|
||||
var currentScope = this;
|
||||
currentScope.$watch(exp, function(value){
|
||||
alert(value);
|
||||
}};
|
||||
};
|
||||
});
|
||||
</pre>
|
||||
|
||||
# Attribute Widget
|
||||
Let's implement the same widget, but this time as an attribute
|
||||
that can be added to any existing DOM element.
|
||||
<pre>
|
||||
<div my-watch="name">text</div>
|
||||
</pre>
|
||||
You can implement `my:watch` attribute like this:
|
||||
<pre>
|
||||
angular.widget('@my:watch', function(expression, compileElement) {
|
||||
var compiler = this;
|
||||
return function(linkElement) {
|
||||
var currentScope = this;
|
||||
currentScope.$watch(expression, function(value){
|
||||
alert(value);
|
||||
});
|
||||
};
|
||||
});
|
||||
</pre>
|
||||
|
||||
@example
|
||||
<doc:example>
|
||||
<doc:source>
|
||||
<script>
|
||||
angular.widget('my:time', function(compileElement){
|
||||
compileElement.css('display', 'block');
|
||||
return function(linkElement){
|
||||
function update(){
|
||||
linkElement.text('Current time is: ' + new Date());
|
||||
setTimeout(update, 1000);
|
||||
}
|
||||
update();
|
||||
};
|
||||
});
|
||||
</script>
|
||||
<my:time></my:time>
|
||||
</doc:source>
|
||||
<doc:scenario>
|
||||
</doc:scenario>
|
||||
</doc:example>
|
||||
@@ -0,0 +1,719 @@
|
||||
@ngdoc overview
|
||||
@name angular.module.ng.$compileProvider.directive
|
||||
@description
|
||||
|
||||
Directives are a way to teach HTML new tricks. During DOM compilation directives are matched
|
||||
against the HTML and executed. This allows directives to register behavior, or transform the DOM.
|
||||
|
||||
Angular comes with a built in set of directives which are useful for building web applications but
|
||||
can be extended such that HTML can be turned into a declarative domain specific language (DSL).
|
||||
|
||||
# Invoking directives from HTML
|
||||
|
||||
Directives have camel cased names such as 'ngBind'. The directive can be invoked by translating
|
||||
the camel case name into snake case with these special characters `:`, `-`, or `_`. Optionally the
|
||||
directive can be prefixed with `x-`, or `data-` to make it HTML validator compliant. Here is a
|
||||
list of some of the possible directive names: `ng:bind`, `ng-bind`, `ng_bind`, `x-ng-bind` and
|
||||
`data-ng-bind`.
|
||||
|
||||
The directives can be placed in element names, attributes, class names, as well as comments. Here
|
||||
are some equivalent examples of invoking `myDir`. (However, most directives are restricted to
|
||||
attribute only.)
|
||||
|
||||
<pre>
|
||||
<span my-dir="exp"></span>
|
||||
<span class="my-dir: exp;"></span>
|
||||
<my-dir></my-dir>
|
||||
<!-- directive: my-dir exp -->
|
||||
</pre>
|
||||
|
||||
Directives can be invoked in many different ways, but are equivalent in the end result as shown in
|
||||
the following example.
|
||||
|
||||
<doc:example>
|
||||
<doc:source >
|
||||
<script>
|
||||
function Ctrl1($scope) {
|
||||
$scope.name = 'angular';
|
||||
}
|
||||
</script>
|
||||
<div ng-controller="Ctrl1">
|
||||
Hello <input ng-model='name' ng-model-instant> <hr/>
|
||||
<span ng:bind="name"> <span ng:bind="name"></span> <br/>
|
||||
<span ng_bind="name"> <span ng_bind="name"></span> <br/>
|
||||
<span ng-bind="name"> <span ng-bind="name"></span> <br/>
|
||||
<span data-ng-bind="name"> <span data-ng-bind="name"></span> <br/>
|
||||
<span x-ng-bind="name"> <span x-ng-bind="name"></span> <br/>
|
||||
</div>
|
||||
</doc:source>
|
||||
<doc:scenario>
|
||||
it('should load template1.html', function() {
|
||||
expect(element('div[ng-controller="Ctrl1"] span[ng-bind]').text()).toBe('angular');
|
||||
});
|
||||
</doc:scenario>
|
||||
</doc:example>
|
||||
|
||||
# String interpolation
|
||||
|
||||
During the compilation process the {@link angular.module.ng.$compile compiler} matches text and
|
||||
attributes using the {@link angular.module.ng.$interpolate $interpolate} service to see if they
|
||||
contain embedded expressions. These expressions are registered as {@link
|
||||
angular.module.ng.$rootScope.Scope#$watch watches} and will update as part of normal {@link
|
||||
angular.module.ng.$rootScope.Scope#$digest digest} cycle. An example of interpolation is shown
|
||||
here:
|
||||
|
||||
<pre>
|
||||
<img src="img/{{username}}.jpg">Hello {{username}}!</img>
|
||||
</pre>
|
||||
|
||||
# Compilation process, and directive matching
|
||||
|
||||
Compilation of HTML happens in three phases:
|
||||
|
||||
1. First the HTML is parsed into DOM using the standard browser API. This is important to
|
||||
realize because the templates must be parsable HTML. This is in contrast to most templating
|
||||
systems that operate on strings, rather then on DOM elements.
|
||||
|
||||
2. The compilation of the DOM is performed by the call to {@link angular.module.ng.$compile
|
||||
$compile()} method. The method traverses the DOM and matches the directives. If a match is found
|
||||
it is added to the list of directives associated with the given DOM element. Once all directives
|
||||
for a given DOM element have been identified they are sorted by priority and their `compile()`
|
||||
functions are executed. The directive compile function has a chance to modify the DOM structure
|
||||
and is responsible for producing a `link()` function explained next. The {@link
|
||||
angular.module.ng.$compile $compile()} method returns a combined linking function, which is a
|
||||
collection of all of the linking functions returned from the individual directive compile
|
||||
functions.
|
||||
|
||||
3. Link the template with scope by calling the liking function returned from the previous step.
|
||||
This in turn will call the linking function of the individual directives allowing them to
|
||||
register any listeners on the elements and set up any {@link
|
||||
angular.module.ng.$rootScope.Scope#$watch watches} with the {@link
|
||||
angular.module.ng.$rootScope.Scope scope}. The result of this is a live binding between the
|
||||
scope and the DOM. A change in the scope is reflected in the DOM.
|
||||
|
||||
<pre>
|
||||
var $compile = ...; // injected into your code
|
||||
var scope = ...;
|
||||
|
||||
var html = '<div ng-bind='exp'></div>';
|
||||
|
||||
// Step 1: parse HTML into DOM element
|
||||
var template = angular.element(html);
|
||||
|
||||
// Step 2: compile the template
|
||||
var linkFn = $compile(template);
|
||||
|
||||
// Step 3: link the compiled template with the scope.
|
||||
linkFn(scope);
|
||||
</pre>
|
||||
|
||||
## Reasons behind the compile/link separation
|
||||
|
||||
At this point you may wonder why is the compile process broken down to a compile and link phase.
|
||||
To understand this, lets look at a real world example with repeater:
|
||||
|
||||
<pre>
|
||||
Hello {{user}}, you have these actions:
|
||||
<ul>
|
||||
<li ng-repeat="action in user.actions">
|
||||
{{action.description}}
|
||||
</li>
|
||||
</ul>
|
||||
</pre>
|
||||
|
||||
The short answer is that compile and link separation is needed any time a change in model causes
|
||||
a change in DOM structure such as in repeaters.
|
||||
|
||||
When the above example is compiled, the compiler visits every node and looks for directives. The
|
||||
`{{user}}` is an example of {@link angular.module.ng.$interpolate interpolation} directive. {@link
|
||||
angular.module.ng.$compileProvider.directive.ng-repeat ng-repeat} is another directive. But {@link
|
||||
angular.module.ng.$compileProvider.directive.ng-repeat ng-repeat} has a dilemma. It needs to be
|
||||
able to quickly stamp out new `li`s for every `action` in `user.actions`. This means that it needs
|
||||
to save a clean copy of the `li` element for cloning purposes and as new `action`s are inserted,
|
||||
the template `li` element needs to be cloned and inserted into `ul`. But cloning the `li` element
|
||||
is not enough. It also needs to compile the `li` so that its directives such as
|
||||
`{{action.descriptions}}` evaluate against the right {@link angular.module.ng.$rootScope.Scope
|
||||
scope}. A naive method would be to simply insert a copy of the `li` elemnt and then compile it.
|
||||
But compiling on every `li` element clone would be slow, since the compilation requires that we
|
||||
traverse the DOM tree and look for directives and execute them. If we put the compilation inside a
|
||||
repeater which needs to unroll 100 items we would quickly run into performance problem.
|
||||
|
||||
The solution is to break the compilation process into two phases the compile phase where all of
|
||||
the directives are identified and sorted by priority, and a linking phase where any work which
|
||||
links a specific instance of the {@link angular.module.ng.$rootScope.Scope scope} and the specific
|
||||
instance of an `li` is performed.
|
||||
|
||||
{@link angular.module.ng.$compileProvider.directive.ng-repeat ng-repeat} works by preventing the
|
||||
compilation process form descending into `li` element. Instead the {@link
|
||||
angular.module.ng.$compileProvider.directive.ng-repeat ng-repeat} directive compiles `li`
|
||||
seperatly. The result of of the `li` element compilation is a linking function which contains all
|
||||
of the directives contained in the `li` element ready to be attached to a specific clone of `li`
|
||||
element. At runtime the {@link angular.module.ng.$compileProvider.directive.ng-repeat ng-repeat}
|
||||
watches the expression and as items are added to the array it clones the `li` element, creates a
|
||||
new {@link angular.module.ng.$rootScope.Scope scope} for the cloned `li` element and calls the
|
||||
link function on the cloned `li`.
|
||||
|
||||
Summary:
|
||||
|
||||
* *compile function* - The compile function is relatively rare in directives, since most
|
||||
directives are concerned with working with a specific DOM element instance rather then
|
||||
transforming the template DOM element. Any operation which can be shared among the instance of
|
||||
directives should be moved to the compile function for performance reasons.
|
||||
|
||||
* *link function* - It is rare for the directive not to have a link function. Link function
|
||||
allows the directive to register listeners to the specific cloned DOM element instance as well
|
||||
as to copy content into the DOM from the scope.
|
||||
|
||||
|
||||
# Writing directives (short version)
|
||||
|
||||
In this example we will build a directive which displays the current time.
|
||||
|
||||
<doc:example module="time">
|
||||
<doc:source>
|
||||
<script>
|
||||
function Ctrl2($scope) {
|
||||
$scope.format = 'M/d/yy h:mm:ss a';
|
||||
}
|
||||
|
||||
angular.module('time', [])
|
||||
// Register the 'myCurrentTime' directive factory method.
|
||||
// We inject $defer and dateFilter service since the factory method is DI.
|
||||
.directive('myCurrentTime', function($defer, dateFilter) {
|
||||
// return the directive link function. (compile function not needed)
|
||||
return function(scope, element, attrs) {
|
||||
var format, // date format
|
||||
deferId; // deferId, so that we can cancel the time updates
|
||||
|
||||
// used to update the UI
|
||||
function updateTime() {
|
||||
element.text(dateFilter(new Date(), format));
|
||||
}
|
||||
|
||||
// watch the expression, and update the UI on change.
|
||||
scope.$watch(attrs.myCurrentTime, function(value) {
|
||||
format = value;
|
||||
updateTime();
|
||||
});
|
||||
|
||||
// schedule update in one second
|
||||
function updateLater() {
|
||||
// save the deferId for canceling
|
||||
deferId = $defer(function() {
|
||||
updateTime(); // update DOM
|
||||
updateLater(); // schedule another update
|
||||
}, 1000);
|
||||
}
|
||||
|
||||
// listen on DOM destroy (removal) event, and cancel the next UI update
|
||||
// to prevent updating time ofter the DOM element was removed.
|
||||
element.bind('$destroy', function() {
|
||||
$defer.cancel(deferId);
|
||||
});
|
||||
|
||||
updateLater(); // kick of the UI update process.
|
||||
}
|
||||
});
|
||||
</script>
|
||||
<div ng-controller="Ctrl2">
|
||||
Date format: <input ng-model='format'> <hr/>
|
||||
Current time is: <span my-current-time="format"></span
|
||||
</div>
|
||||
</doc:source>
|
||||
<doc:scenario>
|
||||
</doc:scenario>
|
||||
</doc:example>
|
||||
|
||||
|
||||
# Writing directives (long version)
|
||||
|
||||
The full skeleton of the directive is shown here:
|
||||
|
||||
<pre>
|
||||
var myModule = angular.module(...);
|
||||
|
||||
myModule.directive('directiveName', function factory(injectables) {
|
||||
var directiveDefinitionObject = {
|
||||
priority: 0,
|
||||
template: '<div></div>',
|
||||
templateUrl: 'directive.html',
|
||||
replace: false,
|
||||
transclude: false,
|
||||
restrict: 'A',
|
||||
scope: false,
|
||||
compile: function compile(tElement, tAttrs, transclude) {
|
||||
return {
|
||||
pre: function preLink(scope, iElement, iAttrs, controller) { ... },
|
||||
post: function postLink(scope, iElement, iAttrs, controller) { ... }
|
||||
}
|
||||
},
|
||||
link: function postLink(scope, iElement, iAttrs) { ... }
|
||||
};
|
||||
return directiveDefinitionObject;
|
||||
});
|
||||
</pre>
|
||||
|
||||
In most cases you will not need such fine control and so the above can be simplified. All of the
|
||||
different parts of this skeleton are explained in following sections. In this section we are
|
||||
interested only isomers of this skeleton.
|
||||
|
||||
The first step in simplyfing the code is to rely on the deafult values. Therefore the above can be
|
||||
simplified as:
|
||||
|
||||
<pre>
|
||||
var myModule = angular.module(...);
|
||||
|
||||
myModule.directive('directiveName', function factory(injectables) {
|
||||
var directiveDefinitionObject = {
|
||||
compile: function compile(tElement, tAttrs) {
|
||||
return function postLink(scope, iElement, iAttrs) { ... }
|
||||
}
|
||||
};
|
||||
return directiveDefinitionObject;
|
||||
});
|
||||
</pre>
|
||||
|
||||
Most directives concern themselves only with instances not with template transformations allowing
|
||||
further simplification:
|
||||
|
||||
<pre>
|
||||
var myModule = angular.module(...);
|
||||
|
||||
myModule.directive('directiveName', function factory(injectables) {
|
||||
return function postLink(scope, iElement, iAttrs) { ... }
|
||||
});
|
||||
</pre>
|
||||
|
||||
|
||||
## Factory method
|
||||
|
||||
The factory method is responsible for creating the directive. It is invoked only once, when the
|
||||
{@link angular.module.ng.$compile compiler} matches the directive for the first time. You can
|
||||
perform any initialization work here. The method is invoked using the {@link
|
||||
http://localhost:8000/build/docs/api/angular.module.AUTO.$injector#invoke $injector.invoke} which
|
||||
makes it injectable following all of the rules of injection annotation.
|
||||
|
||||
## Directive Definition Object
|
||||
|
||||
The directive definition object provides instructions to the {@link angular.module.ng.$compile
|
||||
compiler}. The attributes are:
|
||||
|
||||
* `name` - Name of the current scope. Optional defaults to the name at registration.
|
||||
|
||||
* `priority` - When there are multiple directives defined on a single DOM element, sometimes it
|
||||
is necessary to specify the order in which the directives are applied. The `priority` is used
|
||||
to sort the directives before their `compile` functions get called. Higher `priority` goes
|
||||
first. The order of directives within the same priority is undefined.
|
||||
|
||||
* `terminal` - If set to true then the current `priority` will be the last set of directives
|
||||
which will execute (any directives at the current priority will still execute
|
||||
as the order of execution on same `priority` is undefined).
|
||||
|
||||
* `scope` - If set to:
|
||||
|
||||
* `true` - then a new scope will be created for this directive. If multiple directives on the
|
||||
same element request new scope, only one new scope is created. The new scope rule does not
|
||||
apply for the root of the template since the root of the template always gets a new scope.
|
||||
|
||||
* `{}` (object hash) - then a new 'isolate' scope is created. The 'isolate' scope differs from
|
||||
normal scope that it does not prototypically inherit from the parent scope. This is useful
|
||||
when creating reusable components, which should not accidentally read or modify data in
|
||||
parent scope. <br/>
|
||||
The 'isolate' scope takes an object hash which defines a set of local scope properties
|
||||
derived from the parent scope. These local properties are useful for aliasing values for
|
||||
templates. Locals definition is a hash of normalized element attribute name to their
|
||||
corresponding binding strategy. Valid binding strategies are:
|
||||
|
||||
* `attribute` - one time read of element attribute value and save it to widget scope. <br/>
|
||||
Given `<widget my-attr='abc'>` and widget definition of `scope: {myAttr:'attribute'}`,
|
||||
then widget scope property `myAttr` will be `"abc"`.
|
||||
|
||||
* `evaluate` - one time evaluation of expression stored in the attribute. <br/> Given
|
||||
`<widget my-attr='name'>` and widget definition of `scope: {myAttr:'evaluate'}`, and
|
||||
parent scope `{name:'angular'}` then widget scope property `myAttr` will be `"angular"`.
|
||||
|
||||
* `bind` - Set up one way binding from the element attribute to the widget scope. <br/>
|
||||
Given `<widget my-attr='{{name}}'>` and widget definition of `scope: {myAttr:'bind'}`,
|
||||
and parent scope `{name:'angular'}` then widget scope property `myAttr` will be
|
||||
`"angular"`, but any changes in the parent scope will be reflected in the widget scope.
|
||||
|
||||
* `accessor` - Set up getter/setter function for the expression in the widget element
|
||||
attribute to the widget scope. <br/> Given `<widget my-attr='name'>` and widget definition
|
||||
of `scope: {myAttr:'prop'}`, and parent scope `{name:'angular'}` then widget scope
|
||||
property `myAttr` will be a function such that `myAttr()` will return `"angular"` and
|
||||
`myAttr('new value')` will update the parent scope `name` property. This is useful for
|
||||
treating the element as a data-model for reading/writing.
|
||||
|
||||
* `expression` - Treat element attribute as an expression to be executed on the parent scope.
|
||||
<br/>
|
||||
Given `<widget my-attr='doSomething()'>` and widget definition of `scope:
|
||||
{myAttr:'expression'}`, and parent scope `{doSomething:function() {}}` then calling the
|
||||
widget scope function `myAttr` will execute the expression against the parent scope.
|
||||
|
||||
* `controller` - Controller constructor function. The controller is instantiated before the
|
||||
pre-linking phase and it is shared with other directives if they request it by name (see
|
||||
`require` attribute). This allows the directives to communicate with each other and augment
|
||||
each other behavior. The controller is injectable with the following locals:
|
||||
|
||||
* `$scope` - Current scope associated with the element
|
||||
* `$element` - Current element
|
||||
* `$attrs` - Current attributes obeject for the element
|
||||
* `$transclude` - A transclude linking function pre-bound to the correct transclusion scope:
|
||||
`function(cloneLinkingFn)`.
|
||||
|
||||
* `require` - Require another controller be passed into current directive linking function. The
|
||||
`require` takes a name of the directive controller to pass in. If no such controller can be
|
||||
found an error is raised. The name can be prefixed with:
|
||||
|
||||
* `?` - Don't raise an error. This makes the require dependency optional.
|
||||
* `^` - Look for the controller on parent elements as well.
|
||||
|
||||
|
||||
* `inject` (object hash) - Specifies a way to inject bindings into a controller. Injection
|
||||
definition is a hash of normalized element attribute names to their corresponding binding
|
||||
strategy. Valid binding strategies are:
|
||||
|
||||
* `attribute` - inject attribute value. <br/>
|
||||
Given `<widget my-attr='abc'>` and widget definition of `inject: {myAttr:'attribute'}`, then
|
||||
`myAttr` will inject `"abc"`.
|
||||
|
||||
* `evaluate` - inject one time evaluation of expression stored in the attribute. <br/>
|
||||
Given `<widget my-attr='name'>` and widget definition of `inject: {myAttr:'evaluate'}`, and
|
||||
parent scope `{name:'angular'}` then `myAttr` will inject `"angular"`.
|
||||
|
||||
* `accessor` - inject a getter/setter function for the expression in the widget element
|
||||
attribute to the widget scope. <br/>
|
||||
Given `<widget my-attr='name'>` and widget definition of `inject: {myAttr:'prop'}`, and
|
||||
parent scope `{name:'angular'}` then injecting `myAttr` will inject a function such
|
||||
that `myAttr()` will return `"angular"` and `myAttr('new value')` will update the parent
|
||||
scope `name` property. This is usefull for treating the element as a data-model for
|
||||
reading/writing.
|
||||
|
||||
* `expression` - Inject expression function. <br/>
|
||||
Given `<widget my-attr='doSomething()'>` and widget definition of
|
||||
`inject: {myAttr:'expression'}`, and parent scope `{doSomething:function() {}}` then
|
||||
injecting `myAttr` will inject a function which when called will execute the expression
|
||||
against the parent scope.
|
||||
|
||||
* `restrict` - String of subset of `EACM` which restricts the directive to a specific directive
|
||||
declaration style. If omitted directives are allowed on attributes only.
|
||||
|
||||
* `E` - Element name: `<my-directive></my-directive>`
|
||||
* `A` - Attribute: `<div my-directive="exp"></div>`
|
||||
* `C` - Class: `<div class="my-directive: exp;"></div>`
|
||||
* `M` - Comment: `<!-- directive: my-directive exp -->`
|
||||
|
||||
* `template` - replace the current element with the contents of the HTML. The replacement process
|
||||
migrates all of the attributes / classes from the old element to the new one. See Creating
|
||||
Widgets section below for more information.
|
||||
|
||||
* `templateURL` - Same as `template` but the template is loaded from the specified URL. Because
|
||||
the template loading is asynchronous the compilation/linking is suspended until the template
|
||||
is loaded.
|
||||
|
||||
* `replace` - if set to `true` then the template will replace the current element, rather then
|
||||
append the template to the element.
|
||||
|
||||
* `transclude` - compile the content of the element and make it available to the directive.
|
||||
Typically used with {@link api/angular.module.ng.$compileProvider.directive.ng-transclude
|
||||
ng-transclude}. The advantage of transclusion is that the linking function receives a
|
||||
transclusion function which is pre-bound to the correct scope. In a typical setup the widget
|
||||
creates an `isolate` scope, but the transclusion is not a child, but a sibling of the `isolate`
|
||||
scope. This makes it possible for the widget to have private state, and the transclusion to
|
||||
be bound to the parent (pre-`isolate`) scope.
|
||||
|
||||
* `true` - transclude the content of the directive.
|
||||
* `'element'` - transclude the whole element including any directives defined at lower priority.
|
||||
|
||||
|
||||
* `compile`: This is the compile function described in the section below.
|
||||
|
||||
* `link`: This is the link function described in the section below. This property is used only
|
||||
if the `compile` property is not defined.
|
||||
|
||||
## Compile function
|
||||
|
||||
<pre>
|
||||
function compile(tElement, tAttrs, transclude) { ... }
|
||||
</pre>
|
||||
|
||||
Compile function deals with transforming the template DOM. Since most directives do not do
|
||||
template transformation, it is not used often. Examples which require compile functions are
|
||||
directives which transform template DOM such as {@link
|
||||
angular.module.ng.$compileProvider.directive.ng-repeat ng-repeat} or load the contents
|
||||
asynchronously such as {@link angular.module.ng.$compileProvider.directive.ng-view ng-view}. The
|
||||
compile functions takes the following arguments.
|
||||
|
||||
* `tElement` - template element - The element where the directive has been declared. It is
|
||||
safe to do template transformation on the element and child elements only.
|
||||
|
||||
* `tAttrs` - template attributes - Normalized list of attributes declared on this element shared
|
||||
between all directive compile functions. See {@link
|
||||
#Attributes Attributes}
|
||||
|
||||
* `transclude` - A transclude linking function: `function(scope, cloneLinkingFn)`.
|
||||
|
||||
NOTE: The template instance and the link instance may not be the same objects if the template has
|
||||
been cloned. For this reason it is not safe in the compile function to do anything other the DOM
|
||||
transformation that applies to all DOM clones. Specifically, DOM listener registration should be
|
||||
done in a linking function rather than in a compile function.
|
||||
|
||||
A compile function can have a return value which can be either a function or an object.
|
||||
|
||||
* returning a function - is equivalent to registering the linking function via the `link` property
|
||||
of the config object when the compile function is empty.
|
||||
|
||||
* returning an object with function(s) registered via `pre` and `post` properties - allows you to
|
||||
control when a linking function should be called during the linking phase. See info about
|
||||
pre-linking and post-linking functions below.
|
||||
|
||||
|
||||
## Linking function
|
||||
|
||||
<pre>
|
||||
function link(scope, iElement, iAttrs, controller) { ... }
|
||||
</pre>
|
||||
|
||||
Link function is responsible for registering DOM listeners as well as updating the DOM. It is
|
||||
executed after the template has been cloned. This is where most of the directive logic will be
|
||||
put.
|
||||
|
||||
* `scope` - {@link angular.module.ng.$rootScope.Scope Scope} - The scope to be used by the
|
||||
directive for registering {@link angular.module.ng.$rootScope.Scope#$watch watches}.
|
||||
|
||||
* `iElement` - instance element - The element where the directive is to be used. It is safe to
|
||||
manipulate the children of the element only in `postLink` function since the children have
|
||||
already been linked.
|
||||
|
||||
* `iAttrs` - instance attributes - Normalized list of attributes declared on this element shared
|
||||
between all directive linking functions. See {@link #Attributes Attributes}
|
||||
|
||||
* `controller` - a controller instance - A controller instance if at least one directive on the
|
||||
element defines a controller. The controller is shared among all the directives, which allows
|
||||
the directives to use the controllers as a communication channel.
|
||||
|
||||
|
||||
|
||||
### Pre-linking function
|
||||
|
||||
Executed before the child elements are linked. Not safe to do DOM transformation since the
|
||||
compiler linking function will fail to locate the correct elements for linking.
|
||||
|
||||
### Post-linking function
|
||||
|
||||
Executed after the child elements are linked. Safe to do DOM transformation in here.
|
||||
|
||||
<a name="Attributes"></a>
|
||||
## Attributes
|
||||
|
||||
The attributes object - passed as a parameter in the link() or compile() functions - is a way of
|
||||
accessing:
|
||||
|
||||
* *normalized attribute names:* Since a directive such as 'ngBind' can be expressed in many ways
|
||||
sucha s as 'ng:bind', or 'x-ng-bind', the attributes object allows for a normalize accessed to
|
||||
the attributes.
|
||||
|
||||
* *directive inter-communication:* All directives share the same instance of the attributes
|
||||
object which allows the directives to use the attributes object as inter directive
|
||||
communication.
|
||||
|
||||
* *supports interpolation:* Interpolation attributes are assigned to the attribute object
|
||||
allowing other directives to read the interpolated value.
|
||||
|
||||
* *observing interpolated attributes:* Use `$observe` to observe the value changes of attributes
|
||||
that contain interpolation (e.g. `src="{{bar}}"`). Not only is this very efficient but it's also
|
||||
the only way to easily get the actual value because during the linking phase the interpolation
|
||||
hasn't been evaluated yet and so the value is at this time set to `undefined`.
|
||||
|
||||
<pre>
|
||||
function linkingFn(scope, elm, attrs, ctrl) {
|
||||
// get the attribute value
|
||||
console.log(attrs.ngModel);
|
||||
|
||||
// change the attribute
|
||||
attrs.$set('ngModel', 'new value');
|
||||
|
||||
// observe changes to interpolated attribute
|
||||
attrs.$observe('ngModel', function(value) {
|
||||
console.log('ngModel has changed value to ' + value);
|
||||
});
|
||||
}
|
||||
</pre>
|
||||
|
||||
|
||||
# Understanding Transclusion and Scopes
|
||||
|
||||
It is often desirable to have reusable components. Below is a pseudo code showing how a simplified
|
||||
dialog component may work.
|
||||
|
||||
<pre>
|
||||
<div>
|
||||
<button ng-click="show=true">show</button>
|
||||
<dialog title="Hello {{username}}."
|
||||
visible="show"
|
||||
on-cancel="show = false"
|
||||
on-ok="show = false; doSomething()">
|
||||
Body goes here: {{username}} is {{title}}.
|
||||
</dialog>
|
||||
</pre>
|
||||
|
||||
Clicking on the "show" button will open the dialog. The dialog will have a title, which is
|
||||
data bound to `username`, and it will also have a body which we would like to transclude
|
||||
into the dialog.
|
||||
|
||||
Here is an example of what the template definition for the `dialog` widget may look like.
|
||||
|
||||
<pre>
|
||||
<div ng-show="show()">
|
||||
<h3>{{title}}</h3>
|
||||
<div class="body" ng-transclude></div>
|
||||
<div class="footer">
|
||||
<button ng-click="onOk()">Save changes</button>
|
||||
<button ng-click="onCancel()">Close</button>
|
||||
</div>
|
||||
</div>
|
||||
</pre>
|
||||
|
||||
This will not render properly, unless we do some scope magic.
|
||||
|
||||
The first issue we have to solve is that the dialog box template expect `title` to be defined, but
|
||||
the place of instantiation would like to bind to `username`. Furthermore the buttons expect `onOk`
|
||||
as well as `onCancel` functions to be present in the scope. This limits the usefulness of the
|
||||
widget. To solve the mapping issue we use the `locals` to create local variables which the template
|
||||
expects as follows:
|
||||
|
||||
<pre>
|
||||
scope: {
|
||||
title: 'bind', // set up title to accept data-binding
|
||||
onOk: 'exp', // create a delegate onOk function
|
||||
onCancel: 'exp', // create a delegate onCancel function
|
||||
show: 'prop' // create a getter/setter function for visibility.
|
||||
}
|
||||
</pre>
|
||||
|
||||
Creating local properties on widget scope creates two problems:
|
||||
|
||||
1. isolation - if the user forgets to set `title` attribute of the dialog widget the dialog
|
||||
template will bind to parent scope property. This is unpredictable and undesirable.
|
||||
|
||||
2. transclusion - the transcluded DOM can see the widget locals, which may overwrite the
|
||||
properties which the transclusion needs for data-binding. In our example the `title`
|
||||
property of the widget clobbers the `title` property of the transclusion.
|
||||
|
||||
|
||||
To solve the issue of lack of isolation, the directive declares a new `isolated` scope. An
|
||||
isolated scope does not prototypically inherit from the child scope, and therefore we don't have
|
||||
to worry about accidentally clobbering any properties.
|
||||
|
||||
However 'isolated' scope creates a new problem: if a transcluded DOM is a child of the widget
|
||||
isolated scope then it will not be able to bind to anything. For this reason the transcluded scope
|
||||
is a child of the original scope, before the widget created an isolated scope for its local
|
||||
variables. This makes the transcluded and widget isolated scope siblings.
|
||||
|
||||
This may seem as unexpected complexity, but it gives the widget user and developer the least
|
||||
surprise.
|
||||
|
||||
Therefore the final directive definition looks something like this:
|
||||
|
||||
<pre>
|
||||
transclude: true,
|
||||
scope: {
|
||||
title: 'bind', // set up title to accept data-binding
|
||||
onOk: 'exp', // create a delegate onOk function
|
||||
onCancel: 'exp', // create a delegate onCancel function
|
||||
show: 'prop' // create a getter/setter function for visibility.
|
||||
}
|
||||
</pre>
|
||||
|
||||
# Creating Components
|
||||
|
||||
It is often desirable to replace a single directive with a more complex DOM structure. This
|
||||
allows the directives to become a short hand for reusable components from which applications
|
||||
can be built.
|
||||
|
||||
Following is an example of building a reusable widget.
|
||||
|
||||
|
||||
<doc:example module="zippyModule">
|
||||
<doc:source>
|
||||
<script>
|
||||
function Ctrl3($scope) {
|
||||
$scope.title = 'Lorem Ipsum';
|
||||
$scope.text = 'Neque porro quisquam est qui dolorem ipsum quia dolor...';
|
||||
}
|
||||
|
||||
angular.module('zippyModule', [])
|
||||
.directive('zippy', function(){
|
||||
return {
|
||||
restrict: 'C',
|
||||
// This HTML will replace the zippy directive.
|
||||
replace: true,
|
||||
transclude: true,
|
||||
scope: { zippyTitle:'bind' },
|
||||
template: '<div>' +
|
||||
'<div class="title">{{zippyTitle}}</div>' +
|
||||
'<div class="body" ng-transclude></div>' +
|
||||
'</div>',
|
||||
// The linking function will add behavior to the template
|
||||
link: function(scope, element, attrs) {
|
||||
// Title element
|
||||
var title = angular.element(element.children()[0]),
|
||||
// Opened / closed state
|
||||
opened = true;
|
||||
|
||||
// Clicking on title should open/close the zippy
|
||||
title.bind('click', toggle);
|
||||
|
||||
// Toggle the closed/opened state
|
||||
function toggle() {
|
||||
opened = !opened;
|
||||
element.removeClass(opened ? 'closed' : 'opened');
|
||||
element.addClass(opened ? 'opened' : 'closed');
|
||||
}
|
||||
|
||||
// initialize the zippy
|
||||
toggle();
|
||||
}
|
||||
}
|
||||
});
|
||||
</script>
|
||||
<style>
|
||||
.zippy {
|
||||
border: 1px solid black;
|
||||
display: inline-block;
|
||||
width: 250px;
|
||||
}
|
||||
.zippy.opened > .title:before { content: '▼ '; }
|
||||
.zippy.opened > .body { display: block; }
|
||||
.zippy.closed > .title:before { content: '► '; }
|
||||
.zippy.closed > .body { display: none; }
|
||||
.zippy > .title {
|
||||
background-color: black;
|
||||
color: white;
|
||||
padding: .1em .3em;
|
||||
cursor: pointer;
|
||||
}
|
||||
.zippy > .body {
|
||||
padding: .1em .3em;
|
||||
}
|
||||
</style>
|
||||
<div ng-controller="Ctrl3">
|
||||
Title: <input ng-model="title"> <br>
|
||||
Text: <textarea ng-model="text"></textarea>
|
||||
<hr>
|
||||
<div class="zippy" zippy-title="Details: {{title}}...">{{text}}</div>
|
||||
</div>
|
||||
</doc:source>
|
||||
<doc:scenario>
|
||||
it('should bind and open / close', function() {
|
||||
input('title').enter('TITLE');
|
||||
input('text').enter('TEXT');
|
||||
expect(element('.title').text()).toEqual('Details: TITLE...');
|
||||
expect(binding('text')).toEqual('TEXT');
|
||||
|
||||
expect(element('.zippy').prop('className')).toMatch(/closed/);
|
||||
element('.zippy > .title').click();
|
||||
expect(element('.zippy').prop('className')).toMatch(/opened/);
|
||||
});
|
||||
</doc:scenario>
|
||||
</doc:example>
|
||||
@@ -0,0 +1,5 @@
|
||||
@ngdoc overview
|
||||
@name angular.module.ng
|
||||
@description
|
||||
|
||||
The `ng` is an angular module which contains all of the core angular services.
|
||||
@@ -0,0 +1,63 @@
|
||||
@ngdoc overview
|
||||
@name API Reference
|
||||
@description
|
||||
|
||||
## Angular Compiler API
|
||||
|
||||
* {@link angular.module.ng.$compileProvider.directive Directives} - Angular DOM element attributes
|
||||
* {@link angular.module.ng.$filter Filters} - Angular output filters
|
||||
* {@link angular.module.ng.$compile $compile} - Template compiler
|
||||
|
||||
## Angular Scope API
|
||||
|
||||
* {@link angular.module.ng.$rootScope.Scope Scope Object} - Angular scope object
|
||||
|
||||
|
||||
## Angular Services & Dependency Injection API
|
||||
|
||||
* {@link angular.module.ng Angular Services}
|
||||
* {@link angular.injector angular.injector() }
|
||||
|
||||
|
||||
## Angular Testing API
|
||||
|
||||
* {@link angular.module.ngMock Testing Mocks API} - Mock objects for testing
|
||||
* {@link guide/dev_guide.e2e-testing Angular Scenario Runner} - Automated scenario testing
|
||||
documentation
|
||||
|
||||
|
||||
## Angular Utility Functions
|
||||
|
||||
### HTML & DOM Manipulation
|
||||
|
||||
* {@link angular.element angular.element()}
|
||||
|
||||
### Misc
|
||||
|
||||
* {@link angular.bind angular.bind() }
|
||||
* {@link angular.extend angular.extend() }
|
||||
* {@link angular.forEach angular.forEach() }
|
||||
* {@link angular.identity angular.identity() }
|
||||
* {@link angular.noop angular.noop() }
|
||||
|
||||
|
||||
## Type Identification
|
||||
|
||||
* {@link angular.isArray angular.isArray() }
|
||||
* {@link angular.isDate angular.isDate() }
|
||||
* {@link angular.isDefined angular.isDefined() }
|
||||
* {@link angular.isFunction angular.isFunction() }
|
||||
* {@link angular.isNumber angular.isNumber() }
|
||||
* {@link angular.isObject angular.isObject() }
|
||||
* {@link angular.isString angular.isString() }
|
||||
* {@link angular.isUndefined angular.isUndefined() }
|
||||
|
||||
## Strings
|
||||
|
||||
* {@link angular.lowercase angular.lowercase() }
|
||||
* {@link angular.uppercase angular.uppercase() }
|
||||
|
||||
### JSON
|
||||
|
||||
* {@link angular.fromJson angular.fromJson() }
|
||||
* {@link angular.toJson angular.toJson() }
|
||||
@@ -0,0 +1,127 @@
|
||||
@ngdoc overview
|
||||
@name Cookbook: Advanced Form
|
||||
@description
|
||||
|
||||
Here we extend the basic form example to include common features such as reverting, dirty state
|
||||
detection, and preventing invalid form submission.
|
||||
|
||||
<doc:example>
|
||||
<doc:source>
|
||||
<script>
|
||||
function UserForm($scope) {
|
||||
var master = {
|
||||
name: 'John Smith',
|
||||
address:{
|
||||
line1: '123 Main St.',
|
||||
city:'Anytown',
|
||||
state:'AA',
|
||||
zip:'12345'
|
||||
},
|
||||
contacts:[
|
||||
{type:'phone', value:'1(234) 555-1212'}
|
||||
]
|
||||
};
|
||||
|
||||
$scope.state = /^\w\w$/;
|
||||
$scope.zip = /^\d\d\d\d\d$/;
|
||||
|
||||
$scope.cancel = function() {
|
||||
$scope.form = angular.copy(master);
|
||||
};
|
||||
|
||||
$scope.save = function() {
|
||||
master = $scope.form;
|
||||
$scope.cancel();
|
||||
};
|
||||
|
||||
$scope.addContact = function() {
|
||||
$scope.form.contacts.push({type:'', value:''});
|
||||
};
|
||||
|
||||
$scope.removeContact = function(contact) {
|
||||
var contacts = $scope.form.contacts;
|
||||
for (var i = 0, ii = contacts.length; i < ii; i++) {
|
||||
if (contact === contacts[i]) {
|
||||
contacts.splice(i, 1);
|
||||
}
|
||||
}
|
||||
};
|
||||
|
||||
$scope.isCancelDisabled = function() {
|
||||
return angular.equals(master, $scope.form);
|
||||
};
|
||||
|
||||
$scope.isSaveDisabled = function() {
|
||||
return $scope.myForm.$invalid || angular.equals(master, $scope.form);
|
||||
};
|
||||
|
||||
$scope.cancel();
|
||||
}
|
||||
</script>
|
||||
<div ng-controller="UserForm">
|
||||
|
||||
<form name="myForm">
|
||||
|
||||
<label>Name:</label><br/>
|
||||
<input type="text" ng-model="form.name" required/> <br/><br/>
|
||||
|
||||
<label>Address:</label> <br/>
|
||||
<input type="text" ng-model="form.address.line1" size="33" required/> <br/>
|
||||
<input type="text" ng-model="form.address.city" size="12" required/>,
|
||||
<input type="text" ng-model="form.address.state" size="2"
|
||||
ng-pattern="state" required/>
|
||||
<input type="text" ng-model="form.address.zip" size="5"
|
||||
ng-pattern="zip" required/><br/><br/>
|
||||
|
||||
<label>Contacts:</label>
|
||||
[ <a href="" ng-click="addContact()">add</a> ]
|
||||
<div ng-repeat="contact in form.contacts">
|
||||
<select ng-model="contact.type">
|
||||
<option>email</option>
|
||||
<option>phone</option>
|
||||
<option>pager</option>
|
||||
<option>IM</option>
|
||||
</select>
|
||||
<input type="text" ng-model="contact.value" required/>
|
||||
[ <a href="" ng-click="removeContact(contact)">X</a> ]
|
||||
</div>
|
||||
<button ng-click="cancel()" ng-disabled="{{isCancelDisabled()}}">Cancel</button>
|
||||
<button ng-click="save()" ng-disabled="{{isSaveDisabled()}}">Save</button>
|
||||
</form>
|
||||
|
||||
<hr/>
|
||||
Debug View:
|
||||
<pre>form={{form}}</pre>
|
||||
</div>
|
||||
</doc:source>
|
||||
<doc:scenario>
|
||||
it('should enable save button', function() {
|
||||
expect(element(':button:contains(Save)').attr('disabled')).toBeTruthy();
|
||||
input('form.name').enter('');
|
||||
expect(element(':button:contains(Save)').attr('disabled')).toBeTruthy();
|
||||
input('form.name').enter('change');
|
||||
expect(element(':button:contains(Save)').attr('disabled')).toBeFalsy();
|
||||
element(':button:contains(Save)').click();
|
||||
expect(element(':button:contains(Save)').attr('disabled')).toBeTruthy();
|
||||
});
|
||||
it('should enable cancel button', function() {
|
||||
expect(element(':button:contains(Cancel)').attr('disabled')).toBeTruthy();
|
||||
input('form.name').enter('change');
|
||||
expect(element(':button:contains(Cancel)').attr('disabled')).toBeFalsy();
|
||||
element(':button:contains(Cancel)').click();
|
||||
expect(element(':button:contains(Cancel)').attr('disabled')).toBeTruthy();
|
||||
expect(element(':input[ng\\:model="form.name"]').val()).toEqual('John Smith');
|
||||
});
|
||||
</doc:scenario>
|
||||
</doc:example>
|
||||
|
||||
|
||||
#Things to notice
|
||||
|
||||
* Cancel & save buttons are only enabled if the form is dirty — there is something to cancel or
|
||||
save.
|
||||
* Save button is only enabled if there are no validation errors on the form.
|
||||
* Cancel reverts the form changes back to original state.
|
||||
* Save updates the internal model of the form.
|
||||
* Debug view shows the two models. One presented to the user form and the other being the pristine
|
||||
copy master.
|
||||
@@ -1,4 +1,3 @@
|
||||
@workInProgress
|
||||
@ngdoc overview
|
||||
@name Cookbook: Resources - Buzz
|
||||
@description
|
||||
@@ -6,54 +5,55 @@
|
||||
External resources are URLs that provide JSON data, which are then rendered with the help of
|
||||
templates. angular has a resource factory that can be used to give names to the URLs and then
|
||||
attach behavior to them. For example you can use the
|
||||
{@link http://code.google.com/apis/buzz/v1/getting_started.html#background-operations| Google Buzz API}
|
||||
{@link http://code.google.com/apis/buzz/v1/getting_started.html#background-operations| Google Buzz
|
||||
API}
|
||||
to retrieve Buzz activity and comments.
|
||||
|
||||
<doc:example>
|
||||
<doc:source>
|
||||
<script>
|
||||
BuzzController.$inject = ['$resource'];
|
||||
function BuzzController($resource){
|
||||
function BuzzController($resource) {
|
||||
this.userId = 'googlebuzz';
|
||||
this.Activity = $resource(
|
||||
'https://www.googleapis.com/buzz/v1/activities/:userId/:visibility/:activityId/:comments',
|
||||
{alt:'json', callback:'JSON_CALLBACK'},
|
||||
{ get: {method:'JSON', params:{visibility:'@self'}},
|
||||
replies: {method:'JSON', params:{visibility:'@self', comments:'@comments'}}
|
||||
{alt: 'json', callback: 'JSON_CALLBACK'},
|
||||
{ get: {method: 'JSONP', params: {visibility: '@self'}},
|
||||
replies: {method: 'JSONP', params: {visibility: '@self', comments: '@comments'}}
|
||||
});
|
||||
}
|
||||
BuzzController.prototype = {
|
||||
fetch: function(){
|
||||
fetch: function() {
|
||||
this.activities = this.Activity.get({userId:this.userId});
|
||||
},
|
||||
expandReplies: function(activity) {
|
||||
activity.replies =
|
||||
this.Activity.replies({userId:this.userId, activityId:activity.id});
|
||||
activity.replies = this.Activity.replies({userId: this.userId, activityId: activity.id});
|
||||
}
|
||||
};
|
||||
</script>
|
||||
<div ng:controller="BuzzController">
|
||||
<input name="userId" value="googlebuzz"/>
|
||||
<button ng:click="fetch()">fetch</button>
|
||||
<div ng-controller="BuzzController">
|
||||
<input ng-model="userId"/>
|
||||
<button ng-click="fetch()">fetch</button>
|
||||
<hr/>
|
||||
<div class="buzz" ng:repeat="item in activities.data.items">
|
||||
<div class="buzz" ng-repeat="item in activities.data.items">
|
||||
<h1 style="font-size: 15px;">
|
||||
<img src="{{item.actor.thumbnailUrl}}" style="max-height:30px;max-width:30px;"/>
|
||||
<a href="{{item.actor.profileUrl}}">{{item.actor.name}}</a>
|
||||
<a href="" ng:click="expandReplies(item)" style="float: right;">
|
||||
<img ng-src="{{item.actor.thumbnailUrl}}" style="max-height:30px;max-width:30px;"/>
|
||||
<a ng-href="{{item.actor.profileUrl}}">{{item.actor.name}}</a>
|
||||
<a href ng-click="expandReplies(item)" style="float: right;">
|
||||
Expand replies: {{item.links.replies[0].count}}
|
||||
</a>
|
||||
</h1>
|
||||
{{item.object.content | html}}
|
||||
<div class="reply" ng:repeat="reply in item.replies.data.items" style="margin-left: 20px;">
|
||||
<img src="{{reply.actor.thumbnailUrl}}" style="max-height:30px;max-width:30px;"/>
|
||||
<a href="{{reply.actor.profileUrl}}">{{reply.actor.name}}</a>:
|
||||
<div class="reply" ng-repeat="reply in item.replies.data.items" style="margin-left: 20px;">
|
||||
<img ng-src="{{reply.actor.thumbnailUrl}}" style="max-height:30px;max-width:30px;"/>
|
||||
<a ng-href="{{reply.actor.profileUrl}}">{{reply.actor.name}}</a>:
|
||||
{{reply.content | html}}
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
</doc:source>
|
||||
<doc:scenario>
|
||||
it('fetch buzz and expand', function(){
|
||||
xit('fetch buzz and expand', function() {
|
||||
element(':button:contains(fetch)').click();
|
||||
expect(repeater('div.buzz').count()).toBeGreaterThan(0);
|
||||
element('.buzz a:contains(Expand replies):first').click();
|
||||
@@ -1,4 +1,3 @@
|
||||
@workInProgress
|
||||
@ngdoc overview
|
||||
@name Cookbook: Deep Linking
|
||||
@description
|
||||
@@ -28,57 +27,55 @@ controller.
|
||||
|
||||
In this example we have a simple app which consist of two screens:
|
||||
|
||||
* Welcome: url `#` Show the user contact information.
|
||||
* Settings: url `#/settings` Show an edit screen for user contact information.
|
||||
* Welcome: url `welcome` Show the user contact information.
|
||||
* Settings: url `settings` Show an edit screen for user contact information.
|
||||
|
||||
|
||||
The two partials are defined in the following URLs:
|
||||
|
||||
* {@link ./static/settings.html}
|
||||
* {@link ./static/welcome.html}
|
||||
* <a href="./examples/settings.html" ng-ext-link>./examples/settings.html</a>
|
||||
* <a href="./examples/welcome.html" ng-ext-link>./examples/welcome.html</a>
|
||||
|
||||
|
||||
<doc:example>
|
||||
<doc:source>
|
||||
<doc:example module="deepLinking">
|
||||
<doc:source jsfiddle="false">
|
||||
<script>
|
||||
AppCntl.$inject = ['$route']
|
||||
function AppCntl($route) {
|
||||
// define routes
|
||||
$route.when("", {template:'./static/welcome.html', controller:WelcomeCntl});
|
||||
$route.when("/settings", {template:'./static/settings.html', controller:SettingsCntl});
|
||||
$route.parent(this);
|
||||
angular.module('deepLinking', [])
|
||||
.config(function($routeProvider) {
|
||||
$routeProvider.when("/welcome", {template:'./examples/welcome.html', controller:WelcomeCntl});
|
||||
$routeProvider.when("/settings", {template:'./examples/settings.html', controller:SettingsCntl});
|
||||
});
|
||||
|
||||
AppCntl.$inject = ['$scope', '$route']
|
||||
function AppCntl($scope, $route) {
|
||||
// initialize the model to something useful
|
||||
this.person = {
|
||||
$scope.person = {
|
||||
name:'anonymous',
|
||||
contacts:[{type:'email', url:'anonymous@example.com'}]
|
||||
};
|
||||
}
|
||||
|
||||
function WelcomeCntl($route){}
|
||||
WelcomeCntl.prototype = {
|
||||
greet: function(){
|
||||
alert("Hello " + this.person.name);
|
||||
}
|
||||
};
|
||||
|
||||
function SettingsCntl(){
|
||||
this.cancel();
|
||||
function WelcomeCntl($scope) {
|
||||
$scope.greet = function() {
|
||||
alert("Hello " + $scope.person.name);
|
||||
};
|
||||
}
|
||||
SettingsCntl.prototype = {
|
||||
cancel: function(){
|
||||
this.form = angular.copy(this.person);
|
||||
},
|
||||
|
||||
save: function(){
|
||||
angular.copy(this.form, this.person);
|
||||
window.location.hash = "#";
|
||||
}
|
||||
};
|
||||
function SettingsCntl($scope, $location) {
|
||||
$scope.cancel = function() {
|
||||
$scope.form = angular.copy($scope.person);
|
||||
};
|
||||
|
||||
$scope.save = function() {
|
||||
angular.copy($scope.form, $scope.person);
|
||||
$location.path('/welcome');
|
||||
};
|
||||
|
||||
$scope.cancel();
|
||||
}
|
||||
</script>
|
||||
<div ng:controller="AppCntl">
|
||||
<div ng-controller="AppCntl">
|
||||
<h1>Your App Chrome</h1>
|
||||
[ <a href="#">Welcome</a> | <a href="#/settings">Settings</a> ]
|
||||
[ <a href="welcome">Welcome</a> | <a href="settings">Settings</a> ]
|
||||
<hr/>
|
||||
<span style="background-color: blue; color: white; padding: 3px;">
|
||||
Partial: {{$route.current.template}}
|
||||
@@ -88,7 +85,7 @@ The two partials are defined in the following URLs:
|
||||
</div>
|
||||
</doc:source>
|
||||
<doc:scenario>
|
||||
it('should navigate to URL', function(){
|
||||
it('should navigate to URL', function() {
|
||||
element('a:contains(Welcome)').click();
|
||||
expect(element('ng\\:view').text()).toMatch(/Hello anonymous/);
|
||||
element('a:contains(Settings)').click();
|
||||
@@ -105,10 +102,11 @@ The two partials are defined in the following URLs:
|
||||
# Things to notice
|
||||
|
||||
* Routes are defined in the `AppCntl` class. The initialization of the controller causes the
|
||||
initialization of the {@link angular.service.$rouet $route} service with the proper URL routes.
|
||||
* The {@link angular.service.$route $route} service then watches the URL and instantiates the
|
||||
initialization of the {@link api/angular.module.ng.$route $route} service with the proper URL
|
||||
routes.
|
||||
* The {@link api/angular.module.ng.$route $route} service then watches the URL and instantiates the
|
||||
appropriate controller when the URL changes.
|
||||
* The {@link angular.widget.ng:view ng:view} widget loads the view when the URL changes. It also
|
||||
sets the view scope to the newly instantiated controller.
|
||||
* The {@link api/angular.module.ng.$compileProvider.directive.ng-view ng-view} widget loads the
|
||||
view when the URL changes. It also sets the view scope to the newly instantiated controller.
|
||||
* Changing the URL is sufficient to change the controller and view. It makes no difference whether
|
||||
the URL is changed programatically or by the user.
|
||||
@@ -0,0 +1,115 @@
|
||||
@ngdoc overview
|
||||
@name Cookbook: Form
|
||||
@description
|
||||
|
||||
A web application's main purpose is to present and gather data. For this reason angular strives
|
||||
to make both of these operations trivial. This example shows off how you can build a simple form to
|
||||
allow a user to enter data.
|
||||
|
||||
|
||||
<doc:example>
|
||||
<doc:source>
|
||||
<script>
|
||||
function FormController($scope) {
|
||||
$scope.user = {
|
||||
name: 'John Smith',
|
||||
address:{line1: '123 Main St.', city:'Anytown', state:'AA', zip:'12345'},
|
||||
contacts:[{type:'phone', value:'1(234) 555-1212'}]
|
||||
};
|
||||
$scope.state = /^\w\w$/;
|
||||
$scope.zip = /^\d\d\d\d\d$/;
|
||||
|
||||
$scope.addContact = function() {
|
||||
$scope.user.contacts.push({type:'', value:''});
|
||||
};
|
||||
|
||||
$scope.removeContact = function(contact) {
|
||||
for (var i = 0, ii = this.user.contacts.length; i < ii; i++) {
|
||||
if (contact === this.user.contacts[i]) {
|
||||
$scope.user.contacts.splice(i, 1);
|
||||
}
|
||||
}
|
||||
};
|
||||
}
|
||||
</script>
|
||||
<div ng-controller="FormController" class="example">
|
||||
|
||||
<label>Name:</label><br/>
|
||||
<input type="text" ng-model="user.name" required/> <br/><br/>
|
||||
|
||||
<label>Address:</label><br/>
|
||||
<input type="text" ng-model="user.address.line1" size="33" required> <br/>
|
||||
<input type="text" ng-model="user.address.city" size="12" required>,
|
||||
<input type="text" ng-model="user.address.state" size="2"
|
||||
ng-pattern="state" required>
|
||||
<input type="text" ng-model="user.address.zip" size="5"
|
||||
ng-pattern="zip" required><br/><br/>
|
||||
|
||||
<label>Phone:</label>
|
||||
[ <a href="" ng-click="addContact()">add</a> ]
|
||||
<div ng-repeat="contact in user.contacts">
|
||||
<select ng-model="contact.type">
|
||||
<option>email</option>
|
||||
<option>phone</option>
|
||||
<option>pager</option>
|
||||
<option>IM</option>
|
||||
</select>
|
||||
<input type="text" ng-model="contact.value" required/>
|
||||
[ <a href="" ng-click="removeContact(contact)">X</a> ]
|
||||
</div>
|
||||
<hr/>
|
||||
Debug View:
|
||||
<pre>user={{user}}</pre>
|
||||
</div>
|
||||
|
||||
</doc:source>
|
||||
<doc:scenario>
|
||||
it('should show debug', function() {
|
||||
expect(binding('user')).toMatch(/John Smith/);
|
||||
});
|
||||
it('should add contact', function() {
|
||||
using('.example').element('a:contains(add)').click();
|
||||
using('.example div:last').input('contact.value').enter('you@example.org');
|
||||
expect(binding('user')).toMatch(/\(234\) 555\-1212/);
|
||||
expect(binding('user')).toMatch(/you@example.org/);
|
||||
});
|
||||
|
||||
it('should remove contact', function() {
|
||||
using('.example').element('a:contains(X)').click();
|
||||
expect(binding('user')).not().toMatch(/\(234\) 555\-1212/);
|
||||
});
|
||||
|
||||
it('should validate zip', function() {
|
||||
expect(using('.example').
|
||||
element(':input[ng\\:model="user.address.zip"]').
|
||||
prop('className')).not().toMatch(/ng-invalid/);
|
||||
using('.example').input('user.address.zip').enter('abc');
|
||||
expect(using('.example').
|
||||
element(':input[ng\\:model="user.address.zip"]').
|
||||
prop('className')).toMatch(/ng-invalid/);
|
||||
});
|
||||
|
||||
it('should validate state', function() {
|
||||
expect(using('.example').element(':input[ng\\:model="user.address.state"]').prop('className'))
|
||||
.not().toMatch(/ng-invalid/);
|
||||
using('.example').input('user.address.state').enter('XXX');
|
||||
expect(using('.example').element(':input[ng\\:model="user.address.state"]').prop('className'))
|
||||
.toMatch(/ng-invalid/);
|
||||
});
|
||||
</doc:scenario>
|
||||
</doc:example>
|
||||
|
||||
|
||||
# Things to notice
|
||||
|
||||
* The user data model is initialized {@link api/angular.module.ng.$compileProvider.directive.ng-controller controller} and is
|
||||
available in the {@link api/angular.module.ng.$rootScope.Scope scope} with the initial data.
|
||||
* For debugging purposes we have included a debug view of the model to better understand what
|
||||
is going on.
|
||||
* The {@link api/angular.module.ng.$compileProvider.directive.input input directives} simply refer
|
||||
to the model and are data-bound.
|
||||
* The inputs {@link guide/dev_guide.forms validate}. (Try leaving them blank or entering non digits
|
||||
in the zip field)
|
||||
* In your application you can simply read from or write to the model and the form will be updated.
|
||||
* By clicking the 'add' link you are adding new items into the `user.contacts` array which are then
|
||||
reflected in the view.
|
||||
@@ -1,16 +1,22 @@
|
||||
@workInProgress
|
||||
@ngdoc overview
|
||||
@name Cookbook: Hello World
|
||||
@description
|
||||
|
||||
<doc:example>
|
||||
<doc:source>
|
||||
Your name: <input type="text" name="name" value="World"/>
|
||||
<hr/>
|
||||
Hello {{name}}!
|
||||
<script>
|
||||
function HelloCntl($scope) {
|
||||
$scope.name = 'World';
|
||||
}
|
||||
</script>
|
||||
<div ng-controller="HelloCntl">
|
||||
Your name: <input type="text" ng-model="name" value="World"/>
|
||||
<hr/>
|
||||
Hello {{name}}!
|
||||
</div>
|
||||
</doc:source>
|
||||
<doc:scenario>
|
||||
it('should change the binding when user enters text', function(){
|
||||
it('should change the binding when user enters text', function() {
|
||||
expect(binding('name')).toEqual('World');
|
||||
input('name').enter('angular');
|
||||
expect(binding('name')).toEqual('angular');
|
||||
@@ -22,10 +28,12 @@
|
||||
|
||||
Take a look through the source and note:
|
||||
|
||||
* The script tag that {@link guide.bootstrap bootstraps} the angular environment.
|
||||
* The text {@link angular.widget.HTML input widget} which is bound to the greeting name text.
|
||||
* The script tag that {@link guide/dev_guide.bootstrap bootstraps} the angular environment.
|
||||
* The text {@link api/angular.module.ng.$compileProvider.directive.input input widget} which is
|
||||
bound to the greeting name text.
|
||||
* No need for listener registration and event firing on change events.
|
||||
* The implicit presence of the `name` variable which is in the root {@link angular.scope scope}.
|
||||
* The implicit presence of the `name` variable which is in the root {@link api/angular.module.ng.$rootScope.Scope scope}.
|
||||
* The double curly brace `{{markup}}`, which binds the name variable to the greeting text.
|
||||
* The concept of {@link guide.data-binding data binding}, which reflects any changes to the
|
||||
* The concept of {@link guide/dev_guide.templates.databinding data binding}, which reflects any
|
||||
changes to the
|
||||
input field in the greeting text.
|
||||
@@ -1,4 +1,3 @@
|
||||
@workInProgress
|
||||
@ngdoc overview
|
||||
@name Cookbook
|
||||
@description
|
||||
@@ -8,33 +7,33 @@ Welcome to the angular cookbook. Here we will show you typical uses of angular b
|
||||
|
||||
# Hello World
|
||||
|
||||
{@link cookbook.helloworld Hello World}: The simplest possible application that demonstrates the
|
||||
{@link helloworld Hello World}: The simplest possible application that demonstrates the
|
||||
classic Hello World!
|
||||
|
||||
|
||||
# Basic Form
|
||||
|
||||
{@link cookbook.form Basic Form}: Displaying forms to the user for editing is the bread and butter
|
||||
{@link form Basic Form}: Displaying forms to the user for editing is the bread and butter
|
||||
of web applications. Angular makes forms easy through bidirectional data binding.
|
||||
|
||||
|
||||
# Advanced Form
|
||||
|
||||
{@link cookbook.formadvanced Advanced Form}: Taking the form example to the next level and
|
||||
{@link advancedform Advanced Form}: Taking the form example to the next level and
|
||||
providing advanced features such as dirty detection, form reverting and submit disabling if
|
||||
validation errors exist.
|
||||
|
||||
|
||||
# Model View Controller
|
||||
|
||||
{@link cookbook.mvc MVC}: Tic-Tac-Toe: Model View Controller (MVC) is a time-tested design pattern
|
||||
{@link mvc MVC}: Tic-Tac-Toe: Model View Controller (MVC) is a time-tested design pattern
|
||||
to separate the behavior (JavaScript controller) from the presentation (HTML view). This
|
||||
separation aids in maintainability and testability of your project.
|
||||
|
||||
|
||||
# Multi-page App and Deep Linking
|
||||
|
||||
{@link cookbook.deeplinking Deep Linking}: An AJAX application never navigates away from the
|
||||
{@link deeplinking Deep Linking}: An AJAX application never navigates away from the
|
||||
first page it loads. Instead, it changes the DOM of its single page. Eliminating full-page reloads
|
||||
is what makes AJAX apps responsive, but it creates a problem in that apps with a single URL
|
||||
prevent you from emailing links to a particular screen within your application.
|
||||
@@ -45,7 +44,7 @@ allowing you to send links to specific screens in your app.
|
||||
|
||||
# Services
|
||||
|
||||
{@link angular.service Services}: Services are long lived objects in your applications that are
|
||||
{@link api/angular.module.ng Services}: Services are long lived objects in your applications that are
|
||||
available across controllers. A collection of useful services are pre-bundled with angular but you
|
||||
will likely add your own. Services are initialized using dependency injection, which resolves the
|
||||
order of initialization. This safeguards you from the perils of global state (a common way to
|
||||
@@ -54,7 +53,6 @@ implement long lived objects).
|
||||
|
||||
# External Resources
|
||||
|
||||
{@link cookbook.buzz Resources}: Web applications must be able to communicate with the external
|
||||
{@link buzz Resources}: Web applications must be able to communicate with the external
|
||||
services to get and update data. Resources are the abstractions of external URLs which are
|
||||
specially tailored to angular data binding.
|
||||
|
||||
@@ -0,0 +1,127 @@
|
||||
@ngdoc overview
|
||||
@name Cookbook: MVC
|
||||
@description
|
||||
|
||||
MVC allows for a clean an testable separation between the behavior (controller) and the view
|
||||
(HTML template). A Controller is just a JavaScript class which is grafted onto the scope of the
|
||||
view. This makes it very easy for the controller and the view to share the model.
|
||||
|
||||
The model is simply the controller's this. This makes it very easy to test the controller in
|
||||
isolation since one can simply instantiate the controller and test without a view, because there is
|
||||
no connection between the controller and the view.
|
||||
|
||||
|
||||
<doc:example>
|
||||
<doc:source>
|
||||
<script>
|
||||
function TicTacToeCntl($scope, $location) {
|
||||
$scope.cellStyle= {
|
||||
'height': '20px',
|
||||
'width': '20px',
|
||||
'border': '1px solid black',
|
||||
'text-align': 'center',
|
||||
'vertical-align': 'middle',
|
||||
'cursor': 'pointer'
|
||||
};
|
||||
|
||||
$scope.reset = function() {
|
||||
$scope.board = [
|
||||
['', '', ''],
|
||||
['', '', ''],
|
||||
['', '', '']
|
||||
];
|
||||
$scope.nextMove = 'X';
|
||||
$scope.winner = '';
|
||||
setUrl();
|
||||
};
|
||||
|
||||
$scope.dropPiece = function(row, col) {
|
||||
if (!$scope.winner && !$scope.board[row][col]) {
|
||||
$scope.board[row][col] = $scope.nextMove;
|
||||
$scope.nextMove = $scope.nextMove == 'X' ? 'O' : 'X';
|
||||
setUrl();
|
||||
}
|
||||
};
|
||||
|
||||
$scope.reset();
|
||||
$scope.$watch(function() { return $location.search().board;}, readUrl);
|
||||
|
||||
function setUrl() {
|
||||
var rows = [];
|
||||
angular.forEach($scope.board, function(row) {
|
||||
rows.push(row.join(','));
|
||||
});
|
||||
$location.search({board: rows.join(';') + '/' + $scope.nextMove});
|
||||
}
|
||||
|
||||
function grade() {
|
||||
var b = $scope.board;
|
||||
$scope.winner =
|
||||
row(0) || row(1) || row(2) ||
|
||||
col(0) || col(1) || col(2) ||
|
||||
diagonal(-1) || diagonal(1);
|
||||
function row(row) { return same(b[row][0], b[row][1], b[row][2]);}
|
||||
function col(col) { return same(b[0][col], b[1][col], b[2][col]);}
|
||||
function diagonal(i) { return same(b[0][1-i], b[1][1], b[2][1+i]);}
|
||||
function same(a, b, c) { return (a==b && b==c) ? a : '';};
|
||||
}
|
||||
|
||||
function readUrl(value) {
|
||||
if (value) {
|
||||
value = value.split('/');
|
||||
$scope.nextMove = value[1];
|
||||
angular.forEach(value[0].split(';'), function(row, col){
|
||||
$scope.board[col] = row.split(',');
|
||||
});
|
||||
grade();
|
||||
}
|
||||
}
|
||||
}
|
||||
</script>
|
||||
|
||||
<h3>Tic-Tac-Toe</h3>
|
||||
<div ng-controller="TicTacToeCntl">
|
||||
Next Player: {{nextMove}}
|
||||
<div class="winner" ng-show="winner">Player {{winner}} has won!</div>
|
||||
<table class="board">
|
||||
<tr ng-repeat="row in board" style="height:15px;">
|
||||
<td ng-repeat="cell in row" ng-style="cellStyle"
|
||||
ng-click="dropPiece($parent.$index, $index)">{{cell}}</td>
|
||||
</tr>
|
||||
</table>
|
||||
<button ng-click="reset()">reset board</button>
|
||||
</div>
|
||||
</doc:source>
|
||||
<doc:scenario>
|
||||
it('should play a game', function() {
|
||||
piece(1, 1);
|
||||
expect(binding('nextMove')).toEqual('O');
|
||||
piece(3, 1);
|
||||
expect(binding('nextMove')).toEqual('X');
|
||||
piece(1, 2);
|
||||
piece(3, 2);
|
||||
piece(1, 3);
|
||||
expect(element('.winner').text()).toEqual('Player X has won!');
|
||||
});
|
||||
|
||||
function piece(row, col) {
|
||||
element('.board tr:nth-child('+row+') td:nth-child('+col+')').click();
|
||||
}
|
||||
</doc:scenario>
|
||||
</doc:example>
|
||||
|
||||
|
||||
# Things to notice
|
||||
|
||||
* The controller is defined in JavaScript and has no reference to the rendering logic.
|
||||
* The controller is instantiated by <angular/> and injected into the view.
|
||||
* The controller can be instantiated in isolation (without a view) and the code will still execute.
|
||||
This makes it very testable.
|
||||
* The HTML view is a projection of the model. In the above example, the model is stored in the
|
||||
board variable.
|
||||
* All of the controller's properties (such as board and nextMove) are available to the view.
|
||||
* Changing the model changes the view.
|
||||
* The view can call any controller function.
|
||||
* In this example, the `setUrl()` and `readUrl()` functions copy the game state to/from the URL's
|
||||
hash so the browser's back button will undo game steps. See deep-linking. This example calls {@link
|
||||
api/angular.module.ng.$rootScope.Scope#$watch $watch()} to set up a listener that invokes `readUrl()` when needed.
|
||||
@@ -0,0 +1,49 @@
|
||||
@ngdoc overview
|
||||
@name Developer Guide: Initializing Angular: Automatic Initialization
|
||||
@description
|
||||
|
||||
Angular initializes automatically when you load the angular script into your page that contains an element
|
||||
with `ng-app` directive:
|
||||
|
||||
<pre>
|
||||
<!doctype html>
|
||||
<html ng-app>
|
||||
<head>
|
||||
<script src="angular.js"></script>
|
||||
</head>
|
||||
<body>
|
||||
I can add: {{ 1+2 }}.
|
||||
</body>
|
||||
</html>
|
||||
</pre>
|
||||
|
||||
From a high-level view, this is what happens during angular's automatic initialization process:
|
||||
|
||||
1. The browser loads the page, and then runs the angular script. Angular waits for the
|
||||
`DOMContentLoaded` (or 'Load') event to attempt to bootstrap.
|
||||
|
||||
2. Angular looks for the `ng-app` directive. If found it then proceeds to compile the DOM element and its children.
|
||||
Optionally the `ng-app` may specify a {@link api/angular.module module} to load before the compilation. For details on
|
||||
how the compiler works, see {@link dev_guide.compiler Angular HTML Compiler}.
|
||||
|
||||
|
||||
## Initialization Options
|
||||
|
||||
The reason why `ng-app` exists is because angular should not assume that the entire HTML
|
||||
document should be processed just because the `angular.js` script is included. In order to compile
|
||||
only a part of the document set the `ng-app` on the root element of this portion.
|
||||
|
||||
## Global Angular Object
|
||||
|
||||
The angular script creates a single global variable `angular` in the global namespace. All angular
|
||||
APIs are bound to fields of this global object.
|
||||
|
||||
|
||||
## Related Topics
|
||||
|
||||
* {@link dev_guide.bootstrap Initializing Angular}
|
||||
* {@link dev_guide.bootstrap.manual_bootstrap Manual Initialization}
|
||||
|
||||
## Related API
|
||||
|
||||
{@link api/angular.module.ng.$compile Compiler API}
|
||||
@@ -0,0 +1,46 @@
|
||||
@ngdoc overview
|
||||
@name Developer Guide: Initializing Angular: Manual Initialization
|
||||
@description
|
||||
|
||||
Letting angular handle the initialization process (bootstrapping) is a handy way to start using
|
||||
angular, but advanced users who want more control over the initialization process can choose to use
|
||||
the manual bootstrapping method instead.
|
||||
|
||||
The best way to get started with manual bootstrapping is to look at the what happens when you use
|
||||
{@link api/angular.module.ng.$compileProvider.directive.ng-app ng-app}, by showing each step of the process
|
||||
explicitly.
|
||||
|
||||
<pre>
|
||||
<!doctype html>
|
||||
<html>
|
||||
<head>
|
||||
<script src="http://code.angularjs.org/angular.js"></script>
|
||||
<script>
|
||||
angular.element(document).ready(function() {
|
||||
angular.bootstrap(document);
|
||||
});
|
||||
</script>
|
||||
</head>
|
||||
<body>
|
||||
Hello {{'World'}}!
|
||||
</body>
|
||||
</html>
|
||||
</pre>
|
||||
|
||||
This is the sequence that your code should follow if you bootstrap angular on your own:
|
||||
|
||||
1. After the page is loaded, find the root of the HTML template, which is typically the root of
|
||||
the document.
|
||||
2. Call {@link api/angular.bootstrap} to {@link dev_guide.compiler compile} the template into
|
||||
an executable, bi-directionally bound application.
|
||||
|
||||
|
||||
## Related Topics
|
||||
|
||||
* {@link dev_guide.bootstrap Initializing Angular}
|
||||
* {@link dev_guide.bootstrap.auto_bootstrap Automatic Initialization}
|
||||
* {@link dev_guide.compiler Angular HTML compiler}
|
||||
|
||||
## Related API
|
||||
|
||||
{@link api/angular.module.ng.$compile Compiler API}
|
||||
@@ -0,0 +1,65 @@
|
||||
@ngdoc overview
|
||||
@name Developer Guide: Initializing Angular
|
||||
@description
|
||||
|
||||
Initializing angular consists of loading the `angular.js` script in your page, and specifying how
|
||||
angular should process and manage the page. To initialize angular you do the following:
|
||||
|
||||
* Specify the angular namespace in the `<html>` page
|
||||
* Choose which flavor of angular script to load (debug or production)
|
||||
* Specify whether or not angular should process and manage the page automatically (`ng-app`)
|
||||
|
||||
The simplest way to initialize angular is to load the angular script and tell angular to compile
|
||||
and manage the whole page. You do this as follows:
|
||||
|
||||
<pre>
|
||||
<!doctype html>
|
||||
<html ng-app>
|
||||
<head>
|
||||
...
|
||||
</head>
|
||||
<body>
|
||||
...
|
||||
<script src="angular.js">
|
||||
</body>
|
||||
</pre>
|
||||
|
||||
|
||||
## Specifying the Angular Namespace
|
||||
|
||||
<html xmlns:ng="http://angularjs.org">
|
||||
|
||||
You need to add the angular namespace declaration if you use `ng:something` style of declaring
|
||||
angular directives and you write your templates as XHTML. Or when you are targeting Internet
|
||||
Explorer older than version 9 (because older versions of IE do not render namespace
|
||||
properly for either HTML or XHTML). For more info please read {@link ie Internet Explorer
|
||||
Compatibility} doc.
|
||||
|
||||
|
||||
## Creating Your Own Namespaces
|
||||
|
||||
When you are ready to define your own {@link api/angular.module.ng.$compileProvider.directive
|
||||
directive}, you may chose to create your own namespace in addition to specifying the angular
|
||||
namespace. You use your own namespace to form the fully qualified name for directives that you
|
||||
create.
|
||||
|
||||
For example, you could map the alias `my` to your domain, and create a directive called `my:directive`.
|
||||
To create your own namespace, simply add another `xmlns` tag to your page, create an alias, and set
|
||||
it to your unique domain:
|
||||
|
||||
<html xmlns:ng="http://angularjs.org" xmlns:my="http://mydomain.com">
|
||||
|
||||
|
||||
## Loading the Angular Bootstrap Script
|
||||
|
||||
The angular bootstrap script comes in two flavors; a debug script, and a production script:
|
||||
|
||||
* angular-[version].js - This is a human-readable file, suitable for development and debugging.
|
||||
* angular-[version].min.js - This is a compressed and obfuscated file, suitable for use in
|
||||
production.
|
||||
|
||||
|
||||
## Related Topics
|
||||
|
||||
* {@link dev_guide.bootstrap.auto_bootstrap Automatic Initialization}
|
||||
* {@link dev_guide.bootstrap.manual_bootstrap Manual Initialization}
|
||||
@@ -0,0 +1,23 @@
|
||||
@ngdoc overview
|
||||
@name Developer Guide: Angular HTML Compiler
|
||||
@description
|
||||
|
||||
The core of angular is its HTML compiler. The compiler processes angular directives allowing them
|
||||
to transform a static HTML page into a dynamic web application.
|
||||
|
||||
The default HTML transformations that the angular compiler provides are useful for building generic
|
||||
apps, but you can also extend the compiler to create a domain-specific language for building
|
||||
specific types of web applications.
|
||||
|
||||
All compilation takes place in the web browser; no server is involved.
|
||||
|
||||
|
||||
## Related Topics
|
||||
|
||||
* {@link dev_guide.compiler.understanding_compiler Understanding How the Compiler Works}
|
||||
* {@link dev_guide.compiler.testing_dom_element Testing a New DOM Element}
|
||||
|
||||
## Related API
|
||||
|
||||
* {@link api/angular.module.ng.$compile Angular Compiler API}
|
||||
* {@link api/angular.module.ng.$compileProvider.directive Directives API}
|
||||
@@ -0,0 +1,16 @@
|
||||
@ngdoc overview
|
||||
@name Developer Guide: Angular HTML Compiler: Testing a New DOM Element
|
||||
@description
|
||||
|
||||
|
||||
"Testing, testing, come in, over?"
|
||||
|
||||
|
||||
## Related Topics
|
||||
|
||||
* {@link dev_guide.compiler Angular HTML Compiler}
|
||||
* {@link dev_guide.compiler.understanding_compiler Understanding How the Compiler Works}
|
||||
|
||||
## Related API
|
||||
|
||||
* {@link api/angular.module.ng.$compile $compile()}
|
||||
@@ -0,0 +1,34 @@
|
||||
@ngdoc overview
|
||||
@name Developer Guide: Angular HTML Compiler: Understanding How the Compiler Works
|
||||
@description
|
||||
|
||||
The {@link api/angular.module.ng.$compile compiler} is responsible for applying
|
||||
{@link api/angular.module.ng.$compileProvider.directive directives} to the HTML. The directives
|
||||
extend the behavior of HTML elements and can effect the DOM structure, presentation, and behavior.
|
||||
This allows Angular to teach the browser new tricks.
|
||||
|
||||
The compilation starts at the root element and proceeds in a depth-first order. As the compiler
|
||||
visits each node it collects the directives, orders them by priority and executes their compile
|
||||
function. The result of the compilation process is a linking function. The linking function
|
||||
can be used on the template clones to quickly bind the directives with the scope.
|
||||
|
||||
The result of the compilation process is a live view. We say 'live' since any changes to the
|
||||
model attached to the {@link api/angular.module.ng.$rootScope.Scope scope} are reflected in the view,
|
||||
and any changes in the view are reflected in the scope. This makes the scope the 'single source of
|
||||
truth'.
|
||||
|
||||
Since directives allow attachment of behavior to the HTML, the angular philosophy is to use the
|
||||
HTML as Domain Specific Language (DSL) when building an application. For example it may be useful
|
||||
to declare `TabPanel` directive, or `KeyboardShortcut` directive when for an application.
|
||||
|
||||
For details on how directives are created see {@link api/angular.module.ng.$compileProvider.directive
|
||||
directives}
|
||||
|
||||
## Related Topics
|
||||
|
||||
* {@link dev_guide.compiler Angular HTML Compiler}
|
||||
* {@link dev_guide.compiler.testing_dom_element Testing a New DOM Element}
|
||||
|
||||
## Related API
|
||||
|
||||
* {@link api/angular.module.ng.$compile $compile()}
|
||||
@@ -0,0 +1,32 @@
|
||||
@ngdoc overview
|
||||
@name Developer Guide: About Dependency Injection (DI)
|
||||
@description
|
||||
|
||||
Dependency Injection (DI) is an object-oriented software design pattern that supports the
|
||||
decoupling and dependency management of application components.
|
||||
|
||||
The idea behind DI is to decouple each component from all of the other components that it depends
|
||||
on to do its particular job. The way this is done in DI is by moving the responsibility for
|
||||
managing dependencies out of each individual component and into a provider component. The provider
|
||||
(or injector) component manages the life cycles and dependencies for all of the other components in
|
||||
an application.
|
||||
|
||||
Angular has a built-in dependency management subsystem that helps to make your applications easier
|
||||
to develop, understand, and test.
|
||||
|
||||
For more information on DI in general, see {@link http://en.wikipedia.org/wiki/Dependency_injection
|
||||
Dependency Injection} at Wikipedia, and {@link http://martinfowler.com/articles/injection.html
|
||||
Inversion of Control} by Martin Fowler, or read about DI in your favorite software design pattern
|
||||
book.
|
||||
|
||||
|
||||
## Related Topics
|
||||
|
||||
* {@link dev_guide.di.understanding_di Understanding DI in Angular}
|
||||
* {@link dev_guide.services Angular Services}
|
||||
|
||||
|
||||
## Related API
|
||||
|
||||
* {@link api/angular.module.ng Service API}
|
||||
* {@link api/angular.injector Angular Injector API}
|
||||
@@ -0,0 +1,193 @@
|
||||
@ngdoc overview
|
||||
@name Developer Guide: DI: Understanding DI in Angular
|
||||
@description
|
||||
|
||||
|
||||
While DI is widely used in statically typed languages such as Java or C++, it has not been widely
|
||||
used in JavaScript. Angular brings the benefits of DI into JavaScript apps.
|
||||
|
||||
In angular, DI is implemented as a subsystem that manages dependencies between services,
|
||||
controllers, widgets, and filters.
|
||||
|
||||
Services are objects that handle common tasks in web applications. Angular provides several {@link
|
||||
api/angular.module.ng built-in services}, and you can create your
|
||||
{@link dev_guide.services.creating_services own custom services}.
|
||||
|
||||
The main job of angular's DI subsystem is to provide services to angular components that depend on
|
||||
them. The way the DI subsystem provides services is as follows: all services are registered with
|
||||
angular's {@link api/angular.module.ng service API}, and all components that depend on services
|
||||
define those dependencies as a property (`$inject`). With this information, the DI subsystem
|
||||
manages the creation of service objects and the provision of those objects to the components that
|
||||
need them, at the time they need them. The following illustration steps through the sequence of
|
||||
events:
|
||||
|
||||
<img src="img/guide/di_sequence_final.png">
|
||||
|
||||
In the illustration above, the dependency injection sequence proceeds as follows:
|
||||
|
||||
1. Module "phonecat" is created and all the service providers are registered with this module.
|
||||
(the "ng" module is created by Angular behind the scenes as well)
|
||||
2. `ng-app` triggers bootstrap sequence on given element, during which angular creates injector,
|
||||
loads "phonecat" and "ng" modules and compiles the template.
|
||||
3. The `ng-controller` directive implicitly creates a new child scope and instantiates
|
||||
`PhoneListCtrl` controller.
|
||||
4. Injector identifies the `$http` service as `PhoneListCtrl` controller's only dependency.
|
||||
5. Injector checks its instances cache whether the `$http` service has already been instantiated.
|
||||
If not uses the provider from the available modules to construct it.
|
||||
6. Injector provides the instance of `$http` service to the `PhoneListCtrl` controller constructor.
|
||||
|
||||
|
||||
## How Scope Relates to DI
|
||||
|
||||
The root scope of the application is just a service that is available for injection to any part of
|
||||
the application under the service name "$rootScope".
|
||||
|
||||
|
||||
## Inferring dependencies from the signature of the factory function or constructor
|
||||
|
||||
**EXPERIMENTAL FEATURE**: This is an experimental feature. See the important note at the end of
|
||||
this section for drawbacks.
|
||||
|
||||
We resort to `$inject` and our own annotation because there is no way in JavaScript to get a list
|
||||
of arguments. Or is there? It turns out that calling `.toString()` on a function returns the
|
||||
function declaration along with the argument names as shown below:
|
||||
|
||||
<pre>
|
||||
function myFn(a,b){}
|
||||
expect(myFn.toString()).toEqual('function myFn(a,b){}');
|
||||
</pre>
|
||||
|
||||
This means that angular can infer the function names after all and use that information to generate
|
||||
the `$inject` annotation automatically. Therefore the following two function definitions are
|
||||
equivalent:
|
||||
|
||||
<pre>
|
||||
// given a user defined service
|
||||
angular.module('module1', [], function($provide) {
|
||||
$provide.factory('serviceA', ...);
|
||||
});
|
||||
|
||||
// inject '$window', 'serviceA', curry 'name';
|
||||
function fnA($window, serviceA, name){};
|
||||
fnA.$inject = ['$window', 'serviceA'];
|
||||
|
||||
// inject '$window', 'serviceA', curry 'name';
|
||||
function fnB($window, serviceA_, name){};
|
||||
// implies: fnB.$inject = ['$window', 'serviceA'];
|
||||
</pre>
|
||||
|
||||
If angular does not find a `$inject` annotation on the function, then it calls the `.toString()`
|
||||
method and tries to infer what should be injected by using function argument names as dependency
|
||||
identifiers.
|
||||
|
||||
**IMPORTANT**
|
||||
Minifiers/obfuscators change the names of function arguments and will therefore break the `$inject`
|
||||
inference. For this reason, either explicitly declare the `$inject` or do not use
|
||||
minifiers/obfuscators. In the future, we may provide a pre-processor which will scan the source
|
||||
code and insert the `$inject` into the source code so that it can be minified/obfuscated.
|
||||
|
||||
|
||||
### Dependency inference and variable name shadowing
|
||||
|
||||
During inference, the injector considers argument names with leading and trailing underscores to be
|
||||
equivivalent to the name without these underscores. For example `_fooSvc_` argument name is treated
|
||||
as if it was `fooSvc`, this is useful especially in tests where variable name shadowing can cause
|
||||
some friction. This is best illustrated on examples:
|
||||
|
||||
When testing a service, it's common to need a reference to it in every single test. This can be
|
||||
done in jasmine with DI inference like this:
|
||||
|
||||
<pre>
|
||||
describe('fooSvc', function() {
|
||||
it('should do this thing', inject(function(fooSvc) {
|
||||
//test fooSvc
|
||||
}));
|
||||
|
||||
it('should do that thing', inject(function(fooSvc) {
|
||||
//test fooSvc
|
||||
}));
|
||||
|
||||
// more its
|
||||
});
|
||||
</pre>
|
||||
|
||||
... but having to inject the service over and over gets easily tiresome.
|
||||
|
||||
It's likely better to rewrite these tests with a use of jasmine's `beforeEach`:
|
||||
|
||||
<pre>
|
||||
describe('fooSvc', function() {
|
||||
var fooSvc;
|
||||
|
||||
beforeEach(inject(function(fooSvc) {
|
||||
fooSvc = fooSvc; // DOESN'T WORK! outer fooSvc is being shadowed
|
||||
}));
|
||||
|
||||
it('should do this thing', function() {
|
||||
//test fooSvc
|
||||
});
|
||||
|
||||
it('should do that thing', function() {
|
||||
//test fooSvc
|
||||
});
|
||||
|
||||
// more its
|
||||
});
|
||||
</pre>
|
||||
|
||||
This obviously won't work because `fooSvc` variable in the describe block is being shadowed by the
|
||||
`fooSvc` argument of the beforeEach function. So we have to resort to alternative solutions, like
|
||||
for example use of array notation to annotate the beforeEach fn:
|
||||
|
||||
<pre>
|
||||
describe('fooSvc', function() {
|
||||
var fooSvc;
|
||||
|
||||
beforeEach(inject(['fooSvc', function(fooSvc_) {
|
||||
fooSvc = fooSvc_;
|
||||
}]));
|
||||
|
||||
it('should do this thing', function() {
|
||||
//test fooSvc
|
||||
});
|
||||
|
||||
it('should do that thing', function() {
|
||||
//test fooSvc
|
||||
});
|
||||
});
|
||||
</pre>
|
||||
|
||||
|
||||
That's better, but it's still annoying, especially if you have many services to inject.
|
||||
|
||||
To resolve this shadowing problem, the injector considers `_fooSvc_` argument names equal to
|
||||
`fooSvc`, so the test can be rewritten like this:
|
||||
|
||||
<pre>
|
||||
describe('fooSvc', function() {
|
||||
var fooSvc;
|
||||
|
||||
beforeEach(inject(function(_fooSvc_) {
|
||||
fooSvc = _fooSvc_;
|
||||
}));
|
||||
|
||||
it('should do this thing', function() {
|
||||
//test fooSvc
|
||||
});
|
||||
|
||||
it('should do that thing', function() {
|
||||
//test fooSvc
|
||||
});
|
||||
|
||||
// more its
|
||||
});
|
||||
</pre>
|
||||
|
||||
|
||||
## Related Topics
|
||||
|
||||
* {@link dev_guide.services Angular Services}
|
||||
|
||||
## Related API
|
||||
|
||||
* {@link api/angular.module.ng Services API}
|
||||
@@ -0,0 +1,53 @@
|
||||
@ngdoc overview
|
||||
@name Developer Guide: DI: Using DI in Controllers
|
||||
@description
|
||||
|
||||
The most common place to use dependency injection in angular applications is in {@link
|
||||
dev_guide.mvc.understanding_controller controllers}. Here is a simple example:
|
||||
|
||||
<pre>
|
||||
function MyController($route){
|
||||
// configure the route service
|
||||
$route.when(...);
|
||||
}
|
||||
MyController.$inject = ['$route'];
|
||||
</pre>
|
||||
|
||||
In this example, the `MyController` constructor function takes one argument, the {@link
|
||||
api/angular.module.ng.$route $route} service. Angular is then responsible for supplying the instance
|
||||
of `$route` to the controller when the constructor is instantiated. There are two ways to cause
|
||||
controller instantiation – by configuring routes with the `$route` service, or by referencing the
|
||||
controller from the HTML template, as follows:
|
||||
|
||||
<pre>
|
||||
<!doctype html>
|
||||
<html ng-controller="MyController" ng-app>
|
||||
<script src="http://code.angularjs.org/angular.min.js"></script>
|
||||
<body>
|
||||
...
|
||||
</body>
|
||||
</html>
|
||||
</pre>
|
||||
|
||||
When angular is instantiating your controller, it needs to know what services, if any, should be
|
||||
injected (passed in as arguments) into the controller. Since there is no reflection in JavaScript,
|
||||
we have to supply this information to angular in the form of an additional property on the
|
||||
controller constructor function called `$inject`. Think of it as annotations for JavaScript.
|
||||
|
||||
<pre>
|
||||
MyController.$inject = ['$route'];
|
||||
</pre>
|
||||
|
||||
The information in `$inject` is then used by the {@link api/angular.injector injector} to call the
|
||||
function with the correct arguments.
|
||||
|
||||
|
||||
## Related Topics
|
||||
|
||||
* {@link dev_guide.di About Dependency Injection}
|
||||
* {@link dev_guide.di.understanding_di Understanding Dependency Injection in Angular}
|
||||
* {@link dev_guide.services Angular Services}
|
||||
|
||||
## Related API
|
||||
|
||||
* {@link api/angular.injector Angular Injector API}
|
||||
@@ -0,0 +1,178 @@
|
||||
@workInProgress
|
||||
@ngdoc overview
|
||||
@name Developer Guide: E2E Testing
|
||||
@description
|
||||
|
||||
As applications grow in size and complexity, it becomes unrealistic to rely on manual testing to
|
||||
verify the correctness of new features, catch bugs and notice regressions.
|
||||
|
||||
To solve this problem, we have built an Angular Scenario Runner which simulates user interactions
|
||||
that will help you verify the health of your Angular application.
|
||||
|
||||
# Overview
|
||||
You will write scenario tests in JavaScript, which describe how your application should behave,
|
||||
given a certain interaction in a specific state. A scenario is comprised of one or more it blocks
|
||||
(you can think of these as the requirements of your application), which in turn are made of
|
||||
**commands** and **expectations**. Commands tell the Runner to do something with the application
|
||||
(such as navigate to a page or click on a button), and expectations tell the Runner to assert
|
||||
something about the state (such as the value of a field or the current URL). If any expectation
|
||||
fails, the runner marks the `it` as "failed" and continues on to the next one. Scenarios may also
|
||||
have **beforeEach** and **afterEach** blocks, which will be run before (or after) each `it` block,
|
||||
regardless of whether they pass or fail.
|
||||
|
||||
<img src="img/guide/scenario_runner.png">
|
||||
|
||||
In addition to the above elements, scenarios may also contain helper functions to avoid duplicating
|
||||
code in the `it` blocks.
|
||||
|
||||
Here is an example of a simple scenario:
|
||||
<pre>
|
||||
describe('Buzz Client', function() {
|
||||
it('should filter results', function() {
|
||||
input('user').enter('jacksparrow');
|
||||
element(':button').click();
|
||||
expect(repeater('ul li').count()).toEqual(10);
|
||||
input('filterText').enter('Bees');
|
||||
expect(repeater('ul li').count()).toEqual(1);
|
||||
});
|
||||
});
|
||||
</pre>
|
||||
This scenario describes the requirements of a Buzz Client, specifically, that it should be able to
|
||||
filter the stream of the user. It starts by entering a value in the 'user' input field, clicking
|
||||
the only button on the page, and then it verifies that there are 10 items listed. It then enters
|
||||
'Bees' in the 'filterText' input field and verifies that the list is reduced to a single item.
|
||||
|
||||
The API section below lists the available commands and expectations for the Runner.
|
||||
|
||||
# API
|
||||
Source: {@link https://github.com/angular/angular.js/blob/master/src/scenario/dsl.js}
|
||||
|
||||
## pause()
|
||||
Pauses the execution of the tests until you call `resume()` in the console (or click the resume
|
||||
link in the Runner UI).
|
||||
|
||||
## sleep(seconds)
|
||||
Pauses the execution of the tests for the specified number of `seconds`.
|
||||
|
||||
## browser().navigateTo(url)
|
||||
Loads the `url` into the test frame.
|
||||
|
||||
## browser().navigateTo(url, fn)
|
||||
Loads the URL returned by `fn` into the testing frame. The given `url` is only used for the test
|
||||
output. Use this when the destination URL is dynamic (that is, the destination is unknown when you
|
||||
write the test).
|
||||
|
||||
## browser().reload()
|
||||
Refreshes the currently loaded page in the test frame.
|
||||
|
||||
## browser().window().href()
|
||||
Returns the window.location.href of the currently loaded page in the test frame.
|
||||
|
||||
## browser().window().path()
|
||||
Returns the window.location.pathname of the currently loaded page in the test frame.
|
||||
|
||||
## browser().window().search()
|
||||
Returns the window.location.search of the currently loaded page in the test frame.
|
||||
|
||||
## browser().window().hash()
|
||||
Returns the window.location.hash (without `#`) of the currently loaded page in the test frame.
|
||||
|
||||
## browser().location().url()
|
||||
Returns the {@link api/angular.module.ng.$location $location.url()} of the currently loaded page in
|
||||
the test frame.
|
||||
|
||||
## browser().location().path()
|
||||
Returns the {@link api/angular.module.ng.$location $location.path()} of the currently loaded page in
|
||||
the test frame.
|
||||
|
||||
## browser().location().search()
|
||||
Returns the {@link api/angular.module.ng.$location $location.search()} of the currently loaded page
|
||||
in the test frame.
|
||||
|
||||
## browser().location().hash()
|
||||
Returns the {@link api/angular.module.ng.$location $location.hash()} of the currently loaded page in
|
||||
the test frame.
|
||||
|
||||
## expect(future).{matcher}
|
||||
Asserts the value of the given `future` satisfies the `matcher`. All API statements return a
|
||||
`future` object, which get a `value` assigned after they are executed. Matchers are defined using
|
||||
`angular.scenario.matcher`, and they use the value of futures to run the expectation. For example:
|
||||
`expect(browser().location().href()).toEqual('http://www.google.com')`
|
||||
|
||||
## expect(future).not().{matcher}
|
||||
Asserts the value of the given `future` satisfies the negation of the `matcher`.
|
||||
|
||||
## using(selector, label)
|
||||
Scopes the next DSL element selection.
|
||||
|
||||
## binding(name)
|
||||
Returns the value of the first binding matching the given `name`.
|
||||
|
||||
## input(name).enter(value)
|
||||
Enters the given `value` in the text field with the given `name`.
|
||||
|
||||
## input(name).check()
|
||||
Checks/unchecks the checkbox with the given `name`.
|
||||
|
||||
## input(name).select(value)
|
||||
Selects the given `value` in the radio button with the given `name`.
|
||||
|
||||
## input(name).val()
|
||||
Returns the current value of an input field with the given `name`.
|
||||
|
||||
## repeater(selector, label).count()
|
||||
Returns the number of rows in the repeater matching the given jQuery `selector`. The `label` is
|
||||
used for test ouput.
|
||||
|
||||
## repeater(selector, label).row(index)
|
||||
Returns an array with the bindings in the row at the given `index` in the repeater matching the
|
||||
given jQuery `selector`. The `label` is used for test output.
|
||||
|
||||
## repeater(selector, label).column(binding)
|
||||
Returns an array with the values in the column with the given `binding` in the repeater matching
|
||||
the given jQuery `selector`. The `label` is used for test output.
|
||||
|
||||
## select(name).option(value)
|
||||
Picks the option with the given `value` on the select with the given `name`.
|
||||
|
||||
## select(name).option(value1, value2...)
|
||||
Picks the options with the given `values` on the multi select with the given `name`.
|
||||
|
||||
## element(selector, label).count()
|
||||
Returns the number of elements that match the given jQuery `selector`. The `label` is used for test
|
||||
output.
|
||||
|
||||
## element(selector, label).click()
|
||||
Clicks on the element matching the given jQuery `selector`. The `label` is used for test output.
|
||||
|
||||
## element(selector, label).query(fn)
|
||||
Executes the function `fn(selectedElements, done)`, where selectedElements are the elements that
|
||||
match the given jQuery `selector` and `done` is a function that is called at the end of the `fn`
|
||||
function. The `label` is used for test output.
|
||||
|
||||
## element(selector, label).{method}()
|
||||
Returns the result of calling `method` on the element matching the given jQuery `selector`, where
|
||||
`method` can be any of the following jQuery methods: `val`, `text`, `html`, `height`,
|
||||
`innerHeight`, `outerHeight`, `width`, `innerWidth`, `outerWidth`, `position`, `scrollLeft`,
|
||||
`scrollTop`, `offset`. The `label` is used for test output.
|
||||
|
||||
## element(selector, label).{method}(value)
|
||||
Executes the `method` passing in `value` on the element matching the given jQuery `selector`, where
|
||||
`method` can be any of the following jQuery methods: `val`, `text`, `html`, `height`,
|
||||
`innerHeight`, `outerHeight`, `width`, `innerWidth`, `outerWidth`, `position`, `scrollLeft`,
|
||||
`scrollTop`, `offset`. The `label` is used for test output.
|
||||
|
||||
## element(selector, label).{method}(key)
|
||||
Returns the result of calling `method` passing in `key` on the element matching the given jQuery
|
||||
`selector`, where `method` can be any of the following jQuery methods: `attr`, `prop`, `css`. The
|
||||
`label` is used for test output.
|
||||
|
||||
## element(selector, label).{method}(key, value)
|
||||
Executes the `method` passing in `key` and `value` on the element matching the given jQuery
|
||||
`selector`, where `method` can be any of the following jQuery methods: `attr`, `prop`, `css`. The
|
||||
`label` is used for test output.
|
||||
|
||||
JavaScript is a dynamically typed language which comes with great power of expression, but it also
|
||||
come with almost no-help from the compiler. For this reason we feel very strongly that any code
|
||||
written in JavaScript needs to come with a strong set of tests. We have built many features into
|
||||
angular which makes testing your angular applications easy. So there is no excuse for not do it.
|
||||
@@ -0,0 +1,245 @@
|
||||
@ngdoc overview
|
||||
@name Developer Guide: Understanding Angular Expressions
|
||||
@description
|
||||
|
||||
Expressions are {@link dev_guide.templates.databinding bindings} that you write in HTML and embed
|
||||
in templates in order to create views in angular. Angular expressions are similar but not
|
||||
equivalent to JavaScript expressions.
|
||||
|
||||
For example, these are all valid expressions in angular:
|
||||
|
||||
* `1+2={{1+2}}`
|
||||
* `3*10|currency`
|
||||
* `Hello {{name}}!`
|
||||
* `Hello {{'World'}}!`
|
||||
|
||||
|
||||
## Angular Expressions vs. JS Expressions
|
||||
|
||||
It might be tempting to think of angular view expressions as JavaScript expressions, but that is
|
||||
not entirely correct. Angular does not use a simple JavaScript eval of the expression text. You can
|
||||
think of angular expressions as JavaScript expressions with these differences:
|
||||
|
||||
* **Attribute Evaluation:** evaluation of all attributes are against the current scope, not to the
|
||||
global window as in JavaScript.
|
||||
* **Forgiving:** expression evaluation is forgiving to undefined and null, unlike in JavaScript.
|
||||
* **No Control Flow Statements:** you cannot do the following from an angular expression:
|
||||
conditionals, loops, or throw.
|
||||
* **Type Augmentation:** the scope expression evaluator augments built-in types.
|
||||
* **Filters:** you can add filters to an expression, for example to convert raw data into a
|
||||
human-readable format.
|
||||
* **The $:** angular reserves this prefix to differentiate its API names from others.
|
||||
|
||||
If, on the other hand, you do want to run arbitrary JavaScript code, you should make it a
|
||||
controller method and call that. If you want to `eval()` an angular expression from JavaScript, use
|
||||
the `Scope:$eval()` method.
|
||||
|
||||
## Example
|
||||
<doc:example>
|
||||
<doc:source>
|
||||
1+2={{1+2}}
|
||||
</doc:source>
|
||||
<doc:scenario>
|
||||
it('should calculate expression in binding', function() {
|
||||
expect(binding('1+2')).toEqual('3');
|
||||
});
|
||||
</doc:scenario>
|
||||
</doc:example>
|
||||
|
||||
You can try evaluating different expressions here:
|
||||
|
||||
<doc:example>
|
||||
<doc:source>
|
||||
<script>
|
||||
function Cntl2($scope) {
|
||||
$scope.exprs = [];
|
||||
$scope.expr = '3*10|currency';
|
||||
$scope.addExp = function(expr) {
|
||||
this.exprs.push(expr);
|
||||
};
|
||||
|
||||
$scope.removeExp = function(index) {
|
||||
this.exprs.splice(index, 1);
|
||||
};
|
||||
}
|
||||
</script>
|
||||
<div ng-controller="Cntl2" class="expressions">
|
||||
Expression:
|
||||
<input type='text' ng-model="expr" size="80"/>
|
||||
<button ng-click="addExp(expr)">Evaluate</button>
|
||||
<ul>
|
||||
<li ng-repeat="expr in exprs">
|
||||
[ <a href="" ng-click="removeExp($index)">X</a> ]
|
||||
<tt>{{expr}}</tt> => <span ng-bind="$parent.$eval(expr)"></span>
|
||||
</li>
|
||||
</ul>
|
||||
</div>
|
||||
</doc:source>
|
||||
<doc:scenario>
|
||||
it('should allow user expression testing', function() {
|
||||
element('.expressions :button').click();
|
||||
var li = using('.expressions ul').repeater('li');
|
||||
expect(li.count()).toBe(1);
|
||||
expect(li.row(0)).toEqual(["3*10|currency", "$30.00"]);
|
||||
});
|
||||
</doc:scenario>
|
||||
</doc:example>
|
||||
|
||||
|
||||
# Attribute Evaluation
|
||||
|
||||
Evaluation of all attributes takes place against the current scope. Unlike JavaScript, where names
|
||||
default to global window properties, angular expressions have to use `$window` to refer to the
|
||||
global object. For example, if you want to call `alert()`, which is defined on `window`, an
|
||||
expression must use `$window.alert()`. This is done intentionally to prevent accidental access to
|
||||
the global state (a common source of subtle bugs).
|
||||
|
||||
<doc:example>
|
||||
<doc:source>
|
||||
<script>
|
||||
function Cntl1($window, $scope){
|
||||
$scope.name = 'World';
|
||||
|
||||
$scope.greet = function() {
|
||||
($window.mockWindow || $window).alert('Hello ' + this.name);
|
||||
}
|
||||
}
|
||||
</script>
|
||||
<div class="example2" ng-controller="Cntl1">
|
||||
Name: <input ng-model="name" type="text"/>
|
||||
<button ng-click="greet()">Greet</button>
|
||||
</div>
|
||||
</doc:source>
|
||||
<doc:scenario>
|
||||
it('should calculate expression in binding', function() {
|
||||
var alertText;
|
||||
this.addFutureAction('set mock', function($window, $document, done) {
|
||||
$window.mockWindow = {
|
||||
alert: function(text){ alertText = text; }
|
||||
};
|
||||
done();
|
||||
});
|
||||
element(':button:contains(Greet)').click();
|
||||
expect(this.addFuture('alert text', function(done) {
|
||||
done(null, alertText);
|
||||
})).toBe('Hello World');
|
||||
});
|
||||
</doc:scenario>
|
||||
</doc:example>
|
||||
|
||||
## Forgiving
|
||||
|
||||
Expression evaluation is forgiving to undefined and null. In JavaScript, evaluating `a.b.c` throws
|
||||
an exception if `a` is not an object. While this makes sense for a general purpose language, the
|
||||
expression evaluations are primarily used for data binding, which often look like this:
|
||||
|
||||
{{a.b.c}}
|
||||
|
||||
It makes more sense to show nothing than to throw an exception if `a` is undefined (perhaps we are
|
||||
waiting for the server response, and it will become defined soon). If expression evaluation wasn't
|
||||
forgiving we'd have to write bindings that clutter the code, for example: `{{((a||{}).b||{}).c}}`
|
||||
|
||||
Similarly, invoking a function `a.b.c()` on undefined or null simply returns undefined.
|
||||
|
||||
Assignments work the same way in reverse:
|
||||
|
||||
a.b.c = 10
|
||||
|
||||
...creates the intermediary objects even if a is undefined.
|
||||
|
||||
|
||||
## No Control Flow Statements
|
||||
|
||||
You cannot write a control flow statement in an expression. The reason behind this is core to the
|
||||
angular philosophy that application logic should be in controllers, not in the view. If you need a
|
||||
conditional (including ternary operators), loop, or to throw from a view expression, delegate to a
|
||||
JavaScript method instead.
|
||||
|
||||
|
||||
## Type Augmentation
|
||||
|
||||
Built-in types have methods like `[].push()`, but the richness of these methods is limited.
|
||||
Consider the example below, which allows you to do a simple search over a canned set of contacts.
|
||||
The example would be much more complicated if we did not have the `Array:$filter()`. There is no
|
||||
built-in method on `Array` called {@link api/angular.module.ng.$filter.filter $filter} and angular doesn't add
|
||||
it to `Array.prototype` because that could collide with other JavaScript frameworks.
|
||||
|
||||
For this reason the scope expression evaluator augments the built-in types to make them act like
|
||||
they have extra methods. The actual method for `$filter()` is `angular.module.ng.$filter.filter()`. You can
|
||||
call it from JavaScript.
|
||||
|
||||
Extensions: You can further extend the expression vocabulary by adding new methods to
|
||||
`angular.module.ng.$filter` or `angular.String`, etc.
|
||||
|
||||
<doc:example>
|
||||
<doc:source>
|
||||
<div ng-init="friends = [
|
||||
{name:'John', phone:'555-1212'},
|
||||
{name:'Mary', phone:'555-9876'},
|
||||
{name:'Mike', phone:'555-4321'},
|
||||
{name:'Adam', phone:'555-5678'},
|
||||
{name:'Julie', phone:'555-8765'}]"></div>
|
||||
Search: <input ng-model="searchText"/>
|
||||
<table class="example3">
|
||||
<thead>
|
||||
<tr><th>Name</th><th>Phone</th><tr>
|
||||
</thead>
|
||||
<tbody>
|
||||
<tr ng-repeat="friend in friends | filter:searchText">
|
||||
<td>{{friend.name}}</td>
|
||||
<td>{{friend.phone}}</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
</doc:source>
|
||||
<doc:scenario>
|
||||
it('should filter the list', function() {
|
||||
var tr = using('table.example3 tbody').repeater('tr');
|
||||
expect(tr.count()).toBe(5);
|
||||
input('searchText').enter('a');
|
||||
expect(tr.count()).toBe(2);
|
||||
|
||||
});
|
||||
</doc:scenario>
|
||||
</doc:example>
|
||||
|
||||
## Filters
|
||||
|
||||
When presenting data to the user, you might need to convert the data from its raw format to a
|
||||
user-friendly format. For example, you might have a data object that needs to be formatted
|
||||
according to the locale before displaying it to the user. You can pass expressions through a chain
|
||||
of filters like this:
|
||||
|
||||
name | uppercase
|
||||
|
||||
The expression evaluator simply passes the value of name to angular.module.ng.$filter.uppercase.
|
||||
|
||||
Chain filters using this syntax:
|
||||
|
||||
value | filter1 | filter2
|
||||
|
||||
You can also pass colon-delimited arguments to filters, for example, to display the number 123 with
|
||||
2 decimal points:
|
||||
|
||||
123 | number:2
|
||||
|
||||
# The $
|
||||
|
||||
You might be wondering, what is the significance of the $ prefix? It is simply a prefix that
|
||||
angular uses, to differentiate its API names from others. If angular didn't use $, then evaluating
|
||||
`a.length()` would return undefined because neither a nor angular define such a property.
|
||||
|
||||
Consider that in a future version of angular we might choose to add a length method, in which case
|
||||
the behavior of the expression would change. Worse yet, you the developer could create a length
|
||||
property and then we would have a collision. This problem exists because angular augments existing
|
||||
objects with additional behavior. By prefixing its additions with $ we are reserving our namespace
|
||||
so that angular developers and developers who use angular can develop in harmony without collisions.
|
||||
|
||||
|
||||
## Related Topics
|
||||
|
||||
* {@link dev_guide.templates.filters Understanding Angular Filters}
|
||||
|
||||
## Related API
|
||||
|
||||
* {@link api/angular.module.ng.$compile Angular Compiler API}
|
||||
@@ -0,0 +1,328 @@
|
||||
@ngdoc overview
|
||||
@name Developer Guide: Forms
|
||||
@description
|
||||
|
||||
Controls (`input`, `select`, `textarea`) are a way for user to enter data.
|
||||
Form is a collection of controls for the purpose of grouping related controls together.
|
||||
|
||||
Form and controls provide validation services, so that the user can be notified of invalid input.
|
||||
This provides a better user experience, because the user gets instant feedback on how to correct the error.
|
||||
Keep in mind that while client-side validation plays an important role in providing good user experience, it can easily be circumvented and thus can not be trusted.
|
||||
Server-side validation is still necessary for a secure application.
|
||||
|
||||
|
||||
# Simple form
|
||||
The key directive in understanding two-way data-binding is {@link api/angular.module.ng.$compileProvider.directive.ng-model ng-model}.
|
||||
The `ng-model` provides the two-way data-binding by synchronizing the model to the view, as well as view to the model.
|
||||
In addition it provides {@link api/angular.module.ng.$compileProvider.directive.ng-model.NgModelController API} for other directives to augment its behavior.
|
||||
|
||||
<doc:example>
|
||||
<doc:source>
|
||||
<div ng-controller="Controller">
|
||||
<form novalidate class="simple-form">
|
||||
Name: <input type="text" ng-model="user.name" ng-model-instant /><br />
|
||||
E-mail: <input type="email" ng-model="user.email" /><br />
|
||||
Gender: <input type="radio" ng-model="user.gender" value="male" />male
|
||||
<input type="radio" ng-model="user.gender" value="female" />female<br />
|
||||
<button ng-click="reset()">RESET</button>
|
||||
<button ng-click="update(user)">SAVE</button>
|
||||
</form>
|
||||
<pre>form = {{user | json}}</pre>
|
||||
<pre>master = {{master | json}}</pre>
|
||||
</div>
|
||||
|
||||
<script type="text/javascript">
|
||||
function Controller($scope) {
|
||||
$scope.master= {};
|
||||
|
||||
$scope.update = function(user) {
|
||||
$scope.master= angular.copy(user);
|
||||
};
|
||||
|
||||
$scope.reset = function() {
|
||||
$scope.user = angular.copy($scope.master);
|
||||
};
|
||||
|
||||
$scope.reset();
|
||||
}
|
||||
</script>
|
||||
</doc:source>
|
||||
</doc:example>
|
||||
|
||||
|
||||
Note that:
|
||||
|
||||
* the {@link api/angular.module.ng.$compileProvider.directive.ng-model-instant ng-model-instant} causes the `user.name` to be updated immediately.
|
||||
|
||||
* `novalidate` is used to disable browser's native form validation.
|
||||
|
||||
|
||||
|
||||
# Using CSS classes
|
||||
|
||||
To allow styling of form as well as controls, `ng-model` add these CSS classes:
|
||||
|
||||
- `ng-valid`
|
||||
- `ng-invalid`
|
||||
- `ng-pristine`
|
||||
- `ng-dirty`
|
||||
|
||||
Following example uses the CSS to display validity of each form control.
|
||||
In the example both `user.name` and `user.email` are required, but are rendered with red background only when they are dirty.
|
||||
This ensures that the user is not distracted with an error until after interacting with the control, and failing to satisfy its validity.
|
||||
|
||||
<doc:example>
|
||||
<doc:source>
|
||||
<div ng-controller="Controller">
|
||||
<form novalidate class="css-form">
|
||||
Name:
|
||||
<input type="text" ng-model="user.name" ng-model-instant required /><br />
|
||||
E-mail: <input type="email" ng-model="user.email" required /><br />
|
||||
Gender: <input type="radio" ng-model="user.gender" value="male" />male
|
||||
<input type="radio" ng-model="user.gender" value="female" />female<br />
|
||||
<button ng-click="reset()">RESET</button>
|
||||
<button ng-click="update(user)">SAVE</button>
|
||||
</form>
|
||||
</div>
|
||||
|
||||
<style type="text/css">
|
||||
.css-form input.ng-invalid.ng-dirty {
|
||||
background-color: #FA787E;
|
||||
}
|
||||
|
||||
.css-form input.ng-valid.ng-dirty {
|
||||
background-color: #78FA89;
|
||||
}
|
||||
</style>
|
||||
|
||||
<script type="text/javascript">
|
||||
function Controller($scope) {
|
||||
$scope.master= {};
|
||||
|
||||
$scope.update = function(user) {
|
||||
$scope.master= angular.copy(user);
|
||||
};
|
||||
|
||||
$scope.reset = function() {
|
||||
$scope.user = angular.copy($scope.master);
|
||||
};
|
||||
|
||||
$scope.reset();
|
||||
}
|
||||
</script>
|
||||
</doc:source>
|
||||
</doc:example>
|
||||
|
||||
|
||||
|
||||
# Binding to form and control state
|
||||
|
||||
A form is in instance of {@link api/angular.module.ng.$compileProvider.directive.form.FormController FormController}.
|
||||
The form instance can optionally be published into the scope using the `name` attribute.
|
||||
Similarly control is an instance of {@link api/angular.module.ng.$compileProvider.directive.ng-model.NgModelController NgModelController}.
|
||||
The control instance can similarly be published into the form instance using the `name` attribute.
|
||||
This implies that the internal state of both the form and the control is available for binding in the view using the standard binding primitives.
|
||||
|
||||
This allows us to extend the above example with these features:
|
||||
|
||||
- RESET button is enabled only if form has some changes
|
||||
- SAVE button is enabled only if form has some changes and is valid
|
||||
- custom error messages for `user.email` and `user.agree`
|
||||
|
||||
<doc:example>
|
||||
<doc:source>
|
||||
<div ng-controller="Controller">
|
||||
<form name="form" class="css-form" novalidate>
|
||||
Name:
|
||||
<input type="text" ng-model="user.name" name="uName" required /><br />
|
||||
E-mail:
|
||||
<input type="email" ng-model="user.email" name="uEmail" required/><br />
|
||||
<div ng-show="form.uEmail.$dirty && form.uEmail.$invalid">Invalid:
|
||||
<span ng-show="form.uEmail.$error.required">Tell us your email.</span>
|
||||
<span ng-show="form.uEmail.$error.email">This is not a valid email.</span>
|
||||
</div>
|
||||
|
||||
Gender: <input type="radio" ng-model="user.gender" value="male" />male
|
||||
<input type="radio" ng-model="user.gender" value="female" />female<br />
|
||||
|
||||
<input type="checkbox" ng-model="user.agree" name="userAgree" required />
|
||||
I agree: <input ng-show="user.agree" type="text" ng-model="user.agreeSign"
|
||||
ng-model-instant required /><br />
|
||||
<div ng-show="!user.agree || !user.agreeSign">Please agree and sign.</div>
|
||||
|
||||
<button ng-click="reset()" disabled="{{isUnchanged(user)}}">RESET</button>
|
||||
<button ng-click="update(user)"
|
||||
disabled="{{form.$invalid || isUnchanged(user)}}">SAVE</button>
|
||||
</form>
|
||||
</div>
|
||||
|
||||
<script type="text/javascript">
|
||||
function Controller($scope) {
|
||||
$scope.master= {};
|
||||
|
||||
$scope.update = function(user) {
|
||||
$scope.master= angular.copy(user);
|
||||
};
|
||||
|
||||
$scope.reset = function() {
|
||||
$scope.user = angular.copy($scope.master);
|
||||
};
|
||||
|
||||
$scope.isUnchanged = function(user) {
|
||||
return angular.equals(user, $scope.master);
|
||||
};
|
||||
|
||||
$scope.reset();
|
||||
}
|
||||
</script>
|
||||
</doc:source>
|
||||
</doc:example>
|
||||
|
||||
|
||||
|
||||
# Custom Validation
|
||||
|
||||
Angular provides basic implementation for most common html5 {@link api/angular.module.ng.$compileProvider.directive.input input}
|
||||
types: ({@link api/angular.module.ng.$compileProvider.directive.input.text text}, {@link api/angular.module.ng.$compileProvider.directive.input.number number}, {@link api/angular.module.ng.$compileProvider.directive.input.url url}, {@link api/angular.module.ng.$compileProvider.directive.input.email email}, {@link api/angular.module.ng.$compileProvider.directive.input.radio radio}, {@link api/angular.module.ng.$compileProvider.directive.input.checkbox checkbox}), as well as some directives for validation (`required`, `pattern`, `minlength`, `maxlength`, `min`, `max`).
|
||||
|
||||
Defining your own validator can be done by defining your own directive which adds a custom validation function to the `ng-model` {@link api/angular.module.ng.$compileProvider.directive.ng-model.NgModelController controller}.
|
||||
To get a hold of the controller the directive specifies a dependency as shown in the example below.
|
||||
The validation can occur in two places:
|
||||
|
||||
* **Model to View update** -
|
||||
Whenever the bound model changes, all functions in {@link api/angular.module.ng.$compileProvider.directive.ng-model.NgModelController#$formatters NgModelController#$formatters} array are pipe-lined, so that each of these functions has an opportunity to format the value and change validity state of the form control through {@link api/angular.module.ng.$compileProvider.directive.ng-model.NgModelController#$setValidity NgModelController#$setValidity}.
|
||||
|
||||
* **View to Model update** -
|
||||
In a similar way, whenever a user interacts with a control, the controll calls {@link api/angular.module.ng.$compileProvider.directive.ng-model.NgModelController#$setViewValue NgModelController#$setViewValue}.
|
||||
This in turn pipelines all functions in {@link api/angular.module.ng.$compileProvider.directive.ng-model.NgModelController#$parsers NgModelController#$parsers} array, so that each of these functions has an opportunity to convert the value and change validity state of the form control through {@link api/angular.module.ng.$compileProvider.directive.ng-model.NgModelController#$setValidity NgModelController#$setValidity}.
|
||||
|
||||
In the following example we create two directives.
|
||||
|
||||
* The first one is `integer` and it validates whether the input is a valid integer.
|
||||
For example `1.23` is an invalid value, since it contains a fraction.
|
||||
Note, that we unshift the array instead of pushing.
|
||||
This is because we want to be first parser and consume the control string value, as we need to execute the validation function before a conversion to number occurs.
|
||||
|
||||
* The second directive is a `smart-float`.
|
||||
It parses both `1.2` and `1,2` into a valid float number `1.2`.
|
||||
Note that, we can't use input type `number` here as HTML5 browsers would not allow the user to type what it would consider an invalid number such as `1,2`.
|
||||
|
||||
|
||||
<doc:example module="form-example1">
|
||||
<doc:source>
|
||||
<div ng-controller="Controller">
|
||||
<form name="form" class="css-form" novalidate>
|
||||
<div>
|
||||
Size (integer 0 - 10):
|
||||
<input type="number" ng-model="size" name="size"
|
||||
min="0" max="10" integer />{{size}}<br />
|
||||
<span ng-show="form.size.$error.integer">This is not valid integer!</span>
|
||||
<span ng-show="form.size.$error.min || form.size.$error.max">
|
||||
The value must be in range 0 to 10!</span>
|
||||
</div>
|
||||
|
||||
<div>
|
||||
Length (float):
|
||||
<input type="text" ng-model="length" name="length" smart-float />
|
||||
{{length}}<br />
|
||||
<span ng-show="form.length.$error.float">
|
||||
This is not a valid float number!</span>
|
||||
</div>
|
||||
</form>
|
||||
</div>
|
||||
|
||||
<script type="text/javascript">
|
||||
var app = angular.module('form-example1', []);
|
||||
|
||||
var INTEGER_REGEXP = /^\-?\d*$/;
|
||||
app.directive('integer', function() {
|
||||
return {
|
||||
require: 'ngModel',
|
||||
link: function(scope, elm, attrs, ctrl) {
|
||||
ctrl.$parsers.unshift(function(viewValue) {
|
||||
if (INTEGER_REGEXP.test(viewValue)) {
|
||||
// it is valid
|
||||
ctrl.$setValidity('integer', true);
|
||||
return viewValue;
|
||||
} else {
|
||||
// it is invalid, return undefined (no model update)
|
||||
ctrl.$setValidity('integer', false);
|
||||
return undefined;
|
||||
}
|
||||
});
|
||||
}
|
||||
};
|
||||
});
|
||||
|
||||
var FLOAT_REGEXP = /^\-?\d+((\.|\,)\d+)?$/;
|
||||
app.directive('smartFloat', function() {
|
||||
return {
|
||||
require: 'ngModel',
|
||||
link: function(scope, elm, attrs, ctrl) {
|
||||
ctrl.$parsers.unshift(function(viewValue) {
|
||||
if (FLOAT_REGEXP.test(viewValue)) {
|
||||
ctrl.$setValidity('float', true);
|
||||
return parseFloat(viewValue.replace(',', '.'));
|
||||
} else {
|
||||
ctrl.$setValidity('float', false);
|
||||
return undefined;
|
||||
}
|
||||
});
|
||||
}
|
||||
};
|
||||
});
|
||||
</script>
|
||||
</doc:source>
|
||||
</doc:example>
|
||||
|
||||
|
||||
# Implementing custom form control (using ng-model)
|
||||
Angular implements all of the basic HTML form controls ({@link api/angular.module.ng.$compileProvider.directive.input input}, {@link api/angular.module.ng.$compileProvider.directive.select select}, {@link api/angular.module.ng.$compileProvider.directive.textarea textarea}), which should be sufficient for most cases.
|
||||
However, if you need more flexibility, you can write your own form control as a directive.
|
||||
|
||||
In order for custom control to work with `ng-model` and to achieve two-way data-binding it needs to:
|
||||
|
||||
- implement `render` method, which is responsible for rendering the data after it passed the {@link api/angular.module.ng.$compileProvider.directive.ng-model.NgModelController#$formatters NgModelController#$formatters},
|
||||
- call `$setViewValue` method, whenever the user interacts with the control and model needs to be updated. This is usually done inside a DOM Event listener.
|
||||
|
||||
See {@link api/angular.module.ng.$compileProvider.directive $compileProvider.directive} for more info.
|
||||
|
||||
The following example shows how to add two-way data-binding to contentEditable elements.
|
||||
|
||||
<doc:example module="form-example2">
|
||||
<doc:source>
|
||||
<script type="text/javascript">
|
||||
angular.module('form-example2', []).directive('contenteditable', function() {
|
||||
return {
|
||||
require: 'ngModel',
|
||||
link: function(scope, elm, attrs, ctrl) {
|
||||
// view -> model
|
||||
elm.bind('blur', function() {
|
||||
scope.$apply(function() {
|
||||
ctrl.$setViewValue(elm.html());
|
||||
});
|
||||
});
|
||||
|
||||
// model -> view
|
||||
ctrl.render = function(value) {
|
||||
elm.html(value);
|
||||
};
|
||||
|
||||
// load init value from DOM
|
||||
ctrl.$setViewValue(elm.html());
|
||||
}
|
||||
};
|
||||
});
|
||||
</script>
|
||||
|
||||
<div contentEditable="true" ng-model="content" title="Click to edit">Some</div>
|
||||
<pre>model = {{content}}</pre>
|
||||
|
||||
<style type="text/css">
|
||||
div[contentEditable] {
|
||||
cursor: pointer;
|
||||
background-color: #D0D0D0;
|
||||
}
|
||||
</style>
|
||||
</doc:source>
|
||||
</doc:example>
|
||||
@@ -0,0 +1,124 @@
|
||||
@ngdoc overview
|
||||
@name Developer Guide: i18n and l10n
|
||||
@description
|
||||
|
||||
# I18n and L10n in AngularJS
|
||||
|
||||
**What is i18n and l10n?**
|
||||
|
||||
Internationalization, abbreviated i18n, is the process of developing products in such a way that
|
||||
they can be localized for languages and cultures easily. Localization, abbreviated l10n, is the
|
||||
process of adapting applications and text to enable their usability in a particular cultural or
|
||||
linguistic market. For application developers, internationalizing an application means abstracting
|
||||
all of the strings and other locale-specific bits (such as date or currency formats) out of the
|
||||
application. Localizing an application means providing translations and localized formats for the
|
||||
abstracted bits.
|
||||
|
||||
**What level of support for i18n/l10n is currently in Angular?**
|
||||
|
||||
Currently, Angular supports i18n/l10n for {@link
|
||||
http://docs.angularjs.org/#!/api/angular.module.ng.$filter.date datetime}, {@link
|
||||
http://docs.angularjs.org/#!/api/angular.module.ng.$filter.number number} and {@link
|
||||
http://docs.angularjs.org/#!/api/angular.module.ng.$filter.currency currency} filters.
|
||||
|
||||
Additionally, Angular supports localizable pluralization support provided by the {@link
|
||||
api/angular.module.ng.$compileProvider.directive.ng-pluralize ng-pluralize directive}.
|
||||
|
||||
All localizable Angular components depend on locale-specific rule sets managed by the {@link
|
||||
api/angular.module.ng.$locale $locale service}.
|
||||
|
||||
For readers who want to jump straight into examples, we have a few web pages that showcase how to
|
||||
use Angular filters with various locale rule sets. You can find these examples either on {@link
|
||||
https://github.com/angular/angular.js/tree/master/i18n/e2e Github} or in the i18n/e2e folder of
|
||||
Angular development package.
|
||||
|
||||
**What is a locale id?**
|
||||
|
||||
A locale is a specific geographical, political, or cultural region. The most commonly used locale
|
||||
ID consists of two parts: language code and country code. For example, en-US, en-AU, zh-CN are all
|
||||
valid locale IDs that have both language codes and country codes. Because specifying a country code
|
||||
in locale ID is optional, locale IDs such as en, zh, and sk are also valid. See the {@link
|
||||
http://userguide.icu-project.org/locale ICU } website for more information about using locale IDs.
|
||||
|
||||
**Supported locales in Angular**
|
||||
Angular separates number and datetime format rule sets into different files, each file for a
|
||||
particular locale. You can find a list of currently supported locales {@link
|
||||
https://github.com/angular/angular.js/tree/master/i18n/locale here}
|
||||
# Providing locale rules to Angular
|
||||
|
||||
There are two approaches to providing locale rules to Angular:
|
||||
|
||||
**1. Pre-bundled rule sets**
|
||||
|
||||
You can pre-bundle the desired locale file with Angular by concatenating the content of the
|
||||
locale-specific file to the end of `angular.js` or `angular.min.js` file.
|
||||
|
||||
For example on *nix, to create a an angular.js file that contains localization rules for german
|
||||
locale, you can do the following:
|
||||
|
||||
`cat angular.js i18n/angular-locale_de-ge.js > angular_de-ge.js`
|
||||
|
||||
When the application containing `angular_de-ge.js` script instead of the generic angular.js script
|
||||
starts, Angular is automatically pre-configured with localization rules for the german locale.
|
||||
|
||||
**2. Including locale js script in index.html page**
|
||||
|
||||
You can also include the locale specific js file in the index.html page. For example, if one client
|
||||
requires German locale, you would serve index_de-ge.html which will look something like this:
|
||||
|
||||
<pre>
|
||||
<html ng-app>
|
||||
<head>
|
||||
….
|
||||
<script src="angular.js"></script>
|
||||
<script src="i18n/angular-locale_de-ge.js"></script>
|
||||
….
|
||||
</head>
|
||||
</html>
|
||||
</pre>
|
||||
|
||||
**Comparison of the two approaches**
|
||||
Both approaches described above requires you to prepare different index.html pages or js files for
|
||||
each locale that your app may be localized into. You also need to configure your server to serve
|
||||
the correct file that correspond to the desired locale.
|
||||
|
||||
However, the second approach (Including locale js script in index.html page) is likely to be slower
|
||||
because an extra script needs to be loaded.
|
||||
|
||||
|
||||
# "Gotchas"
|
||||
|
||||
**Currency symbol "gotcha"**
|
||||
|
||||
Angular's {@link http://docs.angularjs.org/#!/api/angular.module.ng.$filter.currency currency filter} allows
|
||||
you to use the default currency symbol from the {@link api/angular.module.ng.$locale locale service},
|
||||
or you can provide the filter with a custom currency symbol. If your app will be used only in one
|
||||
locale, it is fine to rely on the default currency symbol. However, if you anticipate that viewers
|
||||
in other locales might use your app, you should provide your own currency symbol to make sure the
|
||||
actual value is understood.
|
||||
|
||||
For example, if you want to display account balance of 1000 dollars with the following binding
|
||||
containing currency filter: `{{ 1000 | currency }}`, and your app is currently in en-US locale.
|
||||
'$1000.00' will be shown. However, if someone in a different local (say, Japan) views your app, her
|
||||
browser will specify the locale as ja, and the balance of '¥1000.00' will be shown instead. This
|
||||
will really upset your client.
|
||||
|
||||
In this case, you need to override the default currency symbol by providing the {@link
|
||||
http://docs.angularjs.org/#!/api/angular.module.ng.$filter.currency currency filter} with a currency symbol as
|
||||
a parameter when you configure the filter, for example, {{ 1000 | currency:"USD$"}}. This way,
|
||||
Angular will always show a balance of 'USD$1000' and disregard any locale changes.
|
||||
|
||||
**Translation length "gotcha"**
|
||||
|
||||
Keep in mind that translated strings/datetime formats can vary greatly in length. For example,
|
||||
`June 3, 1977` will be translated to Spanish as `3 de junio de 1977`. There are bound to be other
|
||||
more extreme cases. Hence, when internationalizing your apps, you need to apply CSS rules
|
||||
accordingly and do thorough testing to make sure UI components do not overlap.
|
||||
|
||||
|
||||
**Timezones**
|
||||
|
||||
Keep in mind that Angular datetime filter uses the time zone settings of the browser. So the same
|
||||
application will show different time information depending on the time zone settings of the
|
||||
computer that the application is running on. Neither Javascript nor Angular currently supports
|
||||
displaying the date with a timezone specified by the developer.
|
||||
@@ -0,0 +1,42 @@
|
||||
@ngdoc overview
|
||||
@name Developer Guide: Introduction
|
||||
@description
|
||||
|
||||
Angular is pure client-side technology, written entirely in JavaScript. It works with the
|
||||
long-established technologies of the web (HTML, CSS, and JavaScript) to make the development of web
|
||||
apps easier and faster than ever before.
|
||||
|
||||
One important way that angular simplifies web development is by increasing the level of abstraction
|
||||
between the developer and most low-level web app development tasks. Angular automatically takes
|
||||
care of many of these tasks, including:
|
||||
|
||||
* DOM Manipulation
|
||||
* Setting Up Listeners and Notifiers
|
||||
* Input Validation
|
||||
|
||||
Because angular handles much of the work involved in these tasks, developers can concentrate more
|
||||
on application logic and less on repetitive, error-prone, lower-level coding.
|
||||
|
||||
At the same time that angular simplifies the development of web apps, it brings relatively
|
||||
sophisticated techniques to the client-side, including:
|
||||
|
||||
* Separation of data, application logic, and presentation components
|
||||
* Data Binding between data and presentation components
|
||||
* Services (common web app operations, implemented as substitutable objects)
|
||||
* Dependency Injection (used primarily for wiring together services)
|
||||
* An extensible HTML compiler (written entirely in JavaScript)
|
||||
* Ease of Testing
|
||||
|
||||
These techniques have been for the most part absent from the client-side for far too long.
|
||||
|
||||
## Single-page / Round-trip Applications
|
||||
|
||||
You can use angular to develop both single-page and round-trip apps, but angular is designed
|
||||
primarily for developing single-page apps. Angular supports browser history, forward and back
|
||||
buttons, and bookmarking in single-page apps.
|
||||
|
||||
You normally wouldn't want to load angular with every page change, as would be the case with using
|
||||
angular in a round-trip app. However, it would make sense to do so if you were adding a subset of
|
||||
angular's features (for example, templates to leverage angular's data-binding feature) to an
|
||||
existing round-trip app. You might follow this course of action if you were migrating an older app
|
||||
to a single-page angular app.
|
||||
@@ -0,0 +1,24 @@
|
||||
@ngdoc overview
|
||||
@name Developer Guide: About MVC in Angular
|
||||
@description
|
||||
|
||||
While Model-View-Controller (MVC) has acquired different shades of meaning over the years since it
|
||||
first appeared, angular incorporates the basic principles behind the original {@link
|
||||
http://en.wikipedia.org/wiki/Model–view–controller MVC} software design pattern into its way of
|
||||
building client-side web applications.
|
||||
|
||||
The MVC pattern greatly summarized:
|
||||
|
||||
* Separate applications into distinct presentation, data, and logic components
|
||||
* Encourage loose coupling between these components
|
||||
|
||||
Along with {@link dev_guide.services services} and {@link dev_guide.di dependency injection}, MVC
|
||||
makes angular applications better structured, easier to maintain and more testable.
|
||||
|
||||
The following topics explain how angular incorporates the MVC pattern into the angular way of
|
||||
developing web applications:
|
||||
|
||||
* {@link dev_guide.mvc.understanding_model Understanding the Model Component}
|
||||
* {@link dev_guide.mvc.understanding_controller Understanding the Controller Component}
|
||||
* {@link dev_guide.mvc.understanding_view Understanding the View Component}
|
||||
|
||||
@@ -0,0 +1,259 @@
|
||||
@ngdoc overview
|
||||
@name Developer Guide: About MVC in Angular: Understanding the Controller Component
|
||||
@description
|
||||
|
||||
In angular, a controller is a JavaScript function(type/class) that is used to augment instances of
|
||||
angular {@link dev_guide.scopes Scope}, excluding the root scope. When you or angular create a new
|
||||
child scope object via the {@link api/angular.module.ng.$rootScope.Scope#$new scope.$new} API , there is an
|
||||
option to pass in a controller as a method argument. This will tell angular to associate the
|
||||
controller with the new scope and to augment its behavior.
|
||||
|
||||
Use controllers to:
|
||||
|
||||
- Set up the initial state of a scope object.
|
||||
- Add behavior to the scope object.
|
||||
|
||||
# Setting up the initial state of a scope object
|
||||
|
||||
Typically, when you create an application you need to set up an initial state for an angular scope.
|
||||
|
||||
Angular applies (in the sense of JavaScript's `Function#apply`) the controller constructor function
|
||||
to a new angular scope object, which sets up an initial scope state. This means that angular never
|
||||
creates instances of the controller type (by invoking the `new` operator on the controller
|
||||
constructor). Constructors are always applied to an existing scope object.
|
||||
|
||||
You set up the initial state of a scope by creating model properties. For example:
|
||||
|
||||
function GreetingCtrl($scope) {
|
||||
$scope.greeting = 'Hola!';
|
||||
}
|
||||
|
||||
The `GreetingCtrl` controller creates a `greeting` model which can be referred to in a template.
|
||||
|
||||
When a controller function is applied to an angular scope object, the `this` of the controller
|
||||
function becomes the scope of the angular scope object, so any assignment to `this` within the
|
||||
controller function happens on the angular scope object.
|
||||
|
||||
# Adding Behavior to a Scope Object
|
||||
|
||||
Behavior on an angular scope object is in the form of scope method properties available to the
|
||||
template/view. This behavior interacts with and modifies the application model.
|
||||
|
||||
As discussed in the {@link dev_guide.mvc.understanding_model Model} section of this guide, any
|
||||
objects (or primitives) assigned to the scope become model properties. Any functions assigned to
|
||||
the scope, along with any prototype methods of the controller type, become functions available in
|
||||
the template/view, and can be invoked via angular expressions and `ng-` event handlers (e.g. {@link
|
||||
api/angular.module.ng.$compileProvider.directive.ng-click ng-click}). These controller methods are always evaluated within the
|
||||
context of the angular scope object that the controller function was applied to (which means that
|
||||
the `this` keyword of any controller method is always bound to the scope that the controller
|
||||
augments). This is how the second task of adding behavior to the scope is accomplished.
|
||||
|
||||
|
||||
# Using Controllers Correctly
|
||||
|
||||
In general, a controller shouldn't try to do too much. It should contain only the business logic
|
||||
needed for a single view.
|
||||
|
||||
The most common way to keep controllers slim is by encapsulating work that doesn't belong to
|
||||
controllers into services and then using these services in controllers via dependency injection.
|
||||
This is discussed in the {@link dev_guide.di Dependency Injection} {@link dev_guide.services
|
||||
Services} sections of this guide.
|
||||
|
||||
Do not use controllers for:
|
||||
|
||||
- Any kind of DOM manipulation — Controllers should contain only business logic. DOM
|
||||
manipulation—the presentation logic of an application—is well known for being hard to test.
|
||||
Putting any presentation logic into controllers significantly affects testability of the business
|
||||
logic. Angular offers {@link dev_guide.templates.databinding} for automatic DOM manipulation. If
|
||||
you have to perform your own manual DOM manipulation, encapsulate the presentation logic in
|
||||
{@link api/angular.module.ng.$compileProvider.directive directives}.
|
||||
- Input formatting — Use {@link dev_guide.forms angular form controls} instead.
|
||||
- Output filtering — Use {@link dev_guide.templates.filters angular filters} instead.
|
||||
- Run stateless or stateful code shared across controllers — Use {@link dev_guide.services angular
|
||||
services} instead.
|
||||
- Instantiate or manage the life-cycle of other components (for example, to create service
|
||||
instances).
|
||||
|
||||
|
||||
# Associating Controllers with Angular Scope Objects
|
||||
|
||||
You can associate controllers with scope objects explicitly via the {@link api/angular.module.ng.$rootScope.Scope#$new
|
||||
scope.$new} api or implicitly via the {@link api/angular.module.ng.$compileProvider.directive.ng-controller ng-controller
|
||||
directive} or {@link api/angular.module.ng.$route $route service}.
|
||||
|
||||
|
||||
## Controller Constructor and Methods Example
|
||||
|
||||
To illustrate how the controller component works in angular, let's create a little app with the
|
||||
following components:
|
||||
|
||||
- A {@link dev_guide.templates template} with two buttons and a simple message
|
||||
- A model consisting of a string named `spice`
|
||||
- A controller with two functions that set the value of `spice`
|
||||
|
||||
The message in our template contains a binding to the `spice` model, which by default is set to the
|
||||
string "very". Depending on which button is clicked, the `spice` model is set to `chili` or
|
||||
`jalapeño`, and the message is automatically updated by data-binding.
|
||||
|
||||
|
||||
## A Spicy Controller Example
|
||||
|
||||
<pre>
|
||||
<body ng-controller="SpicyCtrl">
|
||||
<button ng-click="chiliSpicy()">Chili</button>
|
||||
<button ng-click="jalapenoSpicy()">Jalapeño</button>
|
||||
<p>The food is {{spice}} spicy!</p>
|
||||
</body>
|
||||
|
||||
function SpicyCtrl($scope) {
|
||||
$scope.spice = 'very';
|
||||
$scope.chiliSpicy = function() {
|
||||
this.spice = 'chili';
|
||||
}
|
||||
}
|
||||
|
||||
SpicyCtrl.prototype.jalapenoSpicy = function() {
|
||||
this.spice = 'jalapeño';
|
||||
}
|
||||
</pre>
|
||||
|
||||
Things to notice in the example above:
|
||||
|
||||
- The `ng-controller` directive is used to (implicitly) create a scope for our template, and the
|
||||
scope is augmented (managed) by the `SpicyCtrl` controller.
|
||||
- `SpicyCtrl` is just a plain JavaScript function. As an (optional) naming convention the name
|
||||
starts with capital letter and ends with "Ctrl" or "Controller".
|
||||
- The JavaScript keyword `this` in the `SpicyCtrl` function is bound to the scope that the
|
||||
controller augments.
|
||||
- Assigning a property to `this` creates or updates the model.
|
||||
- Controller methods can be created through direct assignment to scope (the `chiliSpicy` method) or
|
||||
as prototype methods of the controller constructor function(the `jalapenoSpicy` method)
|
||||
- Both controller methods are available in the template (for the `body` element and and its
|
||||
children).
|
||||
|
||||
Controller methods can also take arguments, as demonstrated in the following variation of the
|
||||
previous example.
|
||||
|
||||
## Controller Method Arguments Example
|
||||
|
||||
<pre>
|
||||
<body ng-controller="SpicyCtrl">
|
||||
<input ng-model="customSpice" value="wasabi">
|
||||
<button ng-click="spicy('chili')">Chili</button>
|
||||
<button ng-click="spicy(customSpice)">Custom spice</button>
|
||||
<p>The food is {{spice}} spicy!</p>
|
||||
</body>
|
||||
|
||||
function SpicyCtrl($scope) {
|
||||
$scope.spice = 'very';
|
||||
$scope.spicy = function(spice) {
|
||||
this.spice = spice;
|
||||
}
|
||||
}
|
||||
</pre>
|
||||
|
||||
Notice that the `SpicyCtrl` controller now defines just one method called `spicy`, which takes one
|
||||
argument called `spice`. The template then refers to this controller method and passes in a string
|
||||
constant `'chili'` in the binding for the first button and a model property `spice` (bound to an
|
||||
input box) in the second button.
|
||||
|
||||
|
||||
## Controller Inheritance Example
|
||||
|
||||
Controller inheritance in angular is based on {@link api/angular.module.ng.$rootScope.Scope Scope} inheritance. Let's
|
||||
have a look at an example:
|
||||
|
||||
<pre>
|
||||
<body ng-controller="MainCtrl">
|
||||
<p>Good {{timeOfDay}}, {{name}}!</p>
|
||||
<div ng-controller="ChildCtrl">
|
||||
<p>Good {{timeOfDay}}, {{name}}!</p>
|
||||
<p ng-controller="BabyCtrl">Good {{timeOfDay}}, {{name}}!</p>
|
||||
</body>
|
||||
|
||||
function MainCtrl($scope) {
|
||||
$scope.timeOfDay = 'morning';
|
||||
$scope.name = 'Nikki';
|
||||
}
|
||||
|
||||
function ChildCtrl($scope) {
|
||||
$scope.name = 'Mattie';
|
||||
}
|
||||
|
||||
function BabyCtrl($scope) {
|
||||
$scope.timeOfDay = 'evening';
|
||||
$scope.name = 'Gingerbreak Baby';
|
||||
}
|
||||
</pre>
|
||||
|
||||
Notice how we nested three `ng-controller` directives in our template. This template construct will
|
||||
result in 4 scopes being created for our view:
|
||||
|
||||
- The root scope
|
||||
- The `MainCtrl` scope, which contains `timeOfDay` and `name` models
|
||||
- The `ChildCtrl` scope, which shadows the `name` model from the previous scope and inherits the
|
||||
`timeOfDay` model
|
||||
- The `BabyCtrl` scope, which shadows both the `timeOfDay` model defined in `MainCtrl` and `name`
|
||||
model defined in the ChildCtrl
|
||||
|
||||
Inheritance works between controllers in the same way as it does with models. So in our previous
|
||||
examples, all of the models could be replaced with controller methods that return string values.
|
||||
|
||||
Note: Standard prototypical inheritance between two controllers doesn't work as one might expect,
|
||||
because as we mentioned earlier, controllers are not instantiated directly by angular, but rather
|
||||
are applied to the scope object.
|
||||
|
||||
|
||||
## Testing Controllers
|
||||
|
||||
The way to test a controller depends upon how complicated the controller is.
|
||||
|
||||
- If your controller doesn't use DI or scope methods — create the controller with the `new`
|
||||
operator and test away. For example:
|
||||
|
||||
Controller Function:
|
||||
<pre>
|
||||
function myController() {
|
||||
this.spices = [{"name":"pasilla", "spiciness":"mild"},
|
||||
{"name":"jalapeno", "spiceiness":"hot hot hot!"},
|
||||
{"name":"habanero", "spiceness":"LAVA HOT!!"}];
|
||||
|
||||
this.spice = "habanero";
|
||||
}
|
||||
</pre>
|
||||
|
||||
Controller Test:
|
||||
<pre>
|
||||
describe('myController function', function() {
|
||||
|
||||
describe('myController', function() {
|
||||
var ctrl;
|
||||
|
||||
beforeEach(function() {
|
||||
ctrl = new myController();
|
||||
});
|
||||
|
||||
it('should create "spices" model with 3 spices', function() {
|
||||
expect(ctrl.spices.length).toBe(3);
|
||||
});
|
||||
|
||||
it('should set the default value of spice', function() {
|
||||
expect(ctrl.spice).toBe('habanero');
|
||||
});
|
||||
});
|
||||
});
|
||||
</pre>
|
||||
|
||||
- If your controller does use DI or scope methods — create a root scope, then create the controller
|
||||
in the root scope with `scope.$new(MyController)`. Test the controller using `$eval`, if necessary.
|
||||
- If you need to test a nested controller that depends on its parent's state — create a root scope,
|
||||
create a parent scope, create a child scope, and test the controller using $eval if necessary.
|
||||
|
||||
|
||||
## Related Topics
|
||||
|
||||
* {@link dev_guide.mvc About MVC in Angular}
|
||||
* {@link dev_guide.mvc.understanding_model Understanding the Model Component}
|
||||
* {@link dev_guide.mvc.understanding_view Understanding the View Component}
|
||||
|
||||
|
||||
@@ -0,0 +1,71 @@
|
||||
@ngdoc overview
|
||||
@name Developer Guide: About MVC in Angular: Understanding the Model Component
|
||||
@description
|
||||
|
||||
Depending on the context of the discussion in angular documentation, the term _model_ can refer to
|
||||
either a single object representing one entity (for example, a model called "phones" with its value
|
||||
being an array of phones) or the entire data model for the application (all entities).
|
||||
|
||||
In angular, a model is any data that is reachable as a property of an angular {@link
|
||||
dev_guide.scopes Scope} object. The name of the property is the model identifier and the value is
|
||||
any JavaScript object (including arrays and primitives).
|
||||
|
||||
The only requirement for a JavaScript object to be a model in angular is that the object must be
|
||||
referenced by an angular scope as a property of that scope object. This property reference can be
|
||||
created explicitly or implicitly.
|
||||
|
||||
You can create models by explicitly creating scope properties referencing JavaScript objects in the
|
||||
following ways:
|
||||
|
||||
* Make a direct property assignment to the scope object in JavaScript code; this most commonly
|
||||
occurs in controllers:
|
||||
|
||||
function MyCtrl($scope) {
|
||||
// create property 'foo' on the MyCtrl's scope
|
||||
// and assign it an initial value 'bar'
|
||||
$scope.foo = 'bar';
|
||||
}
|
||||
|
||||
* Use an {@link dev_guide.expressions angular expression} with an assignment operator in templates:
|
||||
|
||||
<button ng-click="{{foos='ball'}}">Click me</button>
|
||||
|
||||
* Use {@link api/angular.module.ng.$compileProvider.directive.ng-init ng-init directive} in templates (for toy/example apps
|
||||
only, not recommended for real applications):
|
||||
|
||||
<body ng-init=" foo = 'bar' ">
|
||||
|
||||
Angular creates models implicitly (by creating a scope property and assigning it a suitable value)
|
||||
when processing the following template constructs:
|
||||
|
||||
* Form input, select, textarea and other form elements:
|
||||
|
||||
<input ng-model="query" value="fluffy cloud">
|
||||
|
||||
The code above creates a model called "query" on the current scope with the value set to "fluffy
|
||||
cloud".
|
||||
|
||||
* An iterator declaration in {@link api/angular.module.ng.$compileProvider.directive.ng-repeat ng-repeater}:
|
||||
|
||||
<p ng-repeat="phone in phones"></p>
|
||||
|
||||
The code above creates one child scope for each item in the "phones" array and creates a "phone"
|
||||
object (model) on each of these scopes with its value set to the value of "phone" in the array.
|
||||
|
||||
In angular, a JavaScript object stops being a model when:
|
||||
|
||||
* No angular scope contains a property that references the object.
|
||||
|
||||
* All angular scopes that contain a property referencing the object become stale and eligible for
|
||||
garbage collection.
|
||||
|
||||
The following illustration shows a simple data model created implicitly from a simple template:
|
||||
|
||||
<img src="img/guide/about_model_final.png">
|
||||
|
||||
|
||||
## Related Topics
|
||||
|
||||
* {@link dev_guide.mvc About MVC in Angular}
|
||||
* {@link dev_guide.mvc.understanding_controller Understanding the Controller Component}
|
||||
* {@link dev_guide.mvc.understanding_view Understanding the View Component}
|
||||
@@ -0,0 +1,22 @@
|
||||
@ngdoc overview
|
||||
@name Developer Guide: About MVC in Angular: Understanding the View Component
|
||||
@description
|
||||
|
||||
In angular, the view is the DOM loaded and rendered in the browser, after angular has transformed
|
||||
the DOM based on information in the template, controller and model.
|
||||
|
||||
<img src="img/guide/about_view_final.png">
|
||||
|
||||
In the angular implementation of MVC, the view has knowledge of both the model and the controller.
|
||||
The view knows about the model where two-way data-binding occurs. The view has knowledge of the
|
||||
controller through angular directives, such as {@link api/angular.module.ng.$compileProvider.directive.ng-controller
|
||||
ng-controller} and {@link api/angular.module.ng.$compileProvider.directive.ng-view ng-view}, and through bindings of this form:
|
||||
`{{someControllerFunction()}}`. In these ways, the view can call functions in an associated
|
||||
controller function.
|
||||
|
||||
|
||||
## Related Topics
|
||||
|
||||
* {@link dev_guide.mvc About MVC in Angular}
|
||||
* {@link dev_guide.mvc.understanding_model Understanding the Model Component}
|
||||
* {@link dev_guide.mvc.understanding_controller Understanding the Controller Component}
|
||||
@@ -0,0 +1,236 @@
|
||||
@ngdoc overview
|
||||
@name Developer Guide: Overview
|
||||
@description
|
||||
|
||||
|
||||
# What Is Angular?
|
||||
|
||||
The short answer: angular is a new, powerful, client-side technology that makes it much easier for
|
||||
you to create dynamic web sites and complex web apps, all without leaving the comfort of your HTML
|
||||
/ JavaScript home.
|
||||
|
||||
The long answer: it depends on where you're coming from...
|
||||
|
||||
* If you're a web designer, you might perceive angular to be a sweet {@link dev_guide.templates
|
||||
templating} system, that doesn't get in your way and provides you with lots of nice built-ins that
|
||||
make it easier to do what you want to do.
|
||||
|
||||
* If you're a web developer, you might be thrilled that angular functions as an excellent web
|
||||
framework, one that assists you all the way through the development cycle.
|
||||
|
||||
* If you want to go deeper, you can immerse yourself in angular's extensible HTML {@link
|
||||
dev_guide.compiler compiler} that runs in your browser. The angular compiler teaches your browser
|
||||
new tricks.
|
||||
|
||||
Angular is not just a templating system, but you can create fantastic templates with it. Angular is
|
||||
not just a web framework, but it features a very nice framework. Angular is not just an extensible
|
||||
HTML compiler, but the compiler is at the core of Angular. Angular includes all of these
|
||||
components, along with others. Angular is far greater than the sum of its parts. It is a new,
|
||||
better way to develop web applications!
|
||||
|
||||
|
||||
## An Introductory Angular Example
|
||||
|
||||
Let's say that you are a web designer, and you've spent many thous — erm, hundreds of hours
|
||||
designing web sites. But at this point, the thought of manipulating the DOM, writing listeners and
|
||||
input validators, all just to implement a simple form? No. You either don't want to go there in
|
||||
the first place or you've been there and the thrill is gone.
|
||||
|
||||
So look over the following simple example written using angular. Note that it features only the
|
||||
templating aspect of angular, but this should suffice for now to quickly demonstrate how much
|
||||
easier a web developer's life can if they're using angular:
|
||||
|
||||
<doc:example>
|
||||
<doc:source>
|
||||
<script>
|
||||
function InvoiceCntl($scope) {
|
||||
$scope.qty = 1;
|
||||
$scope.cost = 19.95;
|
||||
}
|
||||
</script>
|
||||
<div ng-controller="InvoiceCntl">
|
||||
<b>Invoice:</b>
|
||||
<br />
|
||||
<br />
|
||||
<table>
|
||||
<tr><td> </td><td> </td>
|
||||
<tr><td>Quantity</td><td>Cost</td></tr>
|
||||
<tr>
|
||||
<td><input type="integer" min="0" ng-model="qty" required ></td>
|
||||
<td><input type="number" ng-model="cost" required ></td>
|
||||
</tr>
|
||||
</table>
|
||||
<hr />
|
||||
<b>Total:</b> {{qty * cost | currency}}
|
||||
</div>
|
||||
</doc:source>
|
||||
<!--
|
||||
<doc:scenario>
|
||||
it('should show of angular binding', function() {
|
||||
expect(binding('qty * cost')).toEqual('$19.95');
|
||||
input('qty').enter('2');
|
||||
input('cost').enter('5.00');
|
||||
expect(binding('qty * cost')).toEqual('$10.00');
|
||||
});
|
||||
</doc:scenario>
|
||||
-->
|
||||
</doc:example>
|
||||
|
||||
Try out the Live Preview above, and then let's walk through the example and describe what's going
|
||||
on.
|
||||
|
||||
In the `<html>` tag we specify that this is an angular application with the `ng-app` directive.
|
||||
The `ng-app' will cause the angular to {@link dev_guide.bootstrap auto initialize} your application.
|
||||
|
||||
<html ng-app>
|
||||
|
||||
We load the angular using the `<script>` tag:
|
||||
|
||||
<script src="http://code.angularjs.org/angular-?.?.?.min.js"></script>
|
||||
|
||||
From the `ng-model` attribute of the `<input>` tags, angular automatically sets up two-way data
|
||||
binding, and we also demonstrate some easy input validation:
|
||||
|
||||
Quantity: <input type="integer" min="0" ng-model="qty" required >
|
||||
Cost: <input type="number" ng-model="cost" required >
|
||||
|
||||
These input widgets look normal enough, but consider these points:
|
||||
|
||||
* When this page loaded, angular bound the names of the input widgets (`qty` and `cost`) to
|
||||
variables of the same name. Think of those variables as the "Model" component of the
|
||||
Model-View-Controller design pattern.
|
||||
* Note the angular/HTML widget, {@link api/angular.module.ng.$compileProvider.directive.input input}.
|
||||
You may have noticed that when you enter invalid data
|
||||
or leave the the input fields blank, the borders turn red color, and the display value disappears.
|
||||
These widgets make it easier to implement field validation than coding them in JavaScript,
|
||||
no? Yes.
|
||||
|
||||
And finally, the mysterious `{{ double curly braces }}`:
|
||||
|
||||
Total: {{qty * cost | currency}}
|
||||
|
||||
This notation, `{{ _expression_ }}`, is a bit of built-in angular binding markup, a shortcut for
|
||||
displaying data to the user. The expression within curly braces is monitored and its evaluated value
|
||||
is updated into the view by angular's template compiler. Alternatively, one could use angular's
|
||||
{@link api/angular.module.ng.$compileProvider.directive.ng-bind ng-bind}) directive. The expression
|
||||
itself can be a combination of both an expression and a {@link dev_guide.templates.filters filter}:
|
||||
`{{ expression | filter }}`. Angular provides filters for formatting display data.
|
||||
|
||||
In the example above, the expression in double-curly braces directs angular to, "Bind the data we
|
||||
got from the input widgets to the display, multiply them together, and format the resulting number
|
||||
into output that looks like money."
|
||||
|
||||
|
||||
# The Angular Philosophy
|
||||
|
||||
Angular is built around the belief that declarative code is better than imperative when it comes to
|
||||
building UIs and wiring software components together, while imperative code is excellent for
|
||||
expressing business logic.
|
||||
|
||||
Not to put too fine a point on it, but if you wanted to add a new label to your application, you
|
||||
could do so by simply adding text to the HTML template, saving the code, and refreshing your
|
||||
browser:
|
||||
|
||||
<pre>
|
||||
<span class="label">Hello</span>
|
||||
</pre>
|
||||
|
||||
Or, as in programmatic systems (like {@link http://code.google.com/webtoolkit/ GWT}), you would
|
||||
have to write the code and then run the code like this:
|
||||
|
||||
<pre>
|
||||
var label = new Label();
|
||||
label.setText('Hello');
|
||||
label.setClass('label');
|
||||
parent.addChild(label);
|
||||
</pre>
|
||||
|
||||
That's one line of markup versus four times as much code.
|
||||
|
||||
|
||||
## More Angular Philosophy
|
||||
|
||||
* It is a very good idea to decouple DOM manipulation from app logic. This dramatically improves
|
||||
the testability of the code.
|
||||
* It is a really, _really_ good idea to regard app testing as equal in importance to app writing.
|
||||
Testing difficulty is dramatically affected by the way the code is structured.
|
||||
* It is an excellent idea to decouple the client side of an app from the server side. This allows
|
||||
development work to progress in parallel, and allows for reuse of both sides.
|
||||
* It is very helpful indeed if the framework guides developers through the entire journey of
|
||||
building an app: from designing the UI, through writing the business logic, to testing.
|
||||
* It is always good to make common tasks trivial and difficult tasks possible.
|
||||
|
||||
Now that we're homing in on what angular is, perhaps now would be a good time to list a few things
|
||||
that angular is not:
|
||||
|
||||
* It's not a Library. You don't just call its functions, although it does provide you with some
|
||||
utility APIs.
|
||||
* It's not a DOM Manipulation Library. Angular uses jQuery to manipulate the DOM behind the scenes,
|
||||
rather than give you functions to manipulate the DOM yourself.
|
||||
* It's not a Widget Library. There are lots of existing widget libraries that you can integrate
|
||||
with angular.
|
||||
* It's not "Just Another Templating System". A part of angular is a templating system. The
|
||||
templating subsystem of angular is different from the traditional approach for these reasons:
|
||||
* It Uses HTML/CSS syntax: This makes it easy to read and can be edited with existing HTML/CSS
|
||||
authoring tools.
|
||||
* It Extends HTML vocabulary: Angular allows you to create new HTML tags, which expand into
|
||||
dynamic UI components.
|
||||
* It Executes in the browser: Removes the round trip to the server for many operations and
|
||||
creates instant feedback for users as well as developers.
|
||||
* It Has Bidirectional data binding: The model is the single source of truth. Programmatic
|
||||
changes to the model are automatically reflected in the view. Any changes by the user to the view
|
||||
are automatically reflected in the model.
|
||||
|
||||
|
||||
# Why You Want Angular
|
||||
|
||||
Angular frees you from the following pain:
|
||||
|
||||
* **Registering callbacks:** Registering callbacks clutters your code, making it hard to see the
|
||||
forest for the trees. Removing common boilerplate code such as callbacks is a good thing. It vastly
|
||||
reduces the amount of JavaScript coding _you_ have to do, and it makes it easier to see what your
|
||||
application does.
|
||||
* **Manipulating HTML DOM programatically:** Manipulating HTML DOM is a cornerstone of AJAX
|
||||
applications, but it's cumbersome and error-prone. By declaratively describing how the UI should
|
||||
change as your application state changes, you are freed from low level DOM manipulation tasks. Most
|
||||
applications written with angular never have to programatically manipulate the DOM, although you
|
||||
can if you want to.
|
||||
* **Marshaling data to and from the UI:** CRUD operations make up the majority of AJAX
|
||||
applications. The flow of marshaling data from the server to an internal object to an HTML form,
|
||||
allowing users to modify the form, validating the form, displaying validation errors, returning to
|
||||
an internal model, and then back to the server, creates a lot of boilerplate code. Angular
|
||||
eliminates almost all of this boilerplate, leaving code that describes the overall flow of the
|
||||
application rather than all of the implementation details.
|
||||
* **Writing tons of initialization code just to get started:** Typically you need to write a lot of
|
||||
plumbing just to get a basic "Hello World" AJAX app working. With angular you can bootstrap your
|
||||
app easily using services, which are auto-injected into your application in a {@link
|
||||
http://code.google.com/p/google-guice/ Guice}-like dependency-injection style. This allows you to
|
||||
get started developing features quickly. As a bonus, you get full control over the initialization
|
||||
process in automated tests.
|
||||
|
||||
|
||||
# Watch a Presentation About Angular
|
||||
|
||||
Here is an early presentation on angular, but note that substantial development has occurred since
|
||||
the talk was given in July of 2010.
|
||||
|
||||
<object width="480" height="385">
|
||||
<param name="movie" value="http://www.youtube.com/v/elvcgVSynRg&hl=en_US&fs=1"></param>
|
||||
<param name="allowFullScreen" value="true"></param>
|
||||
<param name="allowscriptaccess" value="always"></param>
|
||||
<embed src="http://www.youtube.com/v/elvcgVSynRg&hl=en_US&fs=1"
|
||||
type="application/x-shockwave-flash" allowscriptaccess="always"
|
||||
allowfullscreen="true" width="480" height="385"></embed>
|
||||
</object>
|
||||
|
||||
{@link
|
||||
|
||||
https://docs.google.com/present/edit?id=0Abz6S2TvsDWSZDQ0OWdjaF8yNTRnODczazdmZg&hl=en&authkey=CO-b7oID
|
||||
|
||||
Presentation}
|
||||
|
|
||||
{@link
|
||||
|
||||
https://docs.google.com/document/edit?id=1ZHVhqC0apbzPRQcgnb1Ye-bAUbNJ-IlFMyPBPCZ2cYU&hl=en&authkey=CInnwLYO
|
||||
|
||||
Source}
|
||||
@@ -0,0 +1,230 @@
|
||||
@ngdoc overview
|
||||
@name Developer Guide: Scopes: Scope Internals
|
||||
@description
|
||||
|
||||
## What is a scope?
|
||||
|
||||
A scope is an execution context for {@link dev_guide.expressions expressions}. You can think of a
|
||||
scope as a JavaScript object that has an extra set of APIs for registering change listeners and for
|
||||
managing its own life cycle. In Angular's implementation of the model-view-controller design
|
||||
pattern, a scope's properties comprise both the model and the controller methods.
|
||||
|
||||
|
||||
### Scope characteristics
|
||||
- Scopes provide APIs ({@link api/angular.module.ng.$rootScope.Scope#$watch $watch}) to observe model mutations.
|
||||
- Scopes provide APIs ({@link api/angular.module.ng.$rootScope.Scope#$apply $apply}) to propagate any model changes
|
||||
through the system into the view from outside of the "Angular realm" (controllers, services,
|
||||
Angular event handlers).
|
||||
- Scopes can be nested to isolate application components while providing access to shared model
|
||||
properties. A scope (prototypically) inherits properties from its parent scope.
|
||||
- In some parts of the system (such as controllers, services and directives), the scope is made
|
||||
available as `this` within the given context. (Note: This api will change before 1.0 is released.)
|
||||
|
||||
|
||||
### Root scope
|
||||
|
||||
Every application has a root scope, which is the ancestor of all other scopes.
|
||||
|
||||
### What is scope used for?
|
||||
|
||||
{@link dev_guide.expressions Expressions} in the view are {@link api/angular.module.ng.$rootScope.Scope#$eval evaluated}
|
||||
against the current scope. When HTML DOM elements are attached to a scope, expressions in those
|
||||
elements are evaluated against the attached scope.
|
||||
|
||||
There are two kinds of expressions:
|
||||
|
||||
- Binding expressions, which are observations of property changes. Property changes are reflected
|
||||
in the view during the {@link api/angular.module.ng.$rootScope.Scope#$digest digest cycle}.
|
||||
- Action expressions, which are expressions with side effects. Typically, the side effects cause
|
||||
execution of a method in a controller in response to a user action, such as clicking on a button.
|
||||
|
||||
|
||||
### Scope inheritance
|
||||
|
||||
A scope (prototypically) inherits properties from its parent scope. Since a given property may not
|
||||
reside on a child scope, if a property read does not find the property on a scope, the read will
|
||||
recursively check the parent scope, grandparent scope, etc. all the way to the root scope before
|
||||
defaulting to undefined.
|
||||
|
||||
{@link api/angular.module.ng.$compileProvider.directive directives} associated with elements
|
||||
(ng-controller, ng-repeat, ng-include, etc.) create new child scopes that inherit properties from
|
||||
the current parent scope. Any code in Angular is free to create a new scope. Whether or not your
|
||||
code does so is an implementation detail of the directive, that is, you can decide when or if this
|
||||
happens. Inheritance typically mimics HTML DOM element nesting, but does not do so with the same
|
||||
granularity.
|
||||
|
||||
A property write will always write to the current scope. This means that a write can hide a parent
|
||||
property within the scope it writes to, as shown in the following example.
|
||||
|
||||
<pre>
|
||||
it('should inherit properties', inject(function($rootScope)) {
|
||||
var root = $rootScope;
|
||||
var child = root.$new();
|
||||
|
||||
root.name = 'angular';
|
||||
expect(child.name).toEqual('angular');
|
||||
expect(root.name).toEqual('angular');
|
||||
|
||||
child.name = 'super-heroic framework';
|
||||
expect(child.name).toEqual('super-heroic framework');
|
||||
expect(root.name).toEqual('angular');
|
||||
});
|
||||
</pre>
|
||||
|
||||
|
||||
### Scope life cycle
|
||||
1. **Creation**
|
||||
|
||||
* The root scope is created by the {@link api/angular.module.ng.$rootScope $rootScope} service.
|
||||
* To create a child scopes, you should call {@link api/angular.module.ng.$rootScope.Scope#$new parentScope.$new()}.
|
||||
|
||||
2. **Watcher registration**
|
||||
|
||||
Watcher registration can happen at any time and on any scope (root or child) via {@link
|
||||
api/angular.module.ng.$rootScope.Scope#$watch scope.$watch()} API.
|
||||
|
||||
3. **Model mutation**
|
||||
|
||||
For mutations to be properly observed, you should make them only within the execution of the
|
||||
function passed into {@link api/angular.module.ng.$rootScope.Scope#$apply scope.$apply()} call. (Angular apis do this
|
||||
implicitly, so no extra `$apply` call is needed when doing synchronous work in controllers, or
|
||||
asynchronous work with {@link api/angular.module.ng.$http $http} or {@link api/angular.module.ng.$defer
|
||||
$defer} services.
|
||||
|
||||
4. **Mutation observation**
|
||||
|
||||
At the end of each `$apply` call {@link api/angular.module.ng.$rootScope.Scope#$digest $digest} cycle is started on
|
||||
the root scope, which then propagates throughout all child scopes.
|
||||
|
||||
During the `$digest` cycle, all `$watch-ers` expressions or functions are checked for model
|
||||
mutation and if a mutation is detected, the `$watch-er` listener is called.
|
||||
|
||||
5. **Scope destruction**
|
||||
|
||||
When child scopes are no longer needed, it is the responsibility of the child scope creator to
|
||||
destroy them via {@link api/angular.module.ng.$rootScope.Scope#$destroy scope.$destroy()} API. This will stop
|
||||
propagation of `$digest` calls into the child scope and allow for memory used by the child scope
|
||||
models to be reclaimed by the garbage collector.
|
||||
|
||||
The root scope can't be destroyed via the `$destroy` API. Instead, it is enough to remove all
|
||||
references from your application to the scope object and garbage collector will do its magic.
|
||||
## Scopes in Angular applications
|
||||
To understand how Angular applications work, you need to understand how scopes work within an
|
||||
application. This section describes the typical life cycle of an application so you can see how
|
||||
scopes come into play throughout and get a sense of their interactions.
|
||||
### How scopes interact in applications
|
||||
|
||||
1. At application compile time, a root scope is created and is attached to the root `<HTML>` DOM
|
||||
element.
|
||||
2. During the compilation phase, the {@link dev_guide.compiler compiler} matches {@link
|
||||
api/angular.module.ng.$compileProvider.directive directives} against the DOM template. The directives
|
||||
usually fall into one of two categories:
|
||||
- Observing {@link api/angular.module.ng.$compileProvider.directive directives}, such as double-curly
|
||||
expressions `{{expression}}`, register listeners using the {@link
|
||||
api/angular.module.ng.$rootScope.Scope#$watch $watch()} method. This type of directive needs to
|
||||
be notified whenever the expression changes so that it can update the view.
|
||||
- Listener directives, such as {@link api/angular.module.ng.$compileProvider.directive.ng-click
|
||||
ng-click}, register a listener with the DOM. When the DOM listener fires, the directive executes
|
||||
the associated expression and updates the view using the {@link
|
||||
api/angular.module.ng.$rootScope.Scope#$apply $apply()} method.
|
||||
3. When an external event (such as a user action, timer or XHR) is received, the associated {@link
|
||||
dev_guide.expressions expression} must be applied to the scope through the {@link
|
||||
api/angular.module.ng.$rootScope.Scope#$apply $apply()} method so that all listeners are updated correctly.
|
||||
|
||||
|
||||
### Directives that create scopes
|
||||
In most cases, {@link api/angular.module.ng.$compileProvider.directive directives} and scopes interact but do not create new
|
||||
instances of scope. However, some directives, such as {@link api/angular.module.ng.$compileProvider.directive.ng-controller
|
||||
ng-controller} and {@link api/angular.module.ng.$compileProvider.directive.ng-repeat ng-repeat}, create new child scopes using
|
||||
the {@link api/angular.module.ng.$rootScope.Scope#$new $new()} method and then attach the child scope to the
|
||||
corresponding DOM element. You can retrieve a scope for any DOM element by using an
|
||||
`angular.element(aDomElement).scope()` method call.)
|
||||
|
||||
|
||||
### Controllers and scopes
|
||||
Scopes and controllers interact with each other in the following situations:
|
||||
- Controllers use scopes to expose controller methods to templates (see {@link
|
||||
api/angular.module.ng.$compileProvider.directive.ng-controller ng-controller}).
|
||||
- Controllers define methods (behavior) that can mutate the model (properties on the scope).
|
||||
- Controllers may register {@link api/angular.module.ng.$rootScope.Scope#$watch watches} on the model. These watches
|
||||
execute immediately after the controller behavior executes, but before the DOM gets updated.
|
||||
|
||||
See the {@link dev_guide.mvc.understanding_controller controller docs} for more information.
|
||||
|
||||
### Updating scope properties
|
||||
You can update a scope by calling its {@link api/angular.module.ng.$rootScope.Scope#$apply $apply()} method with an
|
||||
expression or a function as the function argument. However it is typically not necessary to do this
|
||||
explicitly. In most cases, angular intercepts all external events (such as user interactions, XHRs,
|
||||
and timers) and wraps their callbacks into the `$apply()` method call on the scope object for you
|
||||
at the right time. The only time you might need to call `$apply()` explicitly is when you create
|
||||
your own custom asynchronous widget or service.
|
||||
|
||||
The reason it is unnecessary to call `$apply()` from within your controller functions when you use
|
||||
built-in angular widgets and services is because your controllers are typically called from within
|
||||
an `$apply()` call already.
|
||||
|
||||
When a user inputs data, angularized widgets invoke `$apply()` on the current scope and evaluate an
|
||||
angular expression or execute a function on this scope. Afterwards `$apply` will trigger `$digest`
|
||||
call on the root scope, to propagate your changes through the entire system, which results in
|
||||
$watch-ers firing and view getting updated. Similarly, when a request to fetch data from a server
|
||||
is made and the response comes back, the data is written into the model (scope) within an $apply,
|
||||
which then pushes updates through to the view and any other dependents.
|
||||
|
||||
A widget that creates scopes (such as {@link api/angular.module.ng.$compileProvider.directive.ng-repeat ng-repeat}) via `$new`,
|
||||
doesn't need to worry about propagating the `$digest` call from the parent scope to child scopes.
|
||||
This happens automatically.
|
||||
|
||||
## Scopes in unit-testing
|
||||
You can create scopes, including the root scope, in tests by having the $rootScope injected into
|
||||
your spec. This allows you to mimic the run-time environment and have full control over
|
||||
the life cycle of the scope so that you can assert correct model transitions. Since these scopes
|
||||
are created outside the normal compilation process, their life cycles must be managed by the test.
|
||||
|
||||
### Using scopes in unit-testing
|
||||
The following example demonstrates how the scope life cycle needs to be manually triggered from
|
||||
within the unit-tests.
|
||||
|
||||
<pre>
|
||||
// example of a test
|
||||
it('should trigger a watcher', inject(function($rootScope) {
|
||||
var scope = $rootScope;
|
||||
scope.$watch('name', function(name) {
|
||||
scope.greeting = 'Hello ' + name + '!';
|
||||
});
|
||||
|
||||
scope.name = 'angular';
|
||||
// The watch does not fire yet since we have to manually trigger the digest phase.
|
||||
expect(scope.greeting).toEqual(undefined);
|
||||
|
||||
// manually trigger digest phase from the test
|
||||
scope.$digest();
|
||||
expect(scope.greeting).toEqual('Hello Angular!');
|
||||
}
|
||||
</pre>
|
||||
|
||||
|
||||
### Dependency injection in Tests
|
||||
|
||||
When you find it necessary to inject your own mocks in your tests, use a scope to override the
|
||||
service instances, as shown in the following example.
|
||||
|
||||
<pre>
|
||||
it('should allow override of providers', inject(
|
||||
function($provide) {
|
||||
$provide.value('$location', {mode:'I am a mock'});
|
||||
},
|
||||
function($location){
|
||||
expect($location.mode).toBe('I am a mock');
|
||||
}
|
||||
)};
|
||||
</pre>
|
||||
|
||||
## Related Topics
|
||||
|
||||
* {@link dev_guide.scopes Angular Scope Objects}
|
||||
* {@link dev_guide.scopes.understanding_scopes Understanding Scopes}
|
||||
|
||||
## Related API
|
||||
|
||||
* {@link api/angular.module.ng.$rootScope.Scope Angular Scope API}
|
||||
|
||||
@@ -0,0 +1,35 @@
|
||||
@ngdoc overview
|
||||
@name Developer Guide: Scopes
|
||||
@description
|
||||
|
||||
|
||||
An Angular scope is a JavaScript object with additional APIs useful for watching property changes,
|
||||
Angular scope is the model in Model-View-Controller paradigm. Instances of scope serve as the
|
||||
context within which all {@link dev_guide.expressions expressions} get evaluated.
|
||||
|
||||
You can think of Angular scope objects as the medium through which the model, view, and controller
|
||||
communicate. Scopes are linked during the compilation process with the view. This linkage provides
|
||||
the contexts in which Angular creates data-bindings between the model and the view.
|
||||
|
||||
In addition to providing the context in which data is evaluated, Angular scope objects watch for
|
||||
model changes. The scope objects also notify all components interested in any model changes (for
|
||||
example, functions registered through {@link api/angular.module.ng.$rootScope.Scope#$watch $watch}, bindings created by
|
||||
{@link api/angular.module.ng.$compileProvider.directive.ng-bind ng-bind}, or HTML input elements).
|
||||
|
||||
Angular scope objects:
|
||||
|
||||
* Link the model, controller and view template together.
|
||||
* Provide the mechanism to watch for model changes ({@link api/angular.module.ng.$rootScope.Scope#$watch $watch}).
|
||||
* Apply model changes to the system ({@link api/angular.module.ng.$rootScope.Scope#$apply $apply}).
|
||||
* Provide the context in which expressions are evaluated ({@link api/angular.module.ng.$rootScope.Scope#$eval $eval}).
|
||||
|
||||
|
||||
## Related Topics
|
||||
|
||||
* {@link dev_guide.scopes.understanding_scopes Understanding Scopes}
|
||||
* {@link dev_guide.scopes.internals Scopes Internals}
|
||||
|
||||
## Related API
|
||||
|
||||
* {@link api/angular.module.ng.$rootScope.Scope Angular Scope API}
|
||||
|
||||
@@ -0,0 +1,66 @@
|
||||
@ngdoc overview
|
||||
@name Developer Guide: Scopes: Understanding Scopes
|
||||
@description
|
||||
|
||||
Angular automatically creates a root scope during initialization, and attaches it to the page's
|
||||
root DOM element (usually `<html>`). The root scope object, along with any of its child scope
|
||||
objects, serves as the infrastructure on which your data model is built. The data model (JavaScript
|
||||
objects, arrays, or primitives) is attached to angular scope properties. Angular binds the property
|
||||
values to the DOM where bindings are specified in the template. Angular attaches any controller
|
||||
functions you have created to their respective scope objects.
|
||||
|
||||
<img src="img/guide/simple_scope_final.png">
|
||||
|
||||
Angular scopes can be nested, so a child scope has a parent scope upstream in the DOM. When you
|
||||
display an angular expression in the view, angular walks the DOM tree looking in the closest
|
||||
attached scope object for the specified data. If it doesn't find the data in the closest attached
|
||||
scope, it looks further up the scope hierarchy until it finds the data.
|
||||
|
||||
A child scope object inherits properties from its parents. For example, in the following snippet of
|
||||
code, observe how the value of `name` changes, based on the HTML element it is displayed in:
|
||||
|
||||
<doc:example>
|
||||
<doc:source>
|
||||
<ul ng-init="name='Hank'; names=['Igor', 'Misko', 'Gail', 'Kai']">
|
||||
<li ng-repeat="name in names">
|
||||
Name = {{name}}!
|
||||
</li>
|
||||
</ul>
|
||||
<pre>Name={{name}}</pre>
|
||||
</doc:source>
|
||||
<doc:scenario>
|
||||
it('should override the name property', function() {
|
||||
expect(using('.doc-example-live').repeater('li').row(0)).
|
||||
toEqual(['Igor']);
|
||||
expect(using('.doc-example-live').repeater('li').row(1)).
|
||||
toEqual(['Misko']);
|
||||
|
||||
expect(using('.doc-example-live').repeater('li').row(2)).
|
||||
toEqual(['Gail']);
|
||||
expect(using('.doc-example-live').repeater('li').row(3)).
|
||||
toEqual(['Kai']);
|
||||
expect(using('.doc-example-live').element('pre').text()).
|
||||
toBe('Name=Hank');
|
||||
});
|
||||
</doc:scenario>
|
||||
</doc:example>
|
||||
|
||||
The angular {@link api/angular.module.ng.$compileProvider.directive.ng-repeat ng-repeat} directive creates a new scope for each
|
||||
element that it repeats (in this example the elements are list items). In the `<ul>` element, we
|
||||
initialized `name` to "Hank", and we created an array called `names` to use as the data source for
|
||||
the list items. In each `<li>` element, `name` is overridden. Outside of the `<li>` repeater, the
|
||||
original value of `name` is displayed.
|
||||
|
||||
The following illustration shows the DOM and angular scopes for the example above:
|
||||
|
||||
<img src="img/guide/dom_scope_final.png">
|
||||
|
||||
|
||||
## Related Topics
|
||||
|
||||
* {@link dev_guide.scopes Angular Scope Objects}
|
||||
* {@link dev_guide.scopes.internals Scopes Internals}
|
||||
|
||||
## Related API
|
||||
|
||||
* {@link api/angular.module.ng.$rootScope.Scope Angular Scope API}
|
||||
@@ -0,0 +1,636 @@
|
||||
@ngdoc overview
|
||||
@name Developer Guide: Angular Services: Using $location
|
||||
@description
|
||||
|
||||
# What does it do?
|
||||
|
||||
The `$location` service parses the URL in the browser address bar (based on the {@link
|
||||
https://developer.mozilla.org/en/window.location window.location}) and makes the URL available to
|
||||
your application. Changes to the URL in the address bar are reflected into $location service and
|
||||
changes to $location are reflected into the browser address bar.
|
||||
|
||||
**The $location service:**
|
||||
|
||||
- Exposes the current URL in the browser address bar, so you can
|
||||
- Watch and observe the URL.
|
||||
- Change the URL.
|
||||
- Synchronizes the URL with the browser when the user
|
||||
- Changes the address bar.
|
||||
- Clicks the back or forward button (or clicks a History link).
|
||||
- Clicks on a link.
|
||||
- Represents the URL object as a set of methods (protocol, host, port, path, search, hash).
|
||||
|
||||
|
||||
## Comparing $location to window.location
|
||||
|
||||
<table>
|
||||
<thead>
|
||||
|
||||
<tr>
|
||||
<td class="empty-corner-lt"></td>
|
||||
<td>window.location</td>
|
||||
<td>$location service</td>
|
||||
</tr>
|
||||
|
||||
</thead>
|
||||
<tbody>
|
||||
|
||||
<tr>
|
||||
<td class="head">purpose</td>
|
||||
<td>allow read/write access to the current browser location</td>
|
||||
<td>same</td>
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
<td class="head">API</td>
|
||||
<td>exposes "raw" object with properties that can be directly modified</td>
|
||||
<td>exposes jQuery-style getters and setters</td>
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
<td class="head">integration with angular application life-cycle</td>
|
||||
<td>none</td>
|
||||
<td>knows about all internal life-cycle phases, integrates with $watch, ...</td>
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
<td class="head">seamless integration with HTML5 API</td>
|
||||
<td>no</td>
|
||||
<td>yes (with a fallback for legacy browsers)</td>
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
<td class="head">aware of docroot/context from which the application is loaded</td>
|
||||
<td>no - window.location.path returns "/docroot/actual/path"</td>
|
||||
<td>yes - $location.path() returns "/actual/path"</td>
|
||||
</tr>
|
||||
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
## When should I use $location?
|
||||
Any time your application needs to react to a change in the current URL or if you want to change
|
||||
the current URL in the browser.
|
||||
|
||||
## What does it not do?
|
||||
Does not cause a full page reload when the browser URL is changed. To reload the page after
|
||||
changing the URL, use the lower-level API, `$window.location.href`.
|
||||
|
||||
|
||||
# General overview of the API
|
||||
|
||||
The `$location` service can behave differently, depending on the configuration that was provided to
|
||||
it when it was instantiated. The default configuration is suitable for many applications, for
|
||||
others customizing the configuration can enable new features.
|
||||
|
||||
Once the `$location` service is instantiated, you can interact with it via jQuery-style getter and
|
||||
setter methods that allow you to get or change the current URL in the browser.
|
||||
|
||||
## $location service configuration
|
||||
|
||||
To configure the `$location` service, retrieve the
|
||||
{@link api/angular.module.ng.$locationProvider $locationProvider} and set the parameters as follows:
|
||||
|
||||
|
||||
- **html5Mode(mode)**: {boolean}<br />
|
||||
`true` - see HTML5 mode<br />
|
||||
`false` - see Hashbang mode<br />
|
||||
default: `false`
|
||||
|
||||
- **hashPrefix(prefix)**: {string}<br />
|
||||
prefix used for Hashbang URLs (used in Hashbang mode or in legacy browser in Html5 mode)<br />
|
||||
default: `'!'`
|
||||
|
||||
### Example configuration
|
||||
<pre>
|
||||
$locationProvider.html5Mode(true).hashPrefix('!');
|
||||
</pre>
|
||||
|
||||
## Getter and setter methods
|
||||
|
||||
`$location` service provides getter methods for read-only parts of the URL (absUrl, protocol, host,
|
||||
port) and getter / setter methods for url, path, search, hash:
|
||||
<pre>
|
||||
// get the current path
|
||||
$location.path();
|
||||
|
||||
// change the path
|
||||
$location.path('/newValue')
|
||||
</pre>
|
||||
|
||||
All of the setter methods return the same `$location` object to allow chaining. For example, to
|
||||
change multiple segments in one go, chain setters like this:
|
||||
<pre>$location.path('/newValue').search({key: value});</pre>
|
||||
|
||||
There is a special `replace` method which can be used to tell the $location service that the next
|
||||
time the $location service is synced with the browser, the last history record should be replaced
|
||||
instead of creating a new one. This is useful when you want to implement redirection, which would
|
||||
otherwise break the back button (navigating back would retrigger the redirection). To change the
|
||||
current URL without creating a new browser history record you can call:
|
||||
<pre>
|
||||
$location.path('/someNewPath');
|
||||
$location.replace();
|
||||
// or you can chain these as: $location.path('/someNewPath').replace();
|
||||
</pre>
|
||||
|
||||
Note that the setters don't update `window.location` immediately. Instead, `$location` service is
|
||||
aware of the {@link api/angular.module.ng.$rootScope.Scope scope} life-cycle and coalesces multiple `$location`
|
||||
mutations into one "commit" to the `window.location` object during the scope `$digest` phase. Since
|
||||
multiple changes to the $location's state will be pushed to the browser as a single change, it's
|
||||
enough to call the `replace()` method just once to make the entire "commit" a replace operation
|
||||
rather than addition to the browser history. Once the browser is updated, the $location service
|
||||
resets the flag set by `replace()` method and future mutations will create new history records,
|
||||
unless `replace()` is called again.
|
||||
|
||||
### Setters and character encoding
|
||||
You can pass special characters to `$location` service and it will encode them according to rules
|
||||
specified in {@link http://www.ietf.org/rfc/rfc3986.txt RFC 3986}. When you access the methods:
|
||||
|
||||
- All values that are passed to `$location` setter methods, `path()`, `search()`, `hash()`, are
|
||||
encoded.
|
||||
- Getters (calls to methods without parameters) return decoded values for the following methods
|
||||
`path()`, `search()`, `hash()`.
|
||||
- When you call the `absUrl()` method, the returned value is a full url with its segments encoded.
|
||||
- When you call the `url()` method, the returned value is path, search and hash, in the form
|
||||
`/path?search=a&b=c#hash`. The segments are encoded as well.
|
||||
|
||||
|
||||
# Hashbang and HTML5 Modes
|
||||
|
||||
`$location` service has two configuration modes which control the format of the URL in the browser
|
||||
address bar: **Hashbang mode** (the default) and the **HTML5 mode** which is based on using the
|
||||
HTML5 {@link http://www.w3.org/TR/html5/history.html History API}. Applications use the same API in
|
||||
both modes and the `$location` service will work with appropriate URL segments and browser APIs to
|
||||
facilitate the browser URL change and history management.
|
||||
|
||||
<img src="img/guide/hashbang_vs_regular_url.jpg">
|
||||
|
||||
<table>
|
||||
<thead>
|
||||
|
||||
<tr>
|
||||
<td class="empty-corner-lt"></td>
|
||||
<td>Hashbang mode</td>
|
||||
<td>HTML5 mode</td>
|
||||
</tr>
|
||||
|
||||
</thead>
|
||||
<tbody>
|
||||
|
||||
<tr>
|
||||
<td class="head">configuration</td>
|
||||
<td>the default</td>
|
||||
<td>{ html5Mode: true }</td>
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
<td class="head">URL format</td>
|
||||
<td>hashbang URLs in all browsers</td>
|
||||
<td>regular URLs in modern browser, hashbang URLs in old browser</td>
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
<td class="head"><a href=""> link rewriting</td>
|
||||
<td>no</td>
|
||||
<td>yes</td>
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
<td class="head">requires server-side configuration</td>
|
||||
<td>no</td>
|
||||
<td>yes</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
## Hashbang mode (default mode)
|
||||
|
||||
In this mode, `$location` uses Hashbang URLs in all browsers.
|
||||
|
||||
### Example
|
||||
|
||||
<pre>
|
||||
it('should show example', inject(
|
||||
function($locationProvider) {
|
||||
$locationProvider.html5mode = false;
|
||||
$locationProvider.hashPrefix = '!';
|
||||
},
|
||||
function($location) {
|
||||
// open http://host.com/base/index.html#!/a
|
||||
$location.absUrl() == 'http://host.com/base/index.html#!/a'
|
||||
$location.path() == '/a'
|
||||
|
||||
$location.path('/foo')
|
||||
$location.absUrl() == 'http://host.com/base/index.html#!/foo'
|
||||
|
||||
$location.search() == {}
|
||||
$location.search({a: 'b', c: true});
|
||||
$location.absUrl() == 'http://host.com/base/index.html#!/foo?a=b&c'
|
||||
|
||||
$location.path('/new').search('x=y');
|
||||
$location.absUrl() == 'http://host.com/base/index.html#!/new?x=y'
|
||||
}
|
||||
));
|
||||
</pre>
|
||||
|
||||
### Crawling your app
|
||||
|
||||
To allow indexing of your AJAX application, you have to add special meta tag in the head section of
|
||||
your document:
|
||||
<pre><meta name="fragment" content="!" /></pre>
|
||||
|
||||
This will cause crawler bot to request links with `_escaped_fragment_` param so that your server
|
||||
can recognize the crawler and serve a HTML snapshots. For more information about this technique,
|
||||
see {@link http://code.google.com/web/ajaxcrawling/docs/specification.html Making AJAX Applications
|
||||
Crawlable}.
|
||||
|
||||
## HTML5 mode
|
||||
|
||||
In HTML5 mode, the `$location` service getters and setters interact with the browser URL address
|
||||
through the HTML5 history API, which allows for use of regular URL path and search segments,
|
||||
instead of their hashbang equivalents. If the HTML5 History API is not supported by a browser, the
|
||||
`$location` service will fall back to using the hashbang URLs automatically. This frees you from
|
||||
having to worry about whether the browser displaying your app supports the history API or not; the
|
||||
`$location` service transparently uses the best available option.
|
||||
|
||||
- Opening a regular URL in a legacy browser -> redirects to a hashbang URL
|
||||
- Opening hashbang URL in a modern browser -> rewrites to a regular URL
|
||||
|
||||
### Example
|
||||
|
||||
<pre>
|
||||
it('should show example', inject(
|
||||
function($locationProvider) {
|
||||
$locationProvider.html5mode = true;
|
||||
$locationProvider.hashPrefix = '!';
|
||||
},
|
||||
function($location) {
|
||||
// in browser with HTML5 history support:
|
||||
// open http://host.com/#!/a -> rewrite to http://host.com/a
|
||||
// (replacing the http://host.com/#!/a history record)
|
||||
$location.path() == '/a'
|
||||
|
||||
$location.path('/foo');
|
||||
$location.absUrl() == 'http://host.com/foo'
|
||||
|
||||
$location.search() == {}
|
||||
$location.search({a: 'b', c: true});
|
||||
$location.absUrl() == 'http://host.com/foo?a=b&c'
|
||||
|
||||
$location.path('/new').search('x=y');
|
||||
$location.url() == 'new?x=y'
|
||||
$location.absUrl() == 'http://host.com/new?x=y'
|
||||
|
||||
// in browser without html5 history support:
|
||||
// open http://host.com/new?x=y -> redirect to http://host.com/#!/new?x=y
|
||||
// (again replacing the http://host.com/new?x=y history item)
|
||||
$location.path() == '/new'
|
||||
$location.search() == {x: 'y'}
|
||||
|
||||
$location.path('/foo/bar');
|
||||
$location.path() == '/foo/bar'
|
||||
$location.url() == '/foo/bar?x=y'
|
||||
$location.absUrl() == 'http://host.com/#!/foo/bar?x=y'
|
||||
}
|
||||
));
|
||||
</pre>
|
||||
|
||||
### Fallback for legacy browsers
|
||||
|
||||
For browsers that support the HTML5 history API, `$location` uses the HTML5 history API to write
|
||||
path and search. If the history API is not supported by a browser, `$location` supplies a Hasbang
|
||||
URL. This frees you from having to worry about whether the browser viewing your app supports the
|
||||
history API or not; the `$location` service makes this transparent to you.
|
||||
|
||||
### Html link rewriting
|
||||
|
||||
When you use the history API mode, you will need different links in different browser, but all you
|
||||
have to do is specify regular URL links, such as: `<a href="/some?foo=bar">link</a>`
|
||||
|
||||
When a user clicks on this link,
|
||||
|
||||
- In a legacy browser, the URL changes to `/index.html#!/some?foo=bar`
|
||||
- In a modern browser, the URL changes to `/some?foo=bar`
|
||||
|
||||
|
||||
In cases like the following, links are not rewritten; instead, the browser will perform a full page
|
||||
reload to the original link.
|
||||
|
||||
- Links with an `ng-ext-link` directive<br />
|
||||
Example: `<a href="/ext/link?a=b" ng-ext-link>link</a>`
|
||||
- Links that contain `target="_blank"`<br />
|
||||
Example: `<a href="/ext/link?a=b" target="_blank">link</a>`
|
||||
- Absolute links that go to a different domain<br />
|
||||
Example: `<a href="http://angularjs.org/">link</a>`
|
||||
|
||||
### Server side
|
||||
|
||||
Using this mode requires URL rewriting on server side, basically you have to rewrite all your links
|
||||
to entry point of your application (e.g. index.html)
|
||||
|
||||
### Crawling your app
|
||||
|
||||
If you want your AJAX application to be indexed by web crawlers, you rill need to add the following
|
||||
meta tag to the HEAD section of your document:
|
||||
<pre><meta name="fragment" content="!" /></pre>
|
||||
|
||||
This statement causes a crawler to request links with empty `_escaped_fragment_` parameter so that
|
||||
your server can recognize the crawler and serve it HTML snapshots. For more information about this
|
||||
technique, see {@link http://code.google.com/web/ajaxcrawling/docs/specification.html Making AJAX
|
||||
Applications Crawlable}.
|
||||
|
||||
### Relative links
|
||||
|
||||
Be sure to check all relative links, images, scripts etc. You must use an absolute path because the
|
||||
path is going to be rewritten. You can use `<base href="" />` tag as well.
|
||||
|
||||
Running Angular apps with the History API enabled from document root is strongly encouraged as it
|
||||
takes care of all relative link issues. **Otherwise you have to specify <base href="" /> !**
|
||||
|
||||
### Sending links among different browsers
|
||||
|
||||
Because of rewriting capability in HTML5 mode, your users will be able to open regular url links in
|
||||
legacy browsers and hashbang links in modern browser:
|
||||
|
||||
- Modern browser will rewrite hashbang URLs to regular URLs.
|
||||
- Older browsers will redirect regular URLs to hashbang URLs.
|
||||
|
||||
### Example
|
||||
|
||||
Here you can see two `$location` instances, both in **Html5 mode**, but on different browsers, so
|
||||
that you can see the differences. These `$location` services are connected to a fake browsers. Each
|
||||
input represents address bar of the browser.
|
||||
|
||||
Note that when you type hashbang url into first browser (or vice versa) it doesn't rewrite /
|
||||
redirect to regular / hashbang url, as this conversion happens only during parsing the initial URL
|
||||
= on page reload.
|
||||
|
||||
In this examples we use `<base href="/base/index.html" />`
|
||||
<doc:example>
|
||||
<doc:source source="false">
|
||||
|
||||
<div ng-non-bindable class="html5-hashbang-example">
|
||||
<div id="html5-mode" ng-controller="Html5Cntl">
|
||||
<h3>Browser with History API</h3>
|
||||
<ng-address-bar browser="html5"></ng-address-bar><br /><br />
|
||||
$location.protocol() = {{$location.protocol()}}<br />
|
||||
$location.host() = {{$location.host()}}<br />
|
||||
$location.port() = {{$location.port()}}<br />
|
||||
$location.path() = {{$location.path()}}<br />
|
||||
$location.search() = {{$location.search()}}<br />
|
||||
$location.hash() = {{$location.hash()}}<br />
|
||||
<a href="/base/first?a=b">/base/first?a=b</a> |
|
||||
<a href="sec/ond?flag#hash">sec/ond?flag#hash</a> |
|
||||
<a href="/base/another?search" ng-ext-link>external</a>
|
||||
</div>
|
||||
|
||||
<div id="hashbang-mode" ng-controller="HashbangCntl">
|
||||
<h3>Browser without History API</h3>
|
||||
<ng-address-bar browser="hashbang"></ng-address-bar><br /><br />
|
||||
$location.protocol() = {{$location.protocol()}}<br />
|
||||
$location.host() = {{$location.host()}}<br />
|
||||
$location.port() = {{$location.port()}}<br />
|
||||
$location.path() = {{$location.path()}}<br />
|
||||
$location.search() = {{$location.search()}}<br />
|
||||
$location.hash() = {{$location.hash()}}<br />
|
||||
<a href="/base/first?a=b">/base/first?a=b</a> |
|
||||
<a href="sec/ond?flag#hash">sec/ond?flag#hash</a> |
|
||||
<a href="/base/another?search" ng-ext-link>external</a>
|
||||
</div>
|
||||
</div>
|
||||
|
||||
<script type="text/javascript">
|
||||
function FakeBrowser(initUrl, baseHref) {
|
||||
this.onUrlChange = function(fn) {
|
||||
this.urlChange = fn;
|
||||
};
|
||||
|
||||
this.url = function() {
|
||||
return initUrl;
|
||||
};
|
||||
|
||||
this.defer = function(fn, delay) {
|
||||
setTimeout(function() { fn(); }, delay || 0);
|
||||
};
|
||||
|
||||
this.baseHref = function() {
|
||||
return baseHref;
|
||||
};
|
||||
|
||||
this.hover = angular.noop;
|
||||
this.notifyWhenOutstandingRequests = angular.noop;
|
||||
}
|
||||
|
||||
var browsers = {
|
||||
html5: new FakeBrowser('http://www.host.com/base/path?a=b#h', '/base/index.html'),
|
||||
hashbang: new FakeBrowser('http://www.host.com/base/index.html#!/path?a=b#h', '/base/index.html')
|
||||
};
|
||||
|
||||
function Html5Cntl($location) {
|
||||
this.$location = $location;
|
||||
}
|
||||
|
||||
function HashbangCntl($location) {
|
||||
this.$location = $location;
|
||||
}
|
||||
|
||||
function initEnv(name) {
|
||||
var root = angular.element(document.getElementById(name + '-mode'));
|
||||
angular.bootstrap(root, [function($compileProvider, $locationProvider, $provide){
|
||||
$locationProvider.html5Mode = true;
|
||||
$locationProvider.hashPrefix = '!';
|
||||
|
||||
$provide.value('$browser', browsers[name]);
|
||||
$provide.value('$document', root);
|
||||
$provide.value('$sniffer', {history: name == 'html5'});
|
||||
|
||||
$compileProvider.directive('ngAddressBar', function() {
|
||||
return function(scope, elm, attrs) {
|
||||
var browser = browsers[attrs.browser],
|
||||
input = angular.element('<input type="text" />').val(browser.url()),
|
||||
delay;
|
||||
|
||||
input.bind('keypress keyup keydown', function() {
|
||||
if (!delay) {
|
||||
delay = setTimeout(fireUrlChange, 250);
|
||||
}
|
||||
});
|
||||
|
||||
browser.url = function(url) {
|
||||
return input.val(url);
|
||||
};
|
||||
|
||||
elm.append('Address: ').append(input);
|
||||
|
||||
function fireUrlChange() {
|
||||
delay = null;
|
||||
browser.urlChange(input.val());
|
||||
}
|
||||
};
|
||||
});
|
||||
}]);
|
||||
root.bind('click', function(e) {
|
||||
e.stopPropagation();
|
||||
});
|
||||
}
|
||||
|
||||
initEnv('html5');
|
||||
initEnv('hashbang');
|
||||
</script>
|
||||
|
||||
</doc:source>
|
||||
</doc:example>
|
||||
|
||||
|
||||
# Caveats
|
||||
|
||||
## Page reload navigation
|
||||
|
||||
The `$location` service allows you to change only the URL; it does not allow you to reload the
|
||||
page. When you need to change the URL and reload the page or navigate to a different page, please
|
||||
use a lower level API, {@link api/angular.module.ng.$window $window.location.href}.
|
||||
|
||||
## Using $location outside of the scope life-cycle
|
||||
|
||||
`$location` knows about Angular's {@link api/angular.module.ng.$rootScope.Scope scope} life-cycle. When a URL changes in
|
||||
the browser it updates the `$location` and calls `$apply` so that all $watchers / $observers are
|
||||
notified.
|
||||
When you change the `$location` inside the `$digest` phase everything is ok; `$location` will
|
||||
propagate this change into browser and will notify all the $watchers / $observers.
|
||||
When you want to change the `$location` from outside Angular (for example, through a DOM Event or
|
||||
during testing) - you must call `$apply` to propagate the changes.
|
||||
|
||||
## $location.path() and ! or / prefixes
|
||||
|
||||
A path should always begin with forward slash (`/`); the `$location.path()` setter will add the
|
||||
forward slash if it is missing.
|
||||
|
||||
Note that the `!` prefix in the hashbang mode is not part of `$location.path()`; it is actually
|
||||
hashPrefix.
|
||||
|
||||
|
||||
# Testing with the $location service
|
||||
|
||||
When using `$location` service during testing, you are outside of the angular's {@link
|
||||
api/angular.module.ng.$rootScope.Scope scope} life-cycle. This means it's your responsibility to call `scope.$apply()`.
|
||||
|
||||
<pre>
|
||||
describe('serviceUnderTest', function() {
|
||||
beforeEach(module(function($provide) {
|
||||
$provide.factory('serviceUnderTest', function($location){
|
||||
// whatever it does...
|
||||
});
|
||||
});
|
||||
|
||||
it('should...', inject(function($location, $rootScope, serviceUnderTest) {
|
||||
$location.path('/new/path');
|
||||
$rootScope.$apply();
|
||||
|
||||
// test whatever the service should do...
|
||||
|
||||
}));
|
||||
});
|
||||
</pre>
|
||||
|
||||
|
||||
# Migrating from earlier AngularJS releases
|
||||
|
||||
In earlier releases of Angular, `$location` used `hashPath` or `hashSearch` to process path and
|
||||
search methods. With this release, the `$location` service processes path and search methods and
|
||||
then uses the information it obtains to compose hashbang URLs (such as
|
||||
`http://server.com/#!/path?search=a`), when necessary.
|
||||
|
||||
## Changes to your code
|
||||
|
||||
<table>
|
||||
<tr class="head">
|
||||
<td>Navigation inside the app</td>
|
||||
<td>Change to</td>
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
<td>$location.href = value<br />$location.hash = value<br />$location.update(value)<br
|
||||
/>$location.updateHash(value)</td>
|
||||
<td>$location.path(path).search(search)</td>
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
<td>$location.hashPath = path</td>
|
||||
<td>$location.path(path)</td>
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
<td>$location.hashSearch = search</td>
|
||||
<td>$location.search(search)</td>
|
||||
</tr>
|
||||
|
||||
<tr class="head">
|
||||
<td>Navigation outside the app</td>
|
||||
<td>Use lower level API</td>
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
<td>$location.href = value<br />$location.update(value)</td>
|
||||
<td>$window.location.href = value</td>
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
<td>$location[protocol | host | port | path | search]</td>
|
||||
<td>$window.location[protocol | host | port | path | search]</td>
|
||||
</tr>
|
||||
|
||||
<tr class="head">
|
||||
<td>Read access</td>
|
||||
<td>Change to</td>
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
<td>$location.hashPath</td>
|
||||
<td>$location.path()</td>
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
<td>$location.hashSearch</td>
|
||||
<td>$location.search()</td>
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
<td>$location.href<br />$location.protocol<br />$location.host<br />$location.port<br
|
||||
/>$location.hash</td>
|
||||
<td>$location.absUrl()<br />$location.protocol()<br />$location.host()<br />$location.port()<br
|
||||
/>$location.path() + $location.search()</td>
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
<td>$location.path<br />$location.search</td>
|
||||
<td>$window.location.path<br />$window.location.search</td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
## Two-way binding to $location
|
||||
|
||||
The Angular's compiler currently does not support two-way binding for methods (see {@link
|
||||
https://github.com/angular/angular.js/issues/404 issue}). If you should require two-way binding,
|
||||
you will need to specify an extra property that has two watchers. For example:
|
||||
<pre>
|
||||
<!-- html -->
|
||||
<input type="text" ng-model="locationPath" />
|
||||
</pre>
|
||||
<pre>
|
||||
// js - controller
|
||||
this.$watch('locationPath', function(path) {
|
||||
$location.path(path);
|
||||
});
|
||||
|
||||
this.$watch('$location.path()', function(path) {
|
||||
scope.locationPath = path;
|
||||
});
|
||||
</pre>
|
||||
|
||||
|
||||
# Related API
|
||||
|
||||
* {@link api/angular.module.ng.$location $location API}
|
||||
|
||||
|
||||
|
||||
@@ -0,0 +1,104 @@
|
||||
@ngdoc overview
|
||||
@name Developer Guide: Angular Services: Creating Services
|
||||
@description
|
||||
|
||||
While angular offers several useful services, for any nontrivial application you'll find it useful
|
||||
to write your own custom services. To do this you begin by registering a service factory function
|
||||
with a module either via the {@link api/angular.module Module#factory api} or directly
|
||||
via the {@link api/angular.module.AUTO.$provide $provide} api inside of module config function.
|
||||
|
||||
All angular services participate in {@link dev_guide.di dependency injection (DI)} by registering
|
||||
themselves with Angular's DI system (injector) under a `name` (id) as well as by declaring
|
||||
dependencies which need to be provided for the factory function of the registered service. The
|
||||
ability to swap dependencies for mocks/stubs/dummies in tests allows for services to be highly
|
||||
testable.
|
||||
|
||||
|
||||
# Registering Services
|
||||
|
||||
To register a service, you must have a module that this service will be part of. Afterwards, you
|
||||
can register the service with the module either via the {@link api/angular.Module Module api} or
|
||||
by using the {@link api/angular.module.AUTO.$provide $provide} service in the module configuration
|
||||
function.The following pseudo-code shows both approaches:
|
||||
|
||||
Using the angular.Module api:
|
||||
<pre>
|
||||
var myModule = angular.module('myModule', []);
|
||||
myModule.factory('serviceId', function() {
|
||||
var shinyNewServiceInstance;
|
||||
//factory function body that constructs shinyNewServiceInstance
|
||||
return shinyNewServiceInstance;
|
||||
});
|
||||
</pre>
|
||||
|
||||
Using the $provide service:
|
||||
<pre>
|
||||
angular.module('myModule', [], function($provide) {
|
||||
$provide.factory('serviceId', function() {
|
||||
var shinyNewServiceInstance;
|
||||
//factory function body that constructs shinyNewServiceInstance
|
||||
return shinyNewServiceInstance;
|
||||
});
|
||||
});
|
||||
</pre>
|
||||
|
||||
Note that you are not registering a service instance, but rather a factory function that will
|
||||
create this instance when called.
|
||||
|
||||
|
||||
# Dependencies
|
||||
|
||||
Services can not only be depended upon, but also have its own dependencies. These can be specified
|
||||
as arguments of the factory function. {@link dev_guide.di.understanding_di Read more} about the DI
|
||||
in Angular and the use of array notation and $inject property to make DI annotation
|
||||
minification-proof.
|
||||
|
||||
Following is an example of a very simple service. This service depends on the `$window` service
|
||||
(which is passed as a parameter to the factory function) and is just a function. The service simply
|
||||
stores all notifications; after the third one, the service displays all of the notifications by
|
||||
window alert.
|
||||
|
||||
<pre>
|
||||
angular.module('myModule', [], function($provide) {
|
||||
$provide.factory('notify', ['$window', function(win) {
|
||||
var msgs = [];
|
||||
return function(msg) {
|
||||
msgs.push(msg);
|
||||
if (msgs.length == 3) {
|
||||
win.alert(msgs.join("\n"));
|
||||
msgs = [];
|
||||
}
|
||||
};
|
||||
}]);
|
||||
});
|
||||
</pre>
|
||||
|
||||
|
||||
# Instantiating Angular Services
|
||||
|
||||
All services in Angular are instantiates services lazily, this means that a service will be created
|
||||
only when it is needed for instantiation of a service or an application component that depends on it.
|
||||
In other words, angular won't instantiate lazy services unless they are requested directly or
|
||||
indirectly by the application.
|
||||
|
||||
|
||||
# Services as singletons
|
||||
|
||||
Lastly, it is important to realize that all angular services are application singletons. This means
|
||||
that there is only one instance of a given service per injector. Since angular is lethally allergic
|
||||
to the global state, it is possible to create multiple injectors, each with its own instance of a
|
||||
given service, but that is rarely needed, except in tests where this property is crucially
|
||||
important.
|
||||
|
||||
|
||||
|
||||
## Related Topics
|
||||
|
||||
* {@link dev_guide.services.understanding_services Understanding Angular Services}
|
||||
* {@link dev_guide.services.managing_dependencies Managing Service Dependencies}
|
||||
* {@link dev_guide.services.injecting_controllers Injecting Services Into Controllers }
|
||||
* {@link dev_guide.services.testing_services Testing Angular Services}
|
||||
|
||||
## Related API
|
||||
|
||||
* {@link api/angular.module.ng Angular Service API}
|
||||
@@ -0,0 +1,118 @@
|
||||
@ngdoc overview
|
||||
@name Developer Guide: Angular Services: Injecting Services Into Controllers
|
||||
@description
|
||||
|
||||
Using services as dependencies for controllers is very similar to using services as dependencies
|
||||
for another service.
|
||||
|
||||
Since JavaScript is a dynamic language, DI can't figure out which services to inject by static
|
||||
types (like in static typed languages). Therefore, you can specify the service name by using the
|
||||
`$inject` property, which is an array containing strings with names of services to be injected.
|
||||
The name must match the corresponding service ID registered with angular. The order of the service
|
||||
IDs matters: the order of the services in the array will be used when calling the factory function
|
||||
with injected parameters. The names of parameters in factory function don't matter, but by
|
||||
convention they match the service IDs, which has added benefits discussed below.
|
||||
|
||||
<pre>
|
||||
function myController($loc, $log) {
|
||||
this.firstMethod = function() {
|
||||
// use $location service
|
||||
$loc.setHash();
|
||||
};
|
||||
this.secondMethod = function() {
|
||||
// use $log service
|
||||
$log.info('...');
|
||||
};
|
||||
}
|
||||
// which services to inject ?
|
||||
myController.$inject = ['$location', '$log'];
|
||||
</pre>
|
||||
|
||||
<doc:example module="MyServiceModule">
|
||||
<doc:source>
|
||||
<script type="text/javascript">
|
||||
angular.
|
||||
module('MyServiceModule', []).
|
||||
factory('notify', ['$window', function(win) {
|
||||
var msgs = [];
|
||||
return function(msg) {
|
||||
msgs.push(msg);
|
||||
if (msgs.length == 3) {
|
||||
win.alert(msgs.join("\n"));
|
||||
msgs = [];
|
||||
}
|
||||
};
|
||||
}]);
|
||||
|
||||
function myController(scope, notifyService) {
|
||||
scope.callNotify = function(msg) {
|
||||
notifyService(msg);
|
||||
};
|
||||
}
|
||||
|
||||
myController.$inject = ['$scope','notify'];
|
||||
</script>
|
||||
|
||||
<div ng-controller="myController">
|
||||
<p>Let's try this simple notify service, injected into the controller...</p>
|
||||
<input ng-init="message='test'" ng-model="message" >
|
||||
<button ng-click="callNotify(message);">NOTIFY</button>
|
||||
</div>
|
||||
</doc:source>
|
||||
<doc:scenario>
|
||||
it('should test service', function() {
|
||||
expect(element(':input[ng\\:model="message"]').val()).toEqual('test');
|
||||
});
|
||||
</doc:scenario>
|
||||
</doc:example>
|
||||
|
||||
## Implicit Dependency Injection
|
||||
|
||||
A new feature of Angular DI allows it to determine the dependency from the name of the parameter.
|
||||
Let's rewrite the above example to show the use of this implicit dependency injection of
|
||||
`$window`, `$scope`, and our `notify` service:
|
||||
|
||||
<doc:example module="MyServiceModuleDI">
|
||||
<doc:source>
|
||||
<script type="text/javascript">
|
||||
angular.
|
||||
module('MyServiceModuleDI', []).
|
||||
factory('notify', function($window) {
|
||||
var msgs = [];
|
||||
return function(msg) {
|
||||
msgs.push(msg);
|
||||
if (msgs.length == 3) {
|
||||
$window.alert(msgs.join("\n"));
|
||||
msgs = [];
|
||||
}
|
||||
};
|
||||
});
|
||||
|
||||
function myController($scope, notify) {
|
||||
$scope.callNotify = function(msg) {
|
||||
notify(msg);
|
||||
};
|
||||
}
|
||||
</script>
|
||||
<div ng-controller="myController">
|
||||
<p>Let's try the notify service, that is implicitly injected into the controller...</p>
|
||||
<input ng-init="message='test'" ng-model="message">
|
||||
<button ng-click="callNotify(message);">NOTIFY</button>
|
||||
</div>
|
||||
</doc:source>
|
||||
</doc:example>
|
||||
|
||||
However, if you plan to {@link http://en.wikipedia.org/wiki/Minification_(programming) minify} your
|
||||
code, your variable names will get renamed in which case you will still need to explicitly specify
|
||||
dependencies with the `$inject` property.
|
||||
|
||||
## Related Topics
|
||||
|
||||
{@link dev_guide.services.understanding_services Understanding Angular Services}
|
||||
{@link dev_guide.services.creating_services Creating Angular Services}
|
||||
{@link dev_guide.services.managing_dependencies Managing Service Dependencies}
|
||||
{@link dev_guide.services.testing_services Testing Angular Services}
|
||||
|
||||
## Related API
|
||||
|
||||
{@link api/angular.module.ng Angular Service API}
|
||||
@@ -0,0 +1,114 @@
|
||||
@ngdoc overview
|
||||
@name Developer Guide: Angular Services: Managing Service Dependencies
|
||||
@description
|
||||
|
||||
Angular allows services to declare other services as dependencies needed for construction of their
|
||||
instances.
|
||||
|
||||
To declare dependencies, you specify them in the factory function signature and annotate the
|
||||
function with the inject annotations either using by setting the `$inject` property, as an array of
|
||||
string identifiers or using the array notation. Optionally the `$inject` property declaration can be
|
||||
dropped (see "Inferring `$inject`" but note that that is currently an experimental feature).
|
||||
|
||||
Using the array notation:
|
||||
|
||||
<pre>
|
||||
function myModuleCfgFn($provide) {
|
||||
$provide.factory('myService', ['dep1', 'dep2', function(dep1, dep2) {}]);
|
||||
}
|
||||
</pre>
|
||||
|
||||
|
||||
Using the $inject property:
|
||||
|
||||
<pre>
|
||||
function myModuleCfgFn($provide) {
|
||||
var myServiceFactory = function(dep1, dep2) {};
|
||||
myServiceFactory.$inject = ['dep1', 'dep2'];
|
||||
$provide.factory('myService', myServiceFactory);
|
||||
}
|
||||
</pre>
|
||||
|
||||
|
||||
Using DI inference (incompatible with minifiers):
|
||||
|
||||
<pre>
|
||||
function myModuleCfgFn($provide) {
|
||||
$provide.factory('myService', function(dep1, dep2) {});
|
||||
}
|
||||
</pre>
|
||||
|
||||
|
||||
Here is an example of two services that depend on each other, as well as on other services that are
|
||||
provided by Angular's web framework:
|
||||
|
||||
<pre>
|
||||
/**
|
||||
* batchLog service allows for messages to be queued in memory and flushed
|
||||
* to the console.log every 50 seconds.
|
||||
*
|
||||
* @param {*} message Message to be logged.
|
||||
*/
|
||||
function batchLogModule($provide){
|
||||
$provide.factory('batchLog', ['$defer', '$log', function($defer, $log) {
|
||||
var messageQueue = [];
|
||||
|
||||
function log() {
|
||||
if (messageQueue.length) {
|
||||
$log('batchLog messages: ', messageQueue);
|
||||
messageQueue = [];
|
||||
}
|
||||
$defer(log, 50000);
|
||||
}
|
||||
|
||||
// start periodic checking
|
||||
log();
|
||||
|
||||
return function(message) {
|
||||
messageQueue.push(message);
|
||||
}
|
||||
}]);
|
||||
|
||||
/**
|
||||
* routeTemplateMonitor monitors each $route change and logs the current
|
||||
* template via the batchLog service.
|
||||
*/
|
||||
$provide.factory('routeTemplateMonitor',
|
||||
['$route', 'batchLog', '$rootScope',
|
||||
function($route, batchLog, $rootScope) {
|
||||
$rootScope.$on('$afterRouteChange', function() {
|
||||
batchLog($route.current ? $route.current.template : null);
|
||||
});
|
||||
}]);
|
||||
}
|
||||
|
||||
// get the main service to kick of the application
|
||||
angular.injector([batchLogModule]).get('routeTemplateMonitor');
|
||||
</pre>
|
||||
|
||||
Things to notice in this example:
|
||||
|
||||
* The `batchLog` service depends on the built-in {@link api/angular.module.ng.$defer $defer} and
|
||||
{@link api/angular.module.ng.$log $log} services, and allows messages to be logged into the
|
||||
`console.log` in batches.
|
||||
* The `routeTemplateMonitor` service depends on the built-in {@link api/angular.module.ng.$route
|
||||
$route} service as well as our custom `batchLog` service.
|
||||
* Both of our services use the factory function signature and array notation for inject annotations
|
||||
to declare their dependencies. It is important that the order of the string identifiers in the array
|
||||
is the same as the order of argument names in the signature of the factory function. Unless the
|
||||
dependencies are inferred from the function signature, it is this array with IDs and their order
|
||||
that the injector uses to determine which services and in which order to inject.
|
||||
|
||||
|
||||
## Related Topics
|
||||
|
||||
* {@link dev_guide.services.understanding_services Understanding Angular Services}
|
||||
* {@link dev_guide.services.creating_services Creating Angular Services}
|
||||
* {@link dev_guide.services.injecting_controllers Injecting Services Into Controllers }
|
||||
* {@link dev_guide.services.testing_services Testing Angular Services}
|
||||
|
||||
|
||||
## Related API
|
||||
|
||||
* {@link api/angular.module.ng Angular Service API}
|
||||
* {@link api/angular.injector Angular Injector API}
|
||||
@@ -0,0 +1,21 @@
|
||||
@ngdoc overview
|
||||
@name Developer Guide: Angular Services
|
||||
@description
|
||||
|
||||
Services are a feature that angular brings to client-side web apps from the server side, where
|
||||
services have been commonly used for a long time. Services in angular apps are substitutable
|
||||
objects that are wired together using {@link dev_guide.di dependency injection (DI)}. Services are
|
||||
most often used with {@link dev_guide.di dependency injection}, also a key feature of angular apps.
|
||||
|
||||
|
||||
## Related Topics
|
||||
|
||||
* {@link dev_guide.services.understanding_services Understanding Angular Services}
|
||||
* {@link dev_guide.services.creating_services Creating Angular Services}
|
||||
* {@link dev_guide.services.managing_dependencies Managing Service Dependencies}
|
||||
* {@link dev_guide.services.injecting_controllers Injecting Services Into Controllers}
|
||||
* {@link dev_guide.services.testing_services Testing Angular Services}
|
||||
|
||||
## Related API
|
||||
|
||||
* {@link api/angular.module.ng Angular Service API}
|
||||
@@ -0,0 +1,62 @@
|
||||
@ngdoc overview
|
||||
@name Developer Guide: Angular Services: Testing Angular Services
|
||||
@description
|
||||
|
||||
Following is a unit test for the service in the example in {@link
|
||||
dev_guide.services.creating_services Creating Angular Services}. The unit test example uses Jasmine
|
||||
spy (mock) instead of a real browser alert.
|
||||
|
||||
<pre>
|
||||
var mock, notify;
|
||||
|
||||
beforeEach(function() {
|
||||
mock = {alert: jasmine.createSpy()};
|
||||
|
||||
module(function($provide) {
|
||||
$provide.value('$window', mock);
|
||||
});
|
||||
|
||||
inject(function($injector) {
|
||||
notify = $injector.get('notify');
|
||||
});
|
||||
});
|
||||
|
||||
it('should not alert first two notifications', function() {
|
||||
notify('one');
|
||||
notify('two');
|
||||
|
||||
expect(mock.alert).not.toHaveBeenCalled();
|
||||
});
|
||||
|
||||
it('should alert all after third notification', function() {
|
||||
notify('one');
|
||||
notify('two');
|
||||
notify('three');
|
||||
|
||||
expect(mock.alert).toHaveBeenCalledWith("one\ntwo\nthree");
|
||||
});
|
||||
|
||||
it('should clear messages after alert', function() {
|
||||
notify('one');
|
||||
notify('two');
|
||||
notify('third');
|
||||
notify('more');
|
||||
notify('two');
|
||||
notify('third');
|
||||
|
||||
expect(mock.alert.callCount).toEqual(2);
|
||||
expect(mock.alert.mostRecentCall.args).toEqual(["more\ntwo\nthird"]);
|
||||
});
|
||||
</pre>
|
||||
|
||||
|
||||
## Related Topics
|
||||
|
||||
* {@link dev_guide.services.understanding_services Understanding Angular Services}
|
||||
* {@link dev_guide.services.creating_services Creating Angular Services}
|
||||
* {@link dev_guide.services.managing_dependencies Managing Service Dependencies}
|
||||
* {@link dev_guide.services.injecting_controllers Injecting Services Into Conrollers}
|
||||
|
||||
## Related API
|
||||
|
||||
* {@link api/angular.module.ng Angular Service API}
|
||||
@@ -0,0 +1,36 @@
|
||||
@ngdoc overview
|
||||
@name Developer Guide: Angular Services: Understanding Angular Services
|
||||
@description
|
||||
|
||||
Angular services are singletons that carry out specific tasks common to web apps, such as the
|
||||
{@link api/angular.module.ng.$http $http service} that provides low level access to the browser's
|
||||
`XMLHttpRequest` object.
|
||||
|
||||
To use an angular service, you identify it as a dependency for the dependent (a controller, or
|
||||
another service) that depends on the service. Angular's dependency injection subsystem takes care
|
||||
of the rest. The angular injector subsystem is in charge of service instantiation, resolution of
|
||||
dependencies, and provision of dependencies to factory functions as requested.
|
||||
|
||||
Angular injects dependencies using "constructor" injection (the service is passed in via a factory
|
||||
function). Because JavaScript is a dynamically typed language, Angular's dependency injection
|
||||
subsystem cannot use static types to identify service dependencies. For this reason a dependent
|
||||
must explicitly define its dependencies by using the `$inject` property. For example:
|
||||
|
||||
myController.$inject = ['$location'];
|
||||
|
||||
The angular web framework provides a set of services for common operations. Like other core angular
|
||||
variables and identifiers, the built-in services always start with `$` (such as `$http` mentioned
|
||||
above). You can also create your own custom services.
|
||||
|
||||
|
||||
## Related Topics
|
||||
|
||||
* {@link dev_guide.di About Angular Dependency Injection}
|
||||
* {@link dev_guide.services.creating_services Creating Angular Services}
|
||||
* {@link dev_guide.services.managing_dependencies Managing Service Dependencies}
|
||||
* {@link dev_guide.services.testing_services Testing Angular Services}
|
||||
|
||||
## Related API
|
||||
|
||||
* {@link api/angular.module.ng Angular Service API}
|
||||
* {@link api/angular.injector Injector API}
|
||||
@@ -0,0 +1,23 @@
|
||||
@ngdoc overview
|
||||
@name Developer Guide: Templates: Working With CSS in Angular
|
||||
@description
|
||||
|
||||
|
||||
Angular sets these CSS classes. It is up to your application to provide useful styling.
|
||||
|
||||
# CSS classes used by angular
|
||||
|
||||
* `ng-invalid`, `ng-valid`
|
||||
- **Usage:** angular applies this class to an input widget element if that element's input does
|
||||
notpass validation. (see {@link api/angular.module.ng.$compileProvider.directive.input input} widget).
|
||||
|
||||
* `ng-pristine`, `ng-dirty`
|
||||
- **Usage:** angular {@link api/angular.module.ng.$compileProvider.directive.input input} widget applies `ng-pristine` class
|
||||
to a new input widget element which did not have user interaction. Once the user interacts with
|
||||
the input widget the class is changed to `ng-dirty`.
|
||||
|
||||
|
||||
## Related Topics
|
||||
|
||||
* {@link dev_guide.templates Angular Templates}
|
||||
* {@link dev_guide.forms Angular Forms}
|
||||
@@ -0,0 +1,38 @@
|
||||
@ngdoc overview
|
||||
@name Developer Guide: Templates: Data Binding in Angular
|
||||
@description
|
||||
|
||||
Data-binding in angular web apps is the automatic syncing of data between the model and view
|
||||
components. The way that angular implements data-binding lets you treat the model as the
|
||||
single-source-of-truth in your application. The view is a projection of the model at all times.
|
||||
When the model changes, the view reflects the change, and vice versa.
|
||||
|
||||
## Data Binding in Classical Template Systems
|
||||
|
||||
<img class="right" src="img/One_Way_Data_Binding.png"/>
|
||||
Most templating systems bind data in only one direction: they merge template and model components
|
||||
together into a view, as illustrated in the diagram. After the merge occurs, changes to the model
|
||||
or related sections of the view are NOT automatically reflected in the view. Worse, any changes
|
||||
that the user makes to the view are not reflected in the model. This means that the developer has
|
||||
to write code that constantly syncs the view with the model and the model with the view.
|
||||
|
||||
## Data Binding in Angular Templates
|
||||
|
||||
<img class="right" src="img/Two_Way_Data_Binding.png"/>
|
||||
The way angular templates works is different, as illustrated in the diagram. They are different
|
||||
because first the template (which is the uncompiled HTML along with any additional markup or
|
||||
directives) is compiled on the browser, and second, the compilation step produces a live view. We
|
||||
say live because any changes to the view are immediately reflected in the model, and any changes in
|
||||
the model are propagated to the view. This makes the model always the single-source-of-truth for
|
||||
the application state, greatly simplifying the programing model for the developer. You can think of
|
||||
the view as simply an instant projection of your model.
|
||||
|
||||
Because the view is just a projection of the model, the controller is completely separated from the
|
||||
view and unaware of it. This makes testing a snap because it is easy to test your controller in
|
||||
isolation without the view and the related DOM/browser dependency.
|
||||
|
||||
|
||||
## Related Topics
|
||||
|
||||
* {@link dev_guide.scopes Angular Scopes}
|
||||
* {@link dev_guide.templates Angular Templates}
|
||||
@@ -0,0 +1,66 @@
|
||||
@ngdoc overview
|
||||
@name Developer Guide: Templates: Filters: Creating Angular Filters
|
||||
@description
|
||||
|
||||
Writing your own filter is very easy: just define a JavaScript function on the `angular.module.ng.$filter`
|
||||
object.
|
||||
The framework passes in the input value as the first argument to your function. Any filter
|
||||
arguments are passed in as additional function arguments.
|
||||
|
||||
You can use these variables in the function:
|
||||
|
||||
* `this` — The current scope.
|
||||
* `this.$element` — The DOM element containing the binding. The `$element` variable allows the
|
||||
filter to manipulate the DOM.
|
||||
|
||||
The following sample filter reverses a text string. In addition, it conditionally makes the
|
||||
text upper-case and assigns color.
|
||||
|
||||
<doc:example module="MyReverseModule">
|
||||
<doc:source>
|
||||
<script type="text/javascript">
|
||||
angular.module('MyReverseModule', []).
|
||||
filter('reverse', function() {
|
||||
return function(input, uppercase) {
|
||||
var out = "";
|
||||
for (var i = 0; i < input.length; i++) {
|
||||
out = input.charAt(i) + out;
|
||||
}
|
||||
// conditional based on optional argument
|
||||
if (uppercase) {
|
||||
out = out.toUpperCase();
|
||||
}
|
||||
return out;
|
||||
}
|
||||
});
|
||||
|
||||
function Ctrl($scope) {
|
||||
$scope.greeting = 'hello';
|
||||
}
|
||||
</script>
|
||||
|
||||
<div ng-controller="Ctrl">
|
||||
<input ng-model="greeting" type="greeting"><br>
|
||||
No filter: {{greeting}}<br>
|
||||
Reverse: {{greeting|reverse}}<br>
|
||||
Reverse + uppercase: {{greeting|reverse:true}}<br>
|
||||
</div>
|
||||
</doc:source>
|
||||
<doc:scenario>
|
||||
it('should reverse greeting', function() {
|
||||
expect(binding('greeting|reverse')).toEqual('olleh');
|
||||
input('greeting').enter('ABC');
|
||||
expect(binding('greeting|reverse')).toEqual('CBA');
|
||||
});
|
||||
</doc:scenario>
|
||||
</doc:example>
|
||||
|
||||
|
||||
## Related Topics
|
||||
|
||||
* {@link dev_guide.templates.filters Understanding Angular Filters}
|
||||
* {@link dev_guide.compiler Angular HTML Compiler}
|
||||
|
||||
## Related API
|
||||
|
||||
* {@link api/angular.module.ng.$filter Angular Filter API}
|
||||
@@ -0,0 +1,28 @@
|
||||
@ngdoc overview
|
||||
@name Developer Guide: Templates: Understanding Angular Filters
|
||||
@description
|
||||
|
||||
Angular filters format data for display to the user. In addition to formatting data, filters can
|
||||
also modify the DOM. This allows filters to handle tasks such as conditionally applying CSS styles
|
||||
to filtered output.
|
||||
|
||||
For example, you might have a data object that needs to be formatted according to the locale before
|
||||
displaying it to the user. You can pass expressions through a chain of filters like this:
|
||||
|
||||
name | uppercase
|
||||
|
||||
The expression evaluator simply passes the value of name to
|
||||
{@link api/angular.module.ng.$filter.uppercase uppercase filter}.
|
||||
|
||||
In addition to formatting data, filters can also modify the DOM. This allows filters to handle
|
||||
tasks such as conditionally applying CSS styles to filtered output.
|
||||
|
||||
|
||||
## Related Topics
|
||||
|
||||
* {@link dev_guide.templates.filters.using_filters Using Angular Filters}
|
||||
* {@link dev_guide.templates.filters.creating_filters Creating Angular Filters}
|
||||
|
||||
## Related API
|
||||
|
||||
* {@link api/angular.module.ng.$filter Angular Filter API}
|
||||
@@ -0,0 +1,40 @@
|
||||
@ngdoc overview
|
||||
@name Developer Guide: Templates: Filters: Using Angular Filters
|
||||
@description
|
||||
|
||||
Filters can be part of any {@link api/angular.module.ng.$rootScope.Scope} evaluation but are typically used to format
|
||||
expressions in bindings in your templates:
|
||||
|
||||
{{ expression | filter }}
|
||||
|
||||
Filters typically transform the data to a new data type, formatting the data in the process.
|
||||
Filters can also be chained, and can take optional arguments.
|
||||
|
||||
You can chain filters using this syntax:
|
||||
|
||||
{{ expression | filter1 | filter2 }}
|
||||
|
||||
You can also pass colon-delimited arguments to filters, for example, to display the number 123 with
|
||||
2 decimal points:
|
||||
|
||||
123 | number:2
|
||||
|
||||
Here are some examples that show values before and after applying different filters to an
|
||||
expression in a binding:
|
||||
|
||||
* No filter: `{{1234.5678}}` => `1234.5678`
|
||||
* Number filter: `{{1234.5678|number}}` => `1,234.57`. Notice the "," and rounding to two
|
||||
significant digits.
|
||||
* Filter with arguments: `{{1234.5678|number:5}}` => `1,234.56780`. Filters can take optional
|
||||
arguments, separated by colons in a binding. For example, the "number" filter takes a number
|
||||
argument that specifies how many digits to display to the right of the decimal point.
|
||||
|
||||
|
||||
## Related Topics
|
||||
|
||||
* {@link dev_guide.templates.filters Understanding Angular Filters}
|
||||
* {@link dev_guide.templates.filters.creating_filters Creating Angular Filters}
|
||||
|
||||
## Related API
|
||||
|
||||
* {@link api/angular.module.ng.$filter Angular Filter API}
|
||||
@@ -0,0 +1,57 @@
|
||||
@ngdoc overview
|
||||
@name Developer Guide: Understanding Angular Templates
|
||||
@description
|
||||
|
||||
An angular template is the declarative specification that, along with information from the model
|
||||
and controller, becomes the rendered view that a user sees in the browser. It is the static DOM,
|
||||
containing HTML, CSS, and angular-specific elements and angular-specific element attributes. The
|
||||
angular elements and attributes direct angular to add behavior and transform the template DOM into
|
||||
the dynamic view DOM.
|
||||
|
||||
These are the types of angular elements and element attributes you can use in a template:
|
||||
|
||||
* {@link api/angular.module.ng.$compileProvider.directive Directive} — An attribute or element that
|
||||
augments an existing DOM element or represents a reusable DOM component - a widget.
|
||||
* {@link api/angular.module.ng.$interpolate Markup} — The double
|
||||
curly brace notation `{{ }}` to bind expressions to elements is built-in angular markup.
|
||||
* {@link dev_guide.templates.filters Filter} — Formats your data for display to the user.
|
||||
* {@link dev_guide.forms Form controls} — Lets you validate user input.
|
||||
|
||||
Note: In addition to declaring the elements above in templates, you can also access these elements
|
||||
in JavaScript code.
|
||||
|
||||
The following code snippet shows a simple angular template made up of standard HTML tags along with
|
||||
angular {@link api/angular.module.ng.$compileProvider.directive directives} and curly-brace bindings
|
||||
with {@link dev_guide.expressions expressions}:
|
||||
|
||||
<pre>
|
||||
<html ng-app>
|
||||
<!-- Body tag augmented with ng-controller directive -->
|
||||
<body ng-controller="MyController">
|
||||
<input ng-model="foo" value="bar">
|
||||
<!-- Button tag with ng-click directive, and
|
||||
string expression 'buttonText'
|
||||
wrapped in "{{ }}" markup -->
|
||||
<button ng-click="changeFoo()">{{buttonText}}</button>
|
||||
<script src="angular.js">
|
||||
</body>
|
||||
</html>
|
||||
</pre>
|
||||
|
||||
In a simple single-page app, the template consists of HTML, CSS, and angular directives contained
|
||||
in just one HTML file (usually `index.html`). In a more complex app, you can display multiple views
|
||||
within one main page using "partials", which are segments of template located in separate HTML
|
||||
files. You "include" the partials in the main page using the {@link api/angular.module.ng.$route
|
||||
$route} service in conjunction with the {@link api/angular.module.ng.$compileProvider.directive.ng-view ng-view} directive. An
|
||||
example of this technique is shown in the {@link tutorial/ angular tutorial}, in steps seven and
|
||||
eight.
|
||||
|
||||
|
||||
## Related Topics
|
||||
|
||||
* {@link dev_guide.templates.filters Angular Filters}
|
||||
* {@link dev_guide.forms Angular Forms}
|
||||
|
||||
## Related API
|
||||
|
||||
* {@link api/index API Reference}
|
||||
@@ -0,0 +1,281 @@
|
||||
@ngdoc overview
|
||||
@name Developer Guide: Unit Testing
|
||||
@description
|
||||
|
||||
JavaScript is a dynamically typed language which comes with great power of expression, but it also
|
||||
come with almost no-help from the compiler. For this reason we feel very strongly that any code
|
||||
written in JavaScript needs to come with a strong set of tests. We have built many features into
|
||||
angular which makes testing your angular applications easy. So there is no excuse for not do it.
|
||||
# It is all about NOT mixing concerns
|
||||
Unit testing as the name implies is about testing individual units of code. Unit tests try to
|
||||
answer the question: Did I think about the logic correctly. Does the sort function order the list
|
||||
in the right order. In order to answer such question it is very important that we can isolate it.
|
||||
That is because when we are testing the sort function we don't want to be forced into crating
|
||||
related pieces such as the DOM elements, or making any XHR calls in getting the data to sort. While
|
||||
this may seem obvious it usually is very difficult to be able to call an individual function on a
|
||||
typical project. The reason is that the developers often time mix concerns, and they end up with a
|
||||
piece of code which does everything. It reads the data from XHR, it sorts it and then it
|
||||
manipulates the DOM. With angular we try to make it easy for you to do the right thing, and so we
|
||||
provide dependency injection for your XHR (which you can mock out) and we crated abstraction which
|
||||
allow you to sort your model without having to resort to manipulating the DOM. So that in the end,
|
||||
it is easy to write a sort function which sorts some data, so that your test can create a data set,
|
||||
apply the function, and assert that the resulting model is in the correct order. The test does not
|
||||
have to wait for XHR, or create the right kind of DOM, or assert that your function has mutated the
|
||||
DOM in the right way. Angular is written with testability in mind, but it still requires that you
|
||||
do the right thing. We tried to make the right thing easy, but angular is not magic, which means if
|
||||
you don't follow these, you may very well end up with an untestable application.
|
||||
|
||||
## Dependency Inject
|
||||
There are several ways in which you can get a hold of a dependency:
|
||||
1. You could create it using the `new` operator.
|
||||
2. You could look for it in a well know place, also known as global singleton.
|
||||
3. You could ask a registry (also known as service registry) for it. (But how do you get a hold of
|
||||
the registry? Must likely by looking it up in a well know place. See #2)
|
||||
4. You could expect that the it be handed to you.
|
||||
|
||||
Out of the list above only the last of is testable. Lets look at why:
|
||||
|
||||
### Using the `new` operator
|
||||
|
||||
While there is nothing wrong with the `new` operator fundamentally the issue is that calling a new
|
||||
on a constructor permanently binds the call site to the type. For example lets say that we are
|
||||
trying to instantiate an `XHR` so that we can get some data from the server.
|
||||
|
||||
<pre>
|
||||
function MyClass() {
|
||||
this.doWork = function() {
|
||||
var xhr = new XHR();
|
||||
xhr.open(method, url, true);
|
||||
xhr.onreadystatechange = function() {...}
|
||||
xhr.send();
|
||||
}
|
||||
}
|
||||
</pre>
|
||||
|
||||
The issue becomes, that in tests, we would very much like to instantiate a `MockXHR` which would
|
||||
allow us to return fake data and simulate network failures. By calling `new XHR()` we are
|
||||
permanently bound to the actual one, and there is no good way to replace it. Yes there is monkey
|
||||
patching, that is a bad idea for many reasons, which is outside the scope of this document.
|
||||
|
||||
The class above is hard to test since we have to resort to monkey patching:
|
||||
<pre>
|
||||
var oldXHR = XHR;
|
||||
XHR = function MockXHR() {};
|
||||
var myClass = new MyClass();
|
||||
myClass.doWork();
|
||||
// assert that MockXHR got called with the right arguments
|
||||
XHR = oldXHR; // if you forget this bad things will happen
|
||||
</pre>
|
||||
|
||||
|
||||
### Global look-up:
|
||||
Another way to approach the problem is look for the service in a well known location.
|
||||
|
||||
<pre>
|
||||
function MyClass() {
|
||||
this.doWork = function() {
|
||||
global.xhr({
|
||||
method:'...',
|
||||
url:'...',
|
||||
complete:function(response){ ... }
|
||||
})
|
||||
}
|
||||
}
|
||||
</pre>
|
||||
|
||||
While no new instance of dependency is being created, it is fundamentally the same as `new`, in
|
||||
that there is no good way to intercept the call to `global.xhr` for testing purposes, other then
|
||||
through monkey patching. The basic issue for testing is that global variable needs to be mutated in
|
||||
order to replace it with call to a mock method. For further explanation why this is bad see: {@link
|
||||
http://misko.hevery.com/code-reviewers-guide/flaw-brittle-global-state-singletons/ Brittle Global
|
||||
State & Singletons}
|
||||
|
||||
The class above is hard to test since we have to change global state:
|
||||
<pre>
|
||||
var oldXHR = glabal.xhr;
|
||||
glabal.xhr = function mockXHR() {};
|
||||
var myClass = new MyClass();
|
||||
myClass.doWork();
|
||||
// assert that mockXHR got called with the right arguments
|
||||
global.xhr = oldXHR; // if you forget this bad things will happen
|
||||
</pre>
|
||||
|
||||
|
||||
### Service Registry:
|
||||
|
||||
It may seem as that this can be solved by having a registry for all of the services, and then
|
||||
having the tests replace the services as needed.
|
||||
|
||||
<pre>
|
||||
function MyClass() {
|
||||
var serviceRegistry = ????;
|
||||
this.doWork = function() {
|
||||
var xhr = serviceRegistry.get('xhr');
|
||||
xhr({
|
||||
method:'...',
|
||||
url:'...',
|
||||
complete:function(response){ ... }
|
||||
})
|
||||
}
|
||||
</pre>
|
||||
|
||||
However, where dose the serviceRegistry come from? if it is:
|
||||
* `new`-ed up, the the test has no chance to reset the services for testing
|
||||
* global look-up, then the service returned is global as well (but resetting is easier, since
|
||||
there is only one global variable to be reset).
|
||||
|
||||
The class above is hard to test since we have to change global state:
|
||||
<pre>
|
||||
var oldServiceLocator = glabal.serviceLocator;
|
||||
glabal.serviceLocator.set('xhr', function mockXHR() {});
|
||||
var myClass = new MyClass();
|
||||
myClass.doWork();
|
||||
// assert that mockXHR got called with the right arguments
|
||||
glabal.serviceLocator = oldServiceLocator; // if you forget this bad things will happen
|
||||
</pre>
|
||||
|
||||
|
||||
### Passing in Dependencies:
|
||||
Lastly the dependency can be passed in.
|
||||
|
||||
<pre>
|
||||
function MyClass(xhr) {
|
||||
this.doWork = function() {
|
||||
xhr({
|
||||
method:'...',
|
||||
url:'...',
|
||||
complete:function(response){ ... }
|
||||
})
|
||||
}
|
||||
</pre>
|
||||
|
||||
This is the preferred way since the code makes no assumptions as to where the `xhr` comes from,
|
||||
rather that whoever created the class was responsible for passing it in. Since the creator of the
|
||||
class should be different code than the user of the class, it separates the responsibility of
|
||||
creation from the logic, and that is what dependency-injection is in a nutshell.
|
||||
|
||||
The class above is very testable, since in the test we can write:
|
||||
<pre>
|
||||
function xhrMock(args) {...}
|
||||
var myClass = new MyClass(xhrMock);
|
||||
myClass.doWork();
|
||||
// assert that xhrMock got called with the right arguments
|
||||
</pre>
|
||||
|
||||
Notice that no global variables were harmed in the writing of this test.
|
||||
|
||||
Angular comes with {@link dev_guide.di dependency-injection} built in which makes the right thing
|
||||
easy to do, but you still need to do it if you wish to take advantage of the testability story.
|
||||
|
||||
## Controllers
|
||||
What makes each application unique is its logic, which is what we would like to test. If the logic
|
||||
for your application is mixed in with DOM manipulation, it will be hard to test as in the example
|
||||
below:
|
||||
|
||||
<pre>
|
||||
function PasswordController() {
|
||||
// get references to DOM elements
|
||||
var msg = $('.ex1 span');
|
||||
var input = $('.ex1 input');
|
||||
var strength;
|
||||
|
||||
this.grade = function() {
|
||||
msg.removeClass(strength);
|
||||
var pwd = input.val();
|
||||
password.text(pwd);
|
||||
if (pwd.length > 8) {
|
||||
strength = 'strong';
|
||||
} else if (pwd.length > 3) {
|
||||
strength = 'medium';
|
||||
} else {
|
||||
strength = 'weak';
|
||||
}
|
||||
msg
|
||||
.addClass(strength)
|
||||
.text(strength);
|
||||
}
|
||||
}
|
||||
</pre>
|
||||
|
||||
The code above is problematic from testability, since it requires your test to have the right kind
|
||||
of DOM present when the code executes. The test would look like this:
|
||||
|
||||
<pre>
|
||||
var input = $('<input type="text"/>');
|
||||
var span = $('<span>');
|
||||
$('body').html('<div class="ex1">')
|
||||
.find('div')
|
||||
.append(input)
|
||||
.append(span);
|
||||
var pc = new PasswordController();
|
||||
input.val('abc');
|
||||
pc.grade();
|
||||
expect(span.text()).toEqual('weak');
|
||||
$('body').html('');
|
||||
</pre>
|
||||
|
||||
In angular the controllers are strictly separated from the DOM manipulation logic which results in
|
||||
a much easier testability story as can be seen in this example:
|
||||
|
||||
<pre>
|
||||
function PasswordCntrl() {
|
||||
this.password = '';
|
||||
this.grade = function() {
|
||||
var size = this.password.length;
|
||||
if (size > 8) {
|
||||
this.strength = 'strong';
|
||||
} else if (size > 3) {
|
||||
this.strength = 'medium';
|
||||
} else {
|
||||
this.strength = 'weak';
|
||||
}
|
||||
};
|
||||
}
|
||||
</pre>
|
||||
|
||||
and the tests is straight forward
|
||||
|
||||
<pre>
|
||||
var pc = new PasswordController();
|
||||
pc.password('abc');
|
||||
pc.grade();
|
||||
expect(span.strength).toEqual('weak');
|
||||
</pre>
|
||||
|
||||
Notice that the test is not only much shorter but it is easier to follow what is going on. We say
|
||||
that such a test tells a story, rather then asserting random bits which don't seem to be related.
|
||||
|
||||
|
||||
## Filters
|
||||
{@link api/angular.module.ng.$filter Filters} are functions which transform the data into user readable
|
||||
format. They are important because they remove the formatting responsibility from the application
|
||||
logic, further simplifying the application logic.
|
||||
|
||||
<pre>
|
||||
myModule.filter('length', function() {
|
||||
return function(text){
|
||||
return (''+(text||'')).length;
|
||||
}
|
||||
});
|
||||
|
||||
var length = $filter('length');
|
||||
expect(length(null)).toEqual(0);
|
||||
expect(length('abc')).toEqual(3);
|
||||
</pre>
|
||||
|
||||
## Directives
|
||||
Directives in angular are responsible for updating the DOM when the state of the model changes.
|
||||
|
||||
|
||||
## Mocks
|
||||
oue
|
||||
## Global State Isolation
|
||||
oue
|
||||
# Preferred way of Testing
|
||||
uo
|
||||
## JavaScriptTestDriver
|
||||
ou
|
||||
## Jasmine
|
||||
ou
|
||||
## Sample project
|
||||
uoe
|
||||
@@ -0,0 +1,162 @@
|
||||
@ngdoc overview
|
||||
@name Developer Guide: Internet Explorer Compatibility
|
||||
@description
|
||||
|
||||
# Overview
|
||||
|
||||
This document describes the Internet Explorer (IE) idiosyncrasies when dealing with custom HTML
|
||||
attributes and tags. Read this document if you are planning on deploying your angular application
|
||||
on IE v8.0 or earlier.
|
||||
|
||||
# Short Version
|
||||
|
||||
To make your angular application work on IE please make sure that:
|
||||
|
||||
1. you **do not** use custom element tags such as `<ng:view>` (use the attribute version `<div
|
||||
ng-view>` instead), or
|
||||
|
||||
2. if you **do use** custom element tags, then you must take these steps to make IE happy:
|
||||
|
||||
<pre>
|
||||
<html xmlns:ng="http://angularjs.org">
|
||||
<head>
|
||||
<!--[if lte IE 8]>
|
||||
<script>
|
||||
document.createElement('ng-include');
|
||||
document.createElement('ng-pluralize');
|
||||
document.createElement('ng-view');
|
||||
|
||||
// Optionally these for CSS
|
||||
document.createElement('ng:include');
|
||||
document.createElement('ng:pluralize');
|
||||
document.createElement('ng:view');
|
||||
</script>
|
||||
<![endif]-->
|
||||
</head>
|
||||
<body>
|
||||
...
|
||||
</body>
|
||||
</html>
|
||||
</pre>
|
||||
|
||||
The **important** parts are:
|
||||
|
||||
* `xmlns:ng` - *namespace* - you need one namespace for each custom tay you are planning on
|
||||
using.
|
||||
|
||||
* `document.createElement(yourTagName)` - *creation of custom tag names* - Since this is an
|
||||
issue only for older version of IE you need to load it conditionally. For each tag which does
|
||||
not have namespace and which is not defined in HTML you need to pre-declare it to make IE
|
||||
happy.
|
||||
|
||||
|
||||
# Long Version
|
||||
|
||||
IE has an issues with element tag names which are not standard HTML tag names. These fall into two
|
||||
categories, and each category has its own fix.
|
||||
|
||||
* If the tag name starts with `my:` prefix than it is considered an XML namespace and must
|
||||
have corresponding namespace declaration on `<html xmlns:my="ignored">`
|
||||
|
||||
* If the tag has no `:` but it is not a standard HTML tag, then it must be pre-created using
|
||||
`document.createElement('my-tag')`
|
||||
|
||||
* If you have are planning on styling the custom tag with CSS selectors, then it must be
|
||||
pre-created using `document.createElement('my-tag')` regardless of XML namespace.
|
||||
|
||||
|
||||
## The Good News
|
||||
|
||||
The good news is that these restrictions only apply to element tag names, and not to element
|
||||
attribute names. So this requires no special handling in IE: `<div my-tag your:tag></div>`.
|
||||
|
||||
|
||||
## What happens if I fail to do this?
|
||||
|
||||
Suppose you have HTML with unknown tag `mytag` (this could also be `my:tag` or `my-tag` with same
|
||||
result):
|
||||
|
||||
<pre>
|
||||
<html>
|
||||
<body>
|
||||
<mytag>some text</mytag>
|
||||
</body>
|
||||
</html>
|
||||
</pre>
|
||||
|
||||
It should pares into the following DOM:
|
||||
|
||||
<pre>
|
||||
#document
|
||||
+- HTML
|
||||
+- BODY
|
||||
+- mytag
|
||||
+- #text: some text
|
||||
</pre>
|
||||
|
||||
The expected behavior is that the `BODY` element has a child element `mytag`, which in turn has
|
||||
the text `some text`.
|
||||
|
||||
But this is not what IE does (if the above fixes are not included):
|
||||
|
||||
<pre>
|
||||
#document
|
||||
+- HTML
|
||||
+- BODY
|
||||
+- mytag
|
||||
+- #text: some text
|
||||
+- /mytag
|
||||
</pre>
|
||||
|
||||
In IE, the behavior is that the `BODY` element has three children:
|
||||
|
||||
1. A self closing `mytag`. Example of self closing tag is `<br/>`. The trailing `/` is optional,
|
||||
but the `<br>` tag is not allowed to have any children, and browsers consider `<br>some
|
||||
text</br>` as three siblings not a `<br>` with `some text` as child.
|
||||
|
||||
2. A text node with `some text`. This should have been a child of `mytag` above, not a sibling.
|
||||
|
||||
3. A corrupt self closing `/mytag`. This is corrupt since element names are not allowed to have
|
||||
the `/` character. Furthermore this closing element should not be part of the DOM since it is
|
||||
only used to delimitate the structure of the DOM.
|
||||
|
||||
|
||||
## CSS Styling of Custom Tag Names
|
||||
|
||||
The to make CSS selector work with custom elements the custom element name must be shived with the
|
||||
`document.createElement('my-tag')` regardless of XML namespace.
|
||||
|
||||
<pre>
|
||||
<html xmlns:ng="needed for ng: namespace">
|
||||
<head>
|
||||
<!--[if lte IE 8]>
|
||||
<script>
|
||||
// needed to make ng-include parse properly
|
||||
document.createElement('ng-include');
|
||||
|
||||
// needed to enable CSS reference
|
||||
document.createElement('ng:view');
|
||||
</script>
|
||||
<![endif]-->
|
||||
<style>
|
||||
ng\\:view {
|
||||
display: block;
|
||||
border: 1px solid red;
|
||||
}
|
||||
|
||||
ng-include {
|
||||
display: block;
|
||||
border: 1px solid blue;
|
||||
}
|
||||
</style>
|
||||
</head>
|
||||
<body>
|
||||
<ng:view></ng:view>
|
||||
<ng-include></ng-include>
|
||||
...
|
||||
</body>
|
||||
</html>
|
||||
</pre>
|
||||
|
||||
|
||||
|
||||
@@ -0,0 +1,53 @@
|
||||
@ngdoc overview
|
||||
@name Developer Guide
|
||||
@description
|
||||
|
||||
Welcome to the angular Developer Guide. If you are here to learn the details of how to use angular
|
||||
to develop web apps, you've come to the right place.
|
||||
|
||||
If you are completely or relatively unfamiliar with angular, you may want to check out one or both
|
||||
of the following documents before returning here to the Developer Guide:
|
||||
|
||||
* {@link misc/started Getting Started}
|
||||
* {@link tutorial/index Angular Tutorial}
|
||||
|
||||
<hr>
|
||||
|
||||
## {@link dev_guide.overview Overview of Angular}
|
||||
|
||||
## {@link dev_guide.bootstrap Initializing Angular}
|
||||
|
||||
* {@link dev_guide.bootstrap.auto_bootstrap Understanding Automatic Initialization}
|
||||
* {@link dev_guide.bootstrap.manual_bootstrap Understanding Manual Initialization}
|
||||
|
||||
## {@link dev_guide.mvc About MVC in Angular}
|
||||
|
||||
* {@link dev_guide.mvc.understanding_model Understanding the Model Component}
|
||||
* {@link dev_guide.mvc.understanding_controller Understanding the Controller Component}
|
||||
* {@link dev_guide.mvc.understanding_view Understanding the View Component}
|
||||
|
||||
## {@link dev_guide.scopes Angular Scope Objects}
|
||||
|
||||
* {@link dev_guide.scopes.understanding_scopes Understanding Angular Scope Objects}
|
||||
* {@link dev_guide.scopes.internals Angular Scope Internals}
|
||||
|
||||
## {@link dev_guide.compiler Angular HTML Compiler}
|
||||
|
||||
* {@link api/angular.module.ng.$compileProvider.directive Understanding Angular Directives}
|
||||
|
||||
## {@link dev_guide.templates Angular Templates}
|
||||
|
||||
* {@link dev_guide.templates.filters Understanding Angular Filters}
|
||||
* {@link dev_guide.forms Understanding Angular Forms}
|
||||
|
||||
## {@link dev_guide.services Angular Services}
|
||||
|
||||
* {@link dev_guide.services.understanding_services Understanding Angular Services}
|
||||
* {@link dev_guide.services.creating_services Creating Angular Services}
|
||||
* {@link dev_guide.services.managing_dependencies Managing Service Dependencies}
|
||||
* {@link dev_guide.services.testing_services Testing Angular Services}
|
||||
|
||||
## {@link dev_guide.di About Dependency Injection}
|
||||
|
||||
* {@link dev_guide.di.understanding_di Understanding DI in Angular}
|
||||
* {@link dev_guide.di.using_di_controllers Using DI in Controllers}
|
||||
@@ -0,0 +1,258 @@
|
||||
@ngdoc overview
|
||||
@name Developer Guide: Modules
|
||||
@description
|
||||
|
||||
# What is a Module?
|
||||
|
||||
Most applications have a main method which instantiates, wires, and bootstraps the application.
|
||||
Angular apps don't have a main method, instead the modules serves the purpose of declaratively
|
||||
specifying how an application should be bootstrapped. There are several advantages to this
|
||||
approach:
|
||||
|
||||
* The process is more declarative which is easier to understand
|
||||
* In unit-testing there is no need to load all modules, which may aid in writing unit-tests.
|
||||
* Additional modules can be loaded in scenario tests, which can override some of the
|
||||
configuration and help end-to-end test the application
|
||||
* Third party code can be packaged as reusable modules.
|
||||
* The modules can be loaded in any/parallel order (due to delayed nature of module execution).
|
||||
|
||||
|
||||
# The Basics
|
||||
|
||||
Ok, I'm in a hurry how do i get a Hello World module working?
|
||||
|
||||
Important things to notice:
|
||||
|
||||
* {@link api/angular.Module Module} API
|
||||
* Notice the reference to the `myApp` module in the `<html ng-app="myApp">`, it is what
|
||||
bootstraps the app using your module.
|
||||
|
||||
<doc:example module='simpleApp'>
|
||||
<doc:source>
|
||||
<script>
|
||||
// declare a module
|
||||
var simpleAppModule = angular.module('simpleApp', []);
|
||||
|
||||
// configure the module.
|
||||
// in this example we will create a greeting filter
|
||||
simpleAppModule.filter('greet', function() {
|
||||
return function(name) {
|
||||
return 'Hello, ' + name + '!';
|
||||
};
|
||||
});
|
||||
|
||||
</script>
|
||||
<div>
|
||||
{{ 'World' | greet }}
|
||||
</div>
|
||||
</doc:source>
|
||||
</doc:example>
|
||||
|
||||
|
||||
|
||||
# Recommended Setup
|
||||
|
||||
While the example above is simple, it will not scale to large applications. Instead we recommend
|
||||
that you break your application to multiple modules like this:
|
||||
|
||||
* A service module, for service declaration
|
||||
* A directive module, for directive declaration
|
||||
* A filter module, for filter declaration
|
||||
* And an application level module which depends on the above modules, and which has
|
||||
initialization code.
|
||||
|
||||
The reason for this breakup is that in your tests, it is often necessary to ignore the
|
||||
initialization code, which tends to be difficult to test. By putting it into separate module it
|
||||
can be easily ignored in tests. The tests can also be more focused by only loading the modules
|
||||
which are relevant to tests.
|
||||
|
||||
The above is only a suggestion, so feel free to tailor it to your needs.
|
||||
|
||||
<doc:example module='xmpl'>
|
||||
<doc:source>
|
||||
<script>
|
||||
angular.module('xmpl.service', []).
|
||||
value('greeter', {
|
||||
salutation: 'Hello',
|
||||
localize: function(localization) {
|
||||
this.salutation = localization.salutation;
|
||||
},
|
||||
greet: function(name) {
|
||||
return this.salutation + ' ' + name + '!';
|
||||
}
|
||||
}).
|
||||
value('user', {
|
||||
load: function(name) {
|
||||
this.name = name;
|
||||
}
|
||||
});
|
||||
|
||||
angular.module('xmpl.directive', []);
|
||||
|
||||
angular.module('xmpl.filter', []);
|
||||
|
||||
angular.module('xmpl', ['xmpl.service', 'xmpl.directive', 'xmpl.filter']).
|
||||
run(function(greeter, user) {
|
||||
// This is effectively part of the main method initialization code
|
||||
greeter.localize({
|
||||
salutation: 'Bonjour'
|
||||
});
|
||||
user.load('World');
|
||||
})
|
||||
|
||||
|
||||
// A Controller for your app
|
||||
var XmplController = function($scope, greeter, user) {
|
||||
$scope.greeting = greeter.greet(user.name);
|
||||
}
|
||||
</script>
|
||||
<div ng-controller="XmplController">
|
||||
{{ greeting }}!
|
||||
</div>
|
||||
</doc:source>
|
||||
</doc:example>
|
||||
|
||||
|
||||
|
||||
# Module Loading & Dependencies
|
||||
|
||||
A module is a collection of configuration and run blocks which get applied to the application
|
||||
during the bootstrap process. In its simplest form the module consist of collection of two kinds
|
||||
of blocks:
|
||||
|
||||
1. **Configuration blocks** - get executed during the provider registrations and configuration
|
||||
phase. Only providers and constants can be injected into configuration blocks. This is to
|
||||
prevent accidental instantiation of services before they have been fully configured.
|
||||
2. **Run blocks** - get executed after the injector is created and are used to kickstart the
|
||||
application. Only instances and constants can be injected into run blocks. This is to prevent
|
||||
further system configuration during application run time.
|
||||
|
||||
<pre>
|
||||
angular.module('myModule', []).
|
||||
config(function(injectables) { // provider-injector
|
||||
// This is an example of config block.
|
||||
// You can have as many of these as you want.
|
||||
// You can only inject Providers (not instances)
|
||||
// into the config blocks.
|
||||
}).
|
||||
run(function(injectables) { // instance-injector
|
||||
// This is an example of a run block.
|
||||
// You can have as many of these as you want.
|
||||
// You can only inject instances (not Providers)
|
||||
// int the run blocks
|
||||
});
|
||||
</pre>
|
||||
|
||||
## Configuration Blocks
|
||||
|
||||
There are some convenience methods on the module which are equivalent to the config block. For
|
||||
example:
|
||||
|
||||
<pre>
|
||||
angular.module('myModule', []).
|
||||
value('a', 123).
|
||||
factory('a', function() { return 123; }).
|
||||
directive('directiveName', ...).
|
||||
filter('filterName', ...);
|
||||
|
||||
// is same as
|
||||
|
||||
angular.module('myModule', []).
|
||||
config(function($provide, $compileProvider, $filterProvider) {
|
||||
$provide.value('a', 123)
|
||||
$provide.factory('a', function() { return 123; })
|
||||
$compileProvider.directive('directiveName', ...).
|
||||
$filterProvider.register('filterName', ...);
|
||||
});
|
||||
</pre>
|
||||
|
||||
The configuration blocks get applied in the order in which they are registered. The only exception
|
||||
to it are constant definitions, which are placed at the beginning of all configuration blocks.
|
||||
|
||||
## Run Blocks
|
||||
|
||||
Run blocks are the closest thing in Angular to the main method. A run block is the code which
|
||||
needs to run to kickstart the application. It is executed after all of the service have been
|
||||
configured and the injector has been created. Run blocks typically contain code which is hard
|
||||
to unit-test, and for this reason should be declared in isolated modules, so that they can be
|
||||
ignored in the unit-tests.
|
||||
|
||||
## Dependencies
|
||||
|
||||
Modules can list other modules as their dependencies. Depending on a module implies that required
|
||||
module needs to be loaded before the requiring module is loaded. In other words the configuration
|
||||
blocks of the required modules execute before the configuration blocks or the requiring module.
|
||||
The same is true for the run blocks. Each module can only be loaded once, even if multiple other
|
||||
modules require it.
|
||||
|
||||
## Asynchronous Loading
|
||||
|
||||
Modules are a way of managing $injector configuration, and have nothing to do with loading of
|
||||
scripts into a VM. There are existing projects which deal with script loading, which may be used
|
||||
with Angular. Because modules do nothing at load time they can be loaded into the VM in any order
|
||||
and thus script loaders can take advantage of this property and paralyze the loading process.
|
||||
|
||||
|
||||
# Unit Testing
|
||||
|
||||
In its simplest form a unit-test is a way of instantiating a subset of the application in test and
|
||||
then applying a stimulus to it. It is important to realize that each module can only be loaded
|
||||
once per injector. Typically an app has only one injector. But in tests, each test has its own
|
||||
injector, which means that the modules are loaded multiple times per VM. Properly structured
|
||||
modules can help with unit testing, as in this example:
|
||||
|
||||
In all of these examples we are going to assume this module definition:
|
||||
<pre>
|
||||
angular.module('greetMod', []).
|
||||
|
||||
factory('alert', function($window) {
|
||||
return function(text) {
|
||||
$window.alert(text);
|
||||
}
|
||||
}).
|
||||
|
||||
value('salutation', 'Hello').
|
||||
|
||||
factory('greet', function(alert, salutation) {
|
||||
return function(name) {
|
||||
alert(salutation + ' ' + name + '!');
|
||||
}
|
||||
});
|
||||
</pre>
|
||||
|
||||
Let's write some tests:
|
||||
<pre>
|
||||
describe('myApp', function() {
|
||||
// load the application relevant modules then load a special
|
||||
// test module which overrides the $window with mock version,
|
||||
// so that calling window.alert() will not block the test
|
||||
// runner with a real alert box. This is an example of overriding
|
||||
// configuration information in tests.
|
||||
beforeEach(module('greetMod', function($provide) {
|
||||
$provide.value('$window', {
|
||||
alert: jasmine.createSpy('alert')
|
||||
});
|
||||
});
|
||||
|
||||
// The inject() will create the injector and inject the greet and
|
||||
// $window into the tests. The test need not concern itself with
|
||||
// wiring of the application, only with testing it.
|
||||
it('should alert on $window', inject(function(greet, $window) {
|
||||
greet('World');
|
||||
expect($window.alert).toHaveBeenCalledWith('Hello World!');
|
||||
}));
|
||||
|
||||
// this is another way of overriding configuration in the
|
||||
// tests using an inline module and inject methods.
|
||||
it('should alert using the alert service', function() {
|
||||
var alertSpy = jasmine.createSpy('alert');
|
||||
module(function($provide) {
|
||||
$provide.value('alert', alertSpy);
|
||||
});
|
||||
inject(function(greet) {
|
||||
greet('World');
|
||||
expect(alertSpy).toHaveBeenCalledWith('World');
|
||||
});
|
||||
});
|
||||
});
|
||||
</pre>
|
||||
@@ -2,20 +2,22 @@
|
||||
@name Contributing
|
||||
@description
|
||||
|
||||
<a name="H1_1"></a>
|
||||
# Open Source
|
||||
|
||||
`Angular` is an open source project licensed under the {@link
|
||||
http://github.com/angular/angular.js/blob/master/LICENSE MIT license}. Your contributions are
|
||||
always welcome. When working with `angular` source base, please follow the guidelines provided on
|
||||
this page.
|
||||
|
||||
* <a href="#H1_1">License</a>
|
||||
* <a href="#H1_2">Contributing to Source Code</a>
|
||||
* <a href="#H1_3">Applying Code Standards</a>
|
||||
* <a href="#H1_4">Checking Out and Building `Angular`</a>
|
||||
* <a href="#H1_5">Submitting Your Changes</a>
|
||||
|
||||
|
||||
<a name="H1_1"></a>
|
||||
# License
|
||||
|
||||
`Angular` is an open source project licensed under the {@link
|
||||
http://github.com/angular/angular.js/blob/master/LICENSE MIT license}. Your contributions are
|
||||
always welcome. When working with `angular` source base, please follow the guidelines provided on
|
||||
this page.
|
||||
|
||||
|
||||
<a name="H1_2"></a>
|
||||
# Contributing to Source Code
|
||||
@@ -27,6 +29,7 @@ today! Here are the guidelines we'd like you to use:
|
||||
https://groups.google.com/forum/?hl=en#!forum/angular mailing list} so that we can better
|
||||
coordinate our efforts, prevent duplication of work, and help you to craft the change so that it
|
||||
is successfully accepted upstream.
|
||||
|
||||
* Small changes and bug fixes can be crafted and submitted to Github as a <a href="#H1_5">pull
|
||||
request</a>.
|
||||
|
||||
@@ -38,21 +41,28 @@ request</a>.
|
||||
To ensure consistency throughout the source code, keep these rules in mind as you are working:
|
||||
|
||||
* All features or bug fixes must be tested by one or more <a href="#unit-tests">specs</a>.
|
||||
|
||||
* All public API methods must be documented with ngdoc, an extended version of jsdoc (we added
|
||||
support for markdown and templating via `@ngdoc` tag). To see how we document our APIs, please
|
||||
check out the existing ngdocs.
|
||||
|
||||
* With the exceptions listed below, we follow the rules contained in {@link
|
||||
http://google-styleguide.googlecode.com/svn/trunk/javascriptguide.xml Google's JavaScript Style
|
||||
Guide}:
|
||||
|
||||
* Do not use namespaces: Instead, we wrap the entire `angular` code base in an anonymous closure
|
||||
and export our API explicitly rather than implicitly.
|
||||
|
||||
* Wrap all code at 100 characters.
|
||||
|
||||
* Instead of complex inheritance hierarchies, we prefer simple objects. We use prototypical
|
||||
inheritance only when absolutely necessary.
|
||||
|
||||
* We love functions and closures and, whenever possible, prefer them over objects.
|
||||
|
||||
* To write concise code that can be better minified, internally we use aliases that map to the
|
||||
external API. See our existing code to see what we mean.
|
||||
|
||||
* We don't go crazy with type annotations for private internal APIs unless it's an internal API
|
||||
that is used throughout `angular`. The best guidance is to do what makes the most sense.
|
||||
|
||||
@@ -77,9 +87,20 @@ Rake website.
|
||||
development web server. Depending on your system, you can install Node either from source or as a
|
||||
pre-packaged bundle.
|
||||
|
||||
You'll also need npm and the following npm modules:
|
||||
|
||||
* install npm: `curl http://npmjs.org/install.sh | sh`
|
||||
* install q: `npm install q`
|
||||
* install qq: `npm install qq`
|
||||
* install q-fs: `npm install q-fs`
|
||||
* install jasmine-node: `npm install jasmine`
|
||||
|
||||
|
||||
|
||||
* Java: The Java runtime is used to run {@link http://code.google.com/p/js-test-driver
|
||||
JsTestDriver} (JSTD), which we use to run our unit test suite. JSTD binaries are part of the
|
||||
`angular` source base, which means there is no need to install or configure it separately.
|
||||
|
||||
* Git: The {@link http://help.github.com/mac-git-installation Github Guide to Installing Git} is
|
||||
quite a good source for information on Git.
|
||||
|
||||
@@ -115,14 +136,21 @@ minified `angular` files:
|
||||
The build output can be located under the `build` directory. It consists of the following files and
|
||||
directories:
|
||||
|
||||
* `angular-x.y.z-<git sha>.tgz` — This is the complete tarball, which contains all of the release
|
||||
build artifacts.
|
||||
* `angular-<version>.tgz` — This is the complete tarball, which contains all of the release build
|
||||
artifacts.
|
||||
|
||||
* `angular.js` — The non-minified `angular` script.
|
||||
|
||||
* `angular.min.js` — The minified `angular` script.
|
||||
|
||||
* `angular-scenario.js` — The `angular` End2End test runner.
|
||||
|
||||
* `angular-ie-compat.js` — The Internet Explorer compatibility patch file.
|
||||
|
||||
* `docs/` — A directory that contains all of the files needed to run `docs.angularjs.org`.
|
||||
|
||||
* `docs/index.html` — The main page for the documentation.
|
||||
|
||||
* `docs/docs-scenario.html` — The End2End test runner for the documentation application.
|
||||
|
||||
|
||||
@@ -158,7 +186,7 @@ tests:
|
||||
|
||||
3. To trigger a test execution, run:
|
||||
|
||||
./test.sh
|
||||
./test.sh
|
||||
|
||||
4. To automatically run the test suite each time one or more of the files in the project directory
|
||||
is changed, you can install `watchr` and then run:
|
||||
@@ -214,19 +242,20 @@ To create and submit a change:
|
||||
|
||||
8. When the patch is reviewed and merged, delete your branch and pull yours — and other — changes
|
||||
from the main (upstream) repository:
|
||||
* To delete the branch in Github, run:
|
||||
|
||||
1. To delete the branch in Github, run:
|
||||
|
||||
git push origin :my-fix-branch
|
||||
|
||||
* To check out the master branch, run:
|
||||
2. To check out the master branch, run:
|
||||
|
||||
git checkout master
|
||||
|
||||
* To delete a local branch, run:
|
||||
3. To delete a local branch, run:
|
||||
|
||||
git branch -D my-fix-branch
|
||||
|
||||
* To update your master with the latest upstream version, run:
|
||||
4. To update your master with the latest upstream version, run:
|
||||
|
||||
git pull --ff upstream master
|
||||
|
||||
@@ -0,0 +1,70 @@
|
||||
@ngdoc overview
|
||||
@name Downloading
|
||||
@description
|
||||
|
||||
# Including angular scripts from the angular server
|
||||
The quickest way to get started is to point your html `<script>` tag to a
|
||||
<http://code.angularjs.org/> URL. This way, you don't have to download anything or maintain a
|
||||
local copy.
|
||||
|
||||
There are two types of angular script URLs you can point to, one for development and one for
|
||||
production:
|
||||
|
||||
* __angular-<version>.js__ — This is the human-readable, non-minified version, suitable for web
|
||||
development.
|
||||
* __angular-<version>.min.js__ — This is the minified version, which we strongly suggest you use in
|
||||
production.
|
||||
|
||||
To point your code to an angular script on the angular server, use the following template. This
|
||||
example points to (non-minified) version 0.10.6:
|
||||
|
||||
<pre>
|
||||
<!doctype html>
|
||||
<html ng-app>
|
||||
<head>
|
||||
<title>My Angular App</title>
|
||||
<script src="http://code.angularjs.org/angular-0.10.6.js"></script>
|
||||
</head>
|
||||
<body>
|
||||
</body>
|
||||
</html>
|
||||
</pre>
|
||||
|
||||
|
||||
# Downloading and hosting angular files locally
|
||||
This option is for those who want to work with angular offline, or those who want to host the
|
||||
angular files on their own servers.
|
||||
|
||||
If you navigate to <http://code.angularjs.org/>, you'll see a directory listing with all of the
|
||||
angular versions since we started releasing versioned build artifacts (quite late in the project
|
||||
lifetime). Each directory contains all artifacts that we released for a particular version.
|
||||
Download the version you want and have fun.
|
||||
|
||||
Each directory under <http://code.angularjs.org/> includes the following set of files:
|
||||
|
||||
* __`angular-<version>.js`__ — This file is non-obfuscated, non-minified, and human-readable by
|
||||
opening it it any editor or browser. In order to get better error messages during development, you
|
||||
should always use this non-minified angular script.
|
||||
|
||||
* __`angular-<version>.min.js`__ — This is a minified and obfuscated version of
|
||||
`angular-<version>.js` created with the Closure compiler. Use this version for production in order
|
||||
to minimize the size of the application that is downloaded by your user's browser.
|
||||
|
||||
* __`angular-<version>.tgz`__ — This is a tarball archive that contains all of the files released
|
||||
for this angular version. Use this file to get everything in a single download.
|
||||
|
||||
* __`angular-ie-compat-<version>.js`__ — This is a special file that contains code and data
|
||||
specifically tailored for getting Internet Explorer to work with angular. If you host your own copy
|
||||
of angular files, make sure that this file is available for download, and that it resides under the
|
||||
same parent path as `angular-<version>.js` or `angular-<version>.min.js`.
|
||||
|
||||
* __`angular-mocks-<version>.js`__ — This file contains an implementation of mocks that makes
|
||||
testing angular apps even easier. Your unit/integration test harness should load this file after
|
||||
`angular-<version>.js` is loaded.
|
||||
|
||||
* __`angular-scenario-<version>.js`__ — This file is a very nifty JavaScript file that allows you
|
||||
to write and execute end-to-end tests for angular applications.
|
||||
|
||||
* __`docs-<version>`__ — this directory contains all the files that compose the
|
||||
<http://docs.angularjs.org/> documentation app. These files are handy to see the older version of
|
||||
our docs, or even more importantly, view the docs offline.
|
||||
@@ -1,4 +1,3 @@
|
||||
@workInProgress
|
||||
@ngdoc overview
|
||||
@name FAQ
|
||||
@description
|
||||
@@ -29,7 +28,7 @@ attacks. angular does round-trip escaping on all strings for you.
|
||||
|
||||
### Can I download the source, build, and host the angular environment locally?
|
||||
|
||||
Yes. See instructions in {@link downloading downloading}.
|
||||
Yes. See instructions in {@link downloading}.
|
||||
|
||||
### Is angular a templating system?
|
||||
|
||||
@@ -63,18 +62,19 @@ in angular.
|
||||
|
||||
Yes, angular uses {@link http://jquery.com/ jQuery}, the open source DOM manipulation library.
|
||||
If jQuery is not present in your script path, angular falls back on its own implementation of
|
||||
{@link angular.element jQuery lite}. If jQuery is present in the path, angular uses it to
|
||||
{@link api/angular.element jQuery lite}. If jQuery is present in the path, angular uses it to
|
||||
manipulate the DOM.
|
||||
|
||||
### What is testability like in angular?
|
||||
|
||||
Very testable. It has an integrated dependency injection framework. See
|
||||
{@link angular.service service} for details.
|
||||
{@link api/angular.module.ng service} for details.
|
||||
|
||||
### How can I learn more about angular?
|
||||
|
||||
Watch the July 28, 2010 talk
|
||||
"{@link http://www.youtube.com/watch?v=elvcgVSynRg| Angular: A Radically Different Way of Building AJAX Apps}".
|
||||
"{@link http://www.youtube.com/watch?v=elvcgVSynRg| Angular: A Radically Different Way of Building
|
||||
AJAX Apps}".
|
||||
|
||||
### How is angular licensed?
|
||||
|
||||
@@ -0,0 +1,143 @@
|
||||
@ngdoc overview
|
||||
@name Getting Started
|
||||
@description
|
||||
|
||||
# Hello World!
|
||||
|
||||
A great way for you to get started with AngularJS is to create the tradtional
|
||||
"Hello World!" app:
|
||||
|
||||
1. In your favorite text editor, create an HTML file
|
||||
(for example, `helloworld.html`).
|
||||
2. From the __Source__ box below, copy and paste the code into your HTML file.
|
||||
(Double-click on the source to easily select all.)
|
||||
3. Open the file in your web browser.
|
||||
|
||||
<doc:example>
|
||||
<doc:source>
|
||||
Hello {{'World'}}!
|
||||
</doc:source>
|
||||
</doc:example>
|
||||
|
||||
The resulting web page should look something like the following:
|
||||
|
||||
<img class="center" src="img/helloworld.png" border="1">
|
||||
|
||||
Now let's take a closer look at that code, and see what is going on behind
|
||||
the scenes.
|
||||
|
||||
The `ng-app` tags tells angular to process the entire HTML page and bootstrap the app when the page
|
||||
is loaded:
|
||||
|
||||
<pre>
|
||||
<html ng-app>
|
||||
</pre>
|
||||
|
||||
The next line downloads the angular script:
|
||||
|
||||
<pre>
|
||||
<script src="http://code.angularjs.org/angular-?.?.?.min.js"></script>
|
||||
</pre>
|
||||
|
||||
(For details on what happens when angular processes an HTML page,
|
||||
see {@link guide/dev_guide.bootstrap Bootstrap}.)
|
||||
|
||||
Finally, this line in the `<body>` of the page is the template that describes
|
||||
how to display our greeting in the UI:
|
||||
|
||||
<pre>
|
||||
Hello {{'World'}}!
|
||||
</pre>
|
||||
|
||||
Note the use of the double curly brace markup (`{{ }}`) to bind the expression to
|
||||
the greeting text. Here the expression is the string literal 'World'.
|
||||
|
||||
Next let's look at a more interesting example, that uses AngularJS to
|
||||
bind a dynamic expression to our greeting text.
|
||||
|
||||
# Hello AngularJS World!
|
||||
|
||||
This example demonstrates angular's two-way data binding:
|
||||
|
||||
1. Edit the HTML file you created in the "Hello World!" example above.
|
||||
2. Replace the contents of `<body>` with the code from the __Source__ box below.
|
||||
3. Refresh your browser window.
|
||||
|
||||
<doc:example>
|
||||
<doc:source>
|
||||
Your name: <input type="text" ng-model="yourname" value="World"/>
|
||||
<hr/>
|
||||
Hello {{yourname}}!
|
||||
</doc:source>
|
||||
</doc:example>
|
||||
|
||||
After the refresh, the page should look something like this:
|
||||
|
||||
<img class="left" src="img/helloworld_2way.png" border="1" />
|
||||
|
||||
These are some of the important points to note from this example:
|
||||
|
||||
* The text input {@link api/angular.module.ng.$compileProvider.directive directive}
|
||||
is bound to a model variable called `yourname`.
|
||||
* The double curly braces notation binds the `yourname` model to the greeting text.
|
||||
|
||||
* You did not need to explicitly register an event listener or define an event handler for events!
|
||||
|
||||
Now try typing your name into the input box, and notice the immediate change to
|
||||
the displayed greeting. This demonstrates the concept of angular's
|
||||
{@link guide/dev_guide.templates.databinding bi-directional data binding}. Any changes to the input
|
||||
field are immediately
|
||||
reflected in the model (one direction), and any changes to the model are
|
||||
reflected in the greeting text (the other direction).
|
||||
|
||||
|
||||
# Anatomy Of An Angular App
|
||||
|
||||
This section describes the 3 parts of an angular app, and explains how they map to the
|
||||
Model-View-Controller design pattern:
|
||||
|
||||
## Templates
|
||||
|
||||
Templates, which you write in HTML and CSS, serve as the View. You add elements, attributes, and
|
||||
markup to HTML, which serve as instructions to the angular compiler. The angular compiler is fully
|
||||
extensible, meaning that with angular you can build your own declarative language on top of HTML!
|
||||
|
||||
|
||||
## Application Logic and Behavior
|
||||
|
||||
Application Logic and Behavior, which you define in JavaScript, serve as the Controller. With
|
||||
angular (unlike with standard AJAX applications) you don't need to write additional listeners or
|
||||
DOM manipulators, because they are built-in. This feature makes your application logic very easy to
|
||||
write, test, maintain, and understand.
|
||||
|
||||
|
||||
## Data
|
||||
|
||||
The Model is referenced from properties on {@link guide/dev_guide.scopes angular scope objects}.
|
||||
The data in your model could be Javascript objects, arrays, or primitives, it doesn't matter. What
|
||||
matters is that these are all referenced by the scope object.
|
||||
|
||||
Angular employs scopes to keep your data model and your UI in sync. Whenever something occurs to
|
||||
change the state of the model, angular immediately reflects that change in the UI, and vice versa.
|
||||
|
||||
The following illustration shows the parts of an angular application and how they work together:
|
||||
|
||||
<img class="left" src="img/angular_parts.png" border="0" />
|
||||
|
||||
In addition, angular comes with a set of Services, which have the following properties:
|
||||
|
||||
* The services provided are very useful for building web applications.
|
||||
* You can extend and add application-specific behavior to services.
|
||||
* Services include Dependency-Injection, XHR, caching, URL routing, and browser abstraction.
|
||||
|
||||
|
||||
# Where To Go Next
|
||||
|
||||
* If you like what you've learned so far, you should definitely check out our awesome {@link
|
||||
tutorial/ Tutorial}, which walks you through the process of building real apps with AngularJS.
|
||||
|
||||
* For further explanations and examples of the AngularJS concepts presented on this page, see the
|
||||
{@link guide/index Developer Guide}.
|
||||
|
||||
* For additional hands-on examples of using AngularJS, including more source code that you can
|
||||
copy and paste into your own pages, take a look through the {@link cookbook/ Cookbook}.
|
||||
@@ -1,103 +0,0 @@
|
||||
@workInProgress
|
||||
@ngdoc overview
|
||||
@name Cookbook: Form
|
||||
@description
|
||||
|
||||
A web application's main purpose is to present and gather data. For this reason angular strives
|
||||
to make both of these operations trivial. This example shows off how you can build a simple form to
|
||||
allow a user to enter data.
|
||||
|
||||
|
||||
<doc:example>
|
||||
<doc:source>
|
||||
<script>
|
||||
function FormController(){
|
||||
this.user = {
|
||||
name: 'John Smith',
|
||||
address:{line1: '123 Main St.', city:'Anytown', state:'AA', zip:'12345'},
|
||||
contacts:[{type:'phone', value:'1(234) 555-1212'}]
|
||||
};
|
||||
this.state = /^\w\w$/;
|
||||
this.zip = /^\d\d\d\d\d$/;
|
||||
}
|
||||
</script>
|
||||
<div ng:controller="FormController" class="example">
|
||||
|
||||
<label>Name:</label><br/>
|
||||
<input type="text" name="user.name" ng:required/> <br/><br/>
|
||||
|
||||
<label>Address:</label><br/>
|
||||
<input type="text" name="user.address.line1" size="33" ng:required/> <br/>
|
||||
<input type="text" name="user.address.city" size="12" ng:required/>,
|
||||
<input type="text" name="user.address.state" size="2" ng:required ng:validate="regexp:state"/>
|
||||
<input type="text" name="user.address.zip" size="5" ng:required ng:validate="regexp:zip"/><br/><br/>
|
||||
|
||||
<label>Phone:</label>
|
||||
[ <a href="" ng:click="user.contacts.$add()">add</a> ]
|
||||
<div ng:repeat="contact in user.contacts">
|
||||
<select name="contact.type">
|
||||
<option>email</option>
|
||||
<option>phone</option>
|
||||
<option>pager</option>
|
||||
<option>IM</option>
|
||||
</select>
|
||||
<input type="text" name="contact.value" ng:required/>
|
||||
[ <a href="" ng:click="user.contacts.$remove(contact)">X</a> ]
|
||||
</div>
|
||||
<hr/>
|
||||
Debug View:
|
||||
<pre>user={{user}}</pre>
|
||||
</div>
|
||||
|
||||
</doc:source>
|
||||
<doc:scenario>
|
||||
it('should show debug', function(){
|
||||
expect(binding('user')).toMatch(/John Smith/);
|
||||
});
|
||||
it('should add contact', function(){
|
||||
using('.example').element('a:contains(add)').click();
|
||||
using('.example div:last').input('contact.value').enter('you@example.org');
|
||||
expect(binding('user')).toMatch(/\(234\) 555\-1212/);
|
||||
expect(binding('user')).toMatch(/you@example.org/);
|
||||
});
|
||||
|
||||
it('should remove contact', function(){
|
||||
using('.example').element('a:contains(X)').click();
|
||||
expect(binding('user')).not().toMatch(/\(234\) 555\-1212/);
|
||||
});
|
||||
|
||||
it('should validate zip', function(){
|
||||
expect(using('.example').element(':input[name=user.address.zip]').attr('className'))
|
||||
.not().toMatch(/ng-validation-error/)
|
||||
|
||||
using('.example').input('user.address.zip').enter('abc');
|
||||
|
||||
expect(using('.example').element(':input[name=user.address.zip]').attr('className'))
|
||||
.toMatch(/ng-validation-error/)
|
||||
});
|
||||
|
||||
it('should validate state', function(){
|
||||
expect(using('.example').element(':input[name=user.address.state]').attr('className'))
|
||||
.not().toMatch(/ng-validation-error/)
|
||||
|
||||
using('.example').input('user.address.state').enter('XXX');
|
||||
|
||||
expect(using('.example').element(':input[name=user.address.state]').attr('className'))
|
||||
.toMatch(/ng-validation-error/)
|
||||
});
|
||||
</doc:scenario>
|
||||
</doc:example>
|
||||
|
||||
|
||||
# Things to notice
|
||||
|
||||
* The user data model is initialized {@link angular.ng:controller controller} and is available in
|
||||
the {@link angular.scope scope} with the initial data.
|
||||
* For debugging purposes we have included a debug view of the model to better understand what
|
||||
is going on.
|
||||
* The {@link angular.widget.HTML input widgets} simply refer to the model and are auto bound.
|
||||
* The inputs {@link angular.validator validate}. (Try leaving them blank or entering non digits
|
||||
in the zip field)
|
||||
* In your application you can simply read from or write to the model and the form will be updated.
|
||||
* By clicking the 'add' link you are adding new items into the `user.contacts` array which are then
|
||||
reflected in the view.
|
||||
@@ -1,105 +0,0 @@
|
||||
@workInProgress
|
||||
@ngdoc overview
|
||||
@name Cookbook: Advanced Form
|
||||
@description
|
||||
|
||||
Here we extend the basic form example to include common features such as reverting, dirty state
|
||||
detection, and preventing invalid form submission.
|
||||
|
||||
<doc:example>
|
||||
<doc:source>
|
||||
<script>
|
||||
UserForm.$inject = ['$invalidWidgets'];
|
||||
function UserForm($invalidWidgets){
|
||||
this.$invalidWidgets = $invalidWidgets;
|
||||
this.state = /^\w\w$/;
|
||||
this.zip = /^\d\d\d\d\d$/;
|
||||
this.master = {
|
||||
name: 'John Smith',
|
||||
address:{
|
||||
line1: '123 Main St.',
|
||||
city:'Anytown',
|
||||
state:'AA',
|
||||
zip:'12345'
|
||||
},
|
||||
contacts:[
|
||||
{type:'phone', value:'1(234) 555-1212'}
|
||||
]
|
||||
};
|
||||
this.cancel();
|
||||
}
|
||||
|
||||
UserForm.prototype = {
|
||||
cancel: function(){
|
||||
this.form = angular.copy(this.master);
|
||||
},
|
||||
|
||||
save: function(){
|
||||
this.master = this.form;
|
||||
this.cancel();
|
||||
}
|
||||
};
|
||||
</script>
|
||||
<div ng:controller="UserForm">
|
||||
|
||||
<label>Name:</label><br/>
|
||||
<input type="text" name="form.name" ng:required/> <br/><br/>
|
||||
|
||||
<label>Address:</label><br/>
|
||||
<input type="text" name="form.address.line1" size="33" ng:required/> <br/>
|
||||
<input type="text" name="form.address.city" size="12" ng:required/>,
|
||||
<input type="text" name="form.address.state" size="2" ng:required ng:validate="regexp:state"/>
|
||||
<input type="text" name="form.address.zip" size="5" ng:required ng:validate="regexp:zip"/><br/><br/>
|
||||
|
||||
<label>Phone:</label>
|
||||
[ <a href="" ng:click="form.contacts.$add()">add</a> ]
|
||||
<div ng:repeat="contact in form.contacts">
|
||||
<select name="contact.type">
|
||||
<option>email</option>
|
||||
<option>phone</option>
|
||||
<option>pager</option>
|
||||
<option>IM</option>
|
||||
</select>
|
||||
<input type="text" name="contact.value" ng:required/>
|
||||
[ <a href="" ng:click="form.contacts.$remove(contact)">X</a> ]
|
||||
</div>
|
||||
<button ng:click="cancel()" disabled="{{master.$equals(form)}}">Cancel</button>
|
||||
<button ng:click="save()" disabled="{{$invalidWidgets.visible() || master.$equals(form)}}">Save</button>
|
||||
|
||||
<hr/>
|
||||
Debug View:
|
||||
<pre>form={{form}}
|
||||
master={{master}}</pre>
|
||||
</div>
|
||||
</doc:source>
|
||||
<doc:scenario>
|
||||
it('should enable save button', function(){
|
||||
expect(element(':button:contains(Save)').attr('disabled')).toBeTruthy();
|
||||
input('form.name').enter('');
|
||||
expect(element(':button:contains(Save)').attr('disabled')).toBeTruthy();
|
||||
input('form.name').enter('change');
|
||||
expect(element(':button:contains(Save)').attr('disabled')).toBeFalsy();
|
||||
element(':button:contains(Save)').click();
|
||||
expect(element(':button:contains(Save)').attr('disabled')).toBeTruthy();
|
||||
});
|
||||
it('should enable cancel button', function(){
|
||||
expect(element(':button:contains(Cancel)').attr('disabled')).toBeTruthy();
|
||||
input('form.name').enter('change');
|
||||
expect(element(':button:contains(Cancel)').attr('disabled')).toBeFalsy();
|
||||
element(':button:contains(Cancel)').click();
|
||||
expect(element(':button:contains(Cancel)').attr('disabled')).toBeTruthy();
|
||||
expect(element(':input[name=form.name]').val()).toEqual('John Smith');
|
||||
});
|
||||
</doc:scenario>
|
||||
</doc:example>
|
||||
|
||||
|
||||
#Things to notice
|
||||
|
||||
* Cancel & save buttons are only enabled if the form is dirty -- there is something to cancel or
|
||||
save.
|
||||
* Save button is only enabled if there are no validation errors on the form.
|
||||
* Cancel reverts the form changes back to original state.
|
||||
* Save updates the internal model of the form.
|
||||
* Debug view shows the two models. One presented to the user form and the other being the pristine
|
||||
copy master.
|
||||
@@ -1,125 +0,0 @@
|
||||
@workInProgress
|
||||
@ngdoc overview
|
||||
@name Cookbook: MVC
|
||||
@description
|
||||
|
||||
MVC allows for a clean an testable separation between the behavior (controller) and the view
|
||||
(HTML template). A Controller is just a JavaScript class which is grafted onto the scope of the
|
||||
view. This makes it very easy for the controller and the view to share the model.
|
||||
|
||||
The model is simply the controller's this. This makes it very easy to test the controller in
|
||||
isolation since one can simply instantiate the controller and test without a view, because there is
|
||||
no connection between the controller and the view.
|
||||
|
||||
|
||||
<doc:example>
|
||||
<doc:source>
|
||||
<script>
|
||||
function TicTacToeCntl(){
|
||||
this.cellStyle= {
|
||||
'height': '20px',
|
||||
'width': '20px',
|
||||
'border': '1px solid black',
|
||||
'text-align': 'center',
|
||||
'vertical-align': 'middle',
|
||||
'cursor': 'pointer'
|
||||
};
|
||||
this.reset();
|
||||
this.$watch('$location.hashSearch.board', this.readUrl);
|
||||
}
|
||||
TicTacToeCntl.prototype = {
|
||||
dropPiece: function(row, col) {
|
||||
if (!this.winner && !this.board[row][col]) {
|
||||
this.board[row][col] = this.nextMove;
|
||||
this.nextMove = this.nextMove == 'X' ? 'O' : 'X';
|
||||
this.setUrl();
|
||||
}
|
||||
},
|
||||
reset: function(){
|
||||
this.board = [
|
||||
['', '', ''],
|
||||
['', '', ''],
|
||||
['', '', '']
|
||||
];
|
||||
this.nextMove = 'X';
|
||||
this.winner = '';
|
||||
this.setUrl();
|
||||
},
|
||||
grade: function(){
|
||||
var b = this.board;
|
||||
this.winner =
|
||||
row(0) || row(1) || row(2) ||
|
||||
col(0) || col(1) || col(2) ||
|
||||
diagonal(-1) || diagonal(1);
|
||||
function row(r) { return same(b[r][0], b[r][1], b[r][2]);}
|
||||
function col(c) { return same(b[0][c], b[1][c], b[2][c]);}
|
||||
function diagonal(i) { return same(b[0][1-i], b[1][1], b[2][1+i]);}
|
||||
function same(a, b, c) { return (a==b && b==c) ? a : '';};
|
||||
},
|
||||
setUrl: function(){
|
||||
var rows = [];
|
||||
angular.forEach(this.board, function(row){
|
||||
rows.push(row.join(','));
|
||||
});
|
||||
this.$location.hashSearch.board = rows.join(';') + '/' + this.nextMove;
|
||||
},
|
||||
readUrl: function(value) {
|
||||
if (value) {
|
||||
value = value.split('/');
|
||||
this.nextMove = value[1];
|
||||
angular.forEach(value[0].split(';'), function(row, i){
|
||||
this.board[i] = row.split(',');
|
||||
}, this);
|
||||
this.grade();
|
||||
} else {
|
||||
this.reset();
|
||||
}
|
||||
}
|
||||
};
|
||||
</script>
|
||||
<h3>Tic-Tac-Toe</h3>
|
||||
<div ng:controller="TicTacToeCntl">
|
||||
Next Player: {{nextMove}}
|
||||
<div class="winner" ng:show="winner">Player {{winner}} has won!</div>
|
||||
<table class="board">
|
||||
<tr ng:repeat="row in board" style="height:15px;">
|
||||
<td ng:repeat="cell in row" ng:style="cellStyle"
|
||||
ng:click="dropPiece($parent.$index, $index)">{{cell}}</td>
|
||||
</tr>
|
||||
</table>
|
||||
<button ng:click="reset()">reset board</button>
|
||||
</div>
|
||||
</doc:source>
|
||||
<doc:scenario>
|
||||
it('should play a game', function(){
|
||||
piece(1, 1);
|
||||
expect(binding('nextMove')).toEqual('O');
|
||||
piece(3, 1);
|
||||
expect(binding('nextMove')).toEqual('X');
|
||||
piece(1, 2);
|
||||
piece(3, 2);
|
||||
piece(1, 3);
|
||||
expect(element('.winner').text()).toEqual('Player X has won!');
|
||||
});
|
||||
|
||||
function piece(row, col) {
|
||||
element('.board tr:nth-child('+row+') td:nth-child('+col+')').click();
|
||||
}
|
||||
</doc:scenario>
|
||||
</doc:example>
|
||||
|
||||
|
||||
# Things to notice
|
||||
|
||||
* The controller is defined in JavaScript and has no reference to the rendering logic.
|
||||
* The controller is instantiated by <angular/> and injected into the view.
|
||||
* The controller can be instantiated in isolation (without a view) and the code will still execute.
|
||||
This makes it very testable.
|
||||
* The HTML view is a projection of the model. In the above example, the model is stored in the
|
||||
board variable.
|
||||
* All of the controller's properties (such as board and nextMove) are available to the view.
|
||||
* Changing the model changes the view.
|
||||
* The view can call any controller function.
|
||||
* In this example, the `setUrl()` and `readUrl()` functions copy the game state to/from the URL's
|
||||
hash so the browser's back button will undo game steps. See deep-linking. This example calls
|
||||
{@link angular.Scope.$watch $watch()} to set up a listener that invokes `readUrl()` when needed.
|
||||
@@ -1,70 +0,0 @@
|
||||
@workInProgress
|
||||
@ngdoc overview
|
||||
@name Downloading
|
||||
@description
|
||||
|
||||
# Including angular scripts from code.angularjs.org
|
||||
|
||||
To get started quickly you without worrying about downloading anything and maintaining a local copy,
|
||||
you can point your html `script` tag directly to <http://code.angularjs.org/> urls.
|
||||
|
||||
There are two kinds of urls you care about:
|
||||
|
||||
* http://code.angularjs.org/angular-<version>.js
|
||||
* http://code.angularjs.org/angular-<version>.min.js
|
||||
|
||||
The first one is non-minified version, suitable for web development. The latter one is minified
|
||||
version, which we strongly suggest you use in production.
|
||||
|
||||
To point your code to let's say angular version 0.9.12, use the following template:
|
||||
|
||||
<pre>
|
||||
<!doctype html>
|
||||
<html>
|
||||
<head>
|
||||
<title>My Angular App</title>
|
||||
<script src="http://code.angularjs.org/angular-0.9.12.js" ng:autobind></script>
|
||||
</head>
|
||||
<body>
|
||||
</body>
|
||||
</html>
|
||||
</pre>
|
||||
|
||||
|
||||
# Downloading and hosting the files on your own
|
||||
|
||||
This options is for those who want to work with angular offline, or want to host the angular files
|
||||
on their own servers.
|
||||
|
||||
If you navigate to <http://code.angularjs.org/>, you'll see a directory listing with all angular
|
||||
versions since we started releasing versioned build artifacts (quite late in the project lifetime).
|
||||
|
||||
Each directory contains all artifacts that we released for a particular version. Once you navigate
|
||||
to one of these directories you'll see the following list of files:
|
||||
|
||||
* `angular-<version>.js` - This file is non-obfuscated, non-minified, and human-readable by opening
|
||||
it it any editor or browser. In order to get better error messages during development, you should
|
||||
always use this non-minified angular script.
|
||||
|
||||
* `angular-<version>.min.js` - This is a minified and obfuscated version of
|
||||
`angular-<version>.js` created with Closure compiler. Use this version for production in order to
|
||||
minimize the size of the application that is downloaded by your user's browser.
|
||||
|
||||
* `angular-<version>.tgz` - This is a tarball archive which contains all the other files released
|
||||
for this angular version. Use this file to get everything in a single download.
|
||||
|
||||
* `angular-ie-compat-<version>.js` - This is a special file that contains code and data specifically
|
||||
tailored for getting Internet Explorer to work with angular. If you host your own copy of angular
|
||||
files, make sure that this file is available for download and resides under the same parent path as
|
||||
`angular-<version>.js` or `angular-<version>.min.js`.
|
||||
|
||||
* `angular-mocks-<version>.js` - This file contains implementation of mocks that we provide to you
|
||||
to make testing angular apps even easier. Your unit/integration test harness should load this file
|
||||
after `angular-<version>.js` is loaded.
|
||||
|
||||
* `angular-scenario-<version>.js` - This file is a very nifty JavaScript file, which allows you to
|
||||
write and execute end to end tests for angular applications.
|
||||
|
||||
* `docs-<version>` - this directory contains all the files that compose the
|
||||
<http://docs.angularjs.org/> documentation app. These files are handy to see the older version of
|
||||
our docs, or even more importantly, view the docs offline!
|
||||
@@ -0,0 +1,2 @@
|
||||
controller: {{name}}<br />
|
||||
Book Id: {{params.bookId}}<br />
|
||||
@@ -0,0 +1,3 @@
|
||||
controller: {{name}}<br />
|
||||
Book Id: {{prams.bookId}}<br />
|
||||
Chapter Id: {{params.chapterId}}
|
||||
@@ -0,0 +1 @@
|
||||
Hello, $http!
|
||||
@@ -0,0 +1 @@
|
||||
Content of template1.html
|
||||
@@ -0,0 +1 @@
|
||||
Content of template2.html
|
||||
@@ -1,13 +1,13 @@
|
||||
<label>Name:</label>
|
||||
<input type="text" name="form.name" ng:required>
|
||||
<input type="text" ng:model="form.name" required>
|
||||
|
||||
<div ng:repeat="contact in form.contacts">
|
||||
<select name="contact.type">
|
||||
<select ng:model="contact.type">
|
||||
<option>url</option>
|
||||
<option>email</option>
|
||||
<option>phone</option>
|
||||
</select>
|
||||
<input type="text" name="contact.url">
|
||||
<input type="text" ng:model="contact.url">
|
||||
[ <a href="" ng:click="form.contacts.$remove(contact)">X</a> ]
|
||||
</div>
|
||||
<div>
|
||||
@@ -15,4 +15,4 @@
|
||||
</div>
|
||||
|
||||
<button ng:click="cancel()">Cancel</button>
|
||||
<button ng:click="save()">Save</button>
|
||||
<button ng:click="save()">Save</button>
|
||||
@@ -1,97 +0,0 @@
|
||||
@workInProgress
|
||||
@ngdoc overview
|
||||
@name Developer Guide: Bootstrap
|
||||
@description
|
||||
|
||||
# Bootstrap
|
||||
This section explains how to bootstrap your application to the angular environment using either
|
||||
the `angular.js` or `angular.min.js` script.
|
||||
|
||||
## The bootstrap code
|
||||
|
||||
Note that there are two versions of the bootstrap code that you can use:
|
||||
|
||||
* `angular-0.0.0.js` - this file is unobfuscated, uncompressed, and thus human-readable.
|
||||
* `angular-0.0.0.min.js` - this is a compressed and obfuscated version of angular-debug.js.
|
||||
|
||||
In this section and throughout the Developer Guide, feel free to use `angular.min.js` instead of
|
||||
`angular.js` when working through code examples.
|
||||
|
||||
## ng:autobind
|
||||
|
||||
The simplest way to get an angular application up and running is by inserting a script tag in your
|
||||
HTML file that bootstraps the `angular.js` code and uses the special `ng:autobind` attribute,
|
||||
like in this snippet of HTML:
|
||||
|
||||
<doc:example>
|
||||
<doc:source>
|
||||
Hello {{'World'}}!
|
||||
</doc:source>
|
||||
</doc:example>
|
||||
|
||||
The `ng:autobind` attribute tells angular to compile and manage the whole HTML document. The
|
||||
compilation occurs in the page's onLoad handler. Note that you don't need to explicitly add an
|
||||
onLoad event; auto bind mode takes care of all the magic for you.
|
||||
|
||||
## Manual bind
|
||||
|
||||
Using autobind mode is a handy way to start using angular, but advanced users who want more
|
||||
control over the initialization process might prefer to use manual bind mode instead.
|
||||
|
||||
The best way to get started with manual bind mode is to look at the magic behind `ng:autobind`
|
||||
by writing out each step of the autobind process explicitly. Note that the following code is
|
||||
equivalent to the code in the previous section.
|
||||
|
||||
<pre>
|
||||
<!DOCTYPE HTML>
|
||||
<html xmlns:ng="http://angularjs.org">
|
||||
<script type="text/javascript" src="http://code.angularjs.org/angular-0.0.0.min.js"></script>
|
||||
<script type="text/javascript">
|
||||
(function(window, previousOnLoad){
|
||||
window.onload = function(){
|
||||
try { (previousOnLoad||angular.noop)(); } catch(e) {}
|
||||
angular.compile(window.document)();
|
||||
};
|
||||
})(window, window.onload);
|
||||
</script>
|
||||
<body>
|
||||
Hello {{'World'}}!
|
||||
</body>
|
||||
</html>
|
||||
</pre>
|
||||
|
||||
This is the sequence that your code should follow if you're writing your own manual binding code:
|
||||
|
||||
* After the page is loaded, find the root of the HTML template, which is typically the root of
|
||||
the document.
|
||||
* Run the HTML compiler, which converts the templates into an executable, bi-directionally
|
||||
bound application.
|
||||
|
||||
|
||||
# XML Namespace
|
||||
|
||||
**IMPORTANT:** When using angular you must declare the `ng` namespace using the `xmlns` tag.
|
||||
If you don't declare the namespace, Internet Explorer does not render widgets properly.
|
||||
|
||||
<pre>
|
||||
<html xmlns:ng="http://angularjs.org">
|
||||
</pre>
|
||||
|
||||
|
||||
# Create your own namespace
|
||||
|
||||
If you want to define your own widgets, you must create your own namespace and use that namespace
|
||||
to form the fully qualified widget name. For example, you could map the alias my to your domain
|
||||
and create a widget called my:widget. To create your own namespace, simply add another xmlns tag
|
||||
to your page, create an alias, and set it to your unique domain:
|
||||
|
||||
<pre>
|
||||
<html xmlns:my="http://mydomain.com">
|
||||
</pre>
|
||||
|
||||
|
||||
# Global Object
|
||||
|
||||
The angular script creates a single global variable `angular` in the global namespace. All APIs are
|
||||
bound to fields of this global object.
|
||||
|
||||
@@ -1,163 +0,0 @@
|
||||
@workInProgress
|
||||
@ngdoc overview
|
||||
@name Developer Guide: Compiler
|
||||
@description
|
||||
|
||||
#Compiler
|
||||
|
||||
While angular might look like just a cool way to build web applications, the core of angular is
|
||||
actually an HTML compiler. The default HTML transformations that this compiler provides are useful
|
||||
for building generic apps, but you can also use them to create a domain-specific language for
|
||||
building specific types of web applications.
|
||||
|
||||
The compiler allows you to add behavior to existing HTML through widgets, directives, and text
|
||||
markup.
|
||||
|
||||
All of this compilation happens in the web browser, meaning no server is involved.
|
||||
|
||||
# The compilation process
|
||||
This section describes the steps that angular's HTML compiler goes through. If you use
|
||||
`ng:autobind` in your application, this compilation process happens automatically when the
|
||||
application is initialized (e.g. when the user loads the app in a browser). If you're an advanced
|
||||
user using manual bind mode, you can decide when and how often the compilation happens.
|
||||
|
||||
First, a bit of background of what the compilation step is for. Every type of
|
||||
{@link angular.widget widget}, {@link angular.markup markup}, and
|
||||
{@link angular.directive directive} in angular is defined with a compile function, and that
|
||||
compile function returns an optional link function. Here is the relationship between the two:
|
||||
|
||||
* **compile function** - registers a listener for the widget, markup, or directive's expression.
|
||||
This function is called exactly once.
|
||||
* **link function** - sets up the listener. This function can be called multiple times, once per
|
||||
cloned DOM element (e.g. repeating element).
|
||||
|
||||
Note that angular's built-in widgets, markup, and directives have predefined compile and link
|
||||
functions that you don't need to modify. However, if you're writing your own widgets, markup, or
|
||||
directives, you write compile and link functions. Refer to the Compiler API for more information.
|
||||
|
||||
When the HTML compiler compiles a page, it goes through 3 phases: Compile, Create Root Scope, and
|
||||
Link.
|
||||
|
||||
## 1. Compile Phase
|
||||
|
||||
* Recursively traverse the DOM, depth-first.
|
||||
* Look for a matching compile function of type widget, then markup, then directive.
|
||||
* If a compile function is found then execute it.
|
||||
* When the compile function completes, it should return a link function. Aggregate this link
|
||||
function with all link functions returned previously by step 1c.
|
||||
* Repeat steps 1c and 1d for all compile functions found. The result of the compilation step is
|
||||
the aggregate link function, which comprises all of the individual link functions.
|
||||
|
||||
## 2. Create Root Scope
|
||||
|
||||
* Inject all of the services into the root scope.
|
||||
|
||||
## 3. Link Phase
|
||||
|
||||
* Execute the aggregate link function with the root scope. The aggregate link function calls all
|
||||
the individual link functions that were generated in the compile phase.
|
||||
* If there are any clones of the DOM caused by repeating elements, call the link function multiple
|
||||
times, one for each repeating item.
|
||||
|
||||
Note that while the compile function is executed exactly once, the link function can be executed
|
||||
multiple times: once for each iteration in a repeater.
|
||||
|
||||
# Example
|
||||
|
||||
The compilation process is best understood through example. Let's say that in your namespace my,
|
||||
you want to create a new DOM element <my:greeter/>, which should display a greeting.
|
||||
|
||||
If we want this HTML source:
|
||||
|
||||
<pre>
|
||||
<div ng:init="salutation='Hello'; name='World'">
|
||||
<my:greeter salutation="salutation" name="name"/>
|
||||
</div>
|
||||
</pre>
|
||||
|
||||
To produce this DOM:
|
||||
|
||||
<pre>
|
||||
<div ng:init="salutation='Hello'; name='World'">
|
||||
<my:greeter salutation="salutation" name="name"/>
|
||||
<span class="salutation">Hello</span>
|
||||
<span class="name">World</span>!
|
||||
</my:greeter>
|
||||
</div>
|
||||
</pre>
|
||||
|
||||
Write this widget definition (assuming you've already declared the my namespace in the page):
|
||||
|
||||
|
||||
<pre>
|
||||
angular.widget('my:greeter', function(compileElement){
|
||||
var compiler = this;
|
||||
compileElement.css('display', 'block');
|
||||
var salutationExp = compileElement.attr('salutation');
|
||||
var nameExp = compileElement.attr('name');
|
||||
return function(linkElement){
|
||||
var salutationSpan = angular.element('<span class="salutation"></span');
|
||||
var nameSpan = angular.element('<span class="name"></span>');
|
||||
linkElement.append(salutationSpan);
|
||||
linkElement.append(compiler.text(' '));
|
||||
linkElement.append(nameSpan);
|
||||
linkElement.append(compiler.text('!'));
|
||||
this.$watch(salutationExp, function(value){
|
||||
salutationSpan.text(value);
|
||||
});
|
||||
this.$watch(nameExp, function(value){
|
||||
nameSpan.text(value);
|
||||
});
|
||||
};
|
||||
});
|
||||
</pre>
|
||||
|
||||
Note: For more about widgets, see {@link angular.widget Widget}.
|
||||
|
||||
## Compilation process for this example
|
||||
|
||||
Here are the steps that the compiler goes through for the page that contains this widget definition:
|
||||
|
||||
### Compile Phase
|
||||
|
||||
* Recursively traverse the DOM depth-first.
|
||||
* Find the angular.widget definition.
|
||||
* Find and execute the widget's compileElement function, which includes the following steps:
|
||||
* Add a style element with attribute display: block; to the template DOM so that the browser
|
||||
knows to treat the element as block element for rendering. (Note: because this style element
|
||||
was added on the template compileElement, this style is automatically applied to any clones
|
||||
of the template (i.e. any repeating elements)).
|
||||
* Extract the salutation and name HTML attributes as angular expressions.
|
||||
* Return the aggregate link function, which includes just one link function in this example.
|
||||
|
||||
### Link Phase
|
||||
|
||||
* Execute the aggregate link function, which includes the following steps:
|
||||
* Create a <span> element set to the salutation class
|
||||
* Create a <span> element set to the name class.
|
||||
* Add the span elements to the linkElement. (Note: be careful not to add them to the
|
||||
compileElement, because that's the template.)
|
||||
* Set up watches on the expressions. When an expression changes, copy the data to the
|
||||
corresponding spans.
|
||||
|
||||
|
||||
## Compiler API
|
||||
|
||||
If you define your own widgets, markup, or directives, you need to access the compiler API.
|
||||
This section describes the methods on the compiler that you can call.
|
||||
|
||||
Note: As of 12 August 2010, these methods are subject to change.
|
||||
|
||||
Recall that the compile function's this is a reference to the compiler.
|
||||
|
||||
* `compile(element)` - returns `linker` - Invoke new instance of compiler to compile a DOM element
|
||||
and return a linker function. You can apply the linker function to the original element or a
|
||||
clone of the original element. The linker function returns a scope.
|
||||
* `comment(commentText)` - returns `element` - Create a comment element.
|
||||
* `element(elementName)` - returns `element` - Create an element by name.
|
||||
* `text(text)` - returns `element` - Create a text element.
|
||||
* `descend([set])` - returns `descend` - State Get or set the current descend state. If true the
|
||||
compiler will descend to children elements.
|
||||
* `directives([set])` - returns `directive` - State Get or set the current directives processing
|
||||
state. The compiler will process directives only when directives set to true.
|
||||
|
||||
@@ -1,46 +0,0 @@
|
||||
@workInProgress
|
||||
@ngdoc overview
|
||||
@name Developer Guide: CSS
|
||||
@description
|
||||
|
||||
# CSS
|
||||
angular includes built-in CSS classes, which in turn have predefined CSS styles.
|
||||
|
||||
# Built-in CSS classes
|
||||
|
||||
## `ng-exception`
|
||||
|
||||
**Usage:** angular applies this class to a DOM element if that element contains an Expression that
|
||||
threw an exception when evaluated.
|
||||
|
||||
**Styling:** The built-in styling of the ng-exception class displays an error message surrounded
|
||||
by a solid red border, for example:
|
||||
|
||||
> <div class="ng-exception">Error message</div>
|
||||
|
||||
|
||||
|
||||
You can try to evaluate malformed expressions in {@link angualr.expression expression} to see the
|
||||
`ng-exception` class' styling.
|
||||
|
||||
## `ng-validation-error`
|
||||
|
||||
**Usage:** angular applies this class to an input widget element if that element's input does not
|
||||
pass validation. Note that you set the validation criteria on the input widget element using the
|
||||
Ng:validate or Ng:required directives.
|
||||
|
||||
**Styling:** The built-in styling of the ng-validation-error class turns the border of the input
|
||||
box red and includes a hovering UI element that includes more details of the validation error. You
|
||||
can see an example in {@link angular.widget.@ng:validate ng:validate example}.
|
||||
|
||||
## How to override the styles for built-in classes
|
||||
|
||||
To override the styles for these built-in classes, you can do any of the following:
|
||||
|
||||
Download the source code, edit angular.css, and host the source on your own server.
|
||||
Create a local css file, overriding any styles that you'd like, and link to it from your HTML file
|
||||
as you normally would:
|
||||
|
||||
<pre>
|
||||
<link href="yourfile.css" rel="stylesheet" type="text/css">
|
||||
</pre>
|
||||
@@ -1,41 +0,0 @@
|
||||
@workInProgress
|
||||
@ngdoc overview
|
||||
@name Developer Guide: Data Binding
|
||||
@description
|
||||
|
||||
# Data Binding
|
||||
|
||||
Data-binding allows you to treat the model as the single-source-of-truth of your application, and
|
||||
consider the view as only a projection of the model, at all times. The process of copying the model
|
||||
values to the view, and any changes to the view by the user to the model, is known as data-binding.
|
||||
|
||||
## Classical Template Systems
|
||||
|
||||
<img class="right" src="img/One_Way_Data_Binding.png"/>
|
||||
At the highest level, angular looks like a just another templating system. But there is one
|
||||
important reason why angular templating system is different and makes it very good fit for
|
||||
application development: two-way data binding.
|
||||
|
||||
Most templating systems bind data in only one direction: they merge a template and model together
|
||||
into a view, as illustrated in the diagram to the right. After the merge occurs, any changes to
|
||||
the model or in related sections of the view are NOT automatically reflected in the view. Worse,
|
||||
any changes that the user makes to the view are not reflected in the model. This means that the
|
||||
developer has to write code that constantly syncs the view with the model and the model with the
|
||||
view.
|
||||
|
||||
|
||||
# angular Template Systems
|
||||
<img class="right" src="img/Two_Way_Data_Binding.png"/>
|
||||
The way angular templates works is different, as illustrated in the diagram on the right. They are
|
||||
different because first the template (which is the uncompiled HTML along with any additional markup
|
||||
or directives) is compiled on the browser, and second, the compilation step produces a live view.
|
||||
We say live because any changes to the view are immediately reflected in the model, and any changes
|
||||
in the model are propagated to the view. This makes the model always the single-source-of-truth for
|
||||
the application state, greatly simplifying the programing model for the developer. You can think of
|
||||
the view as simply an instant projection of your model.
|
||||
|
||||
Because the view is just a projection of the model, the controller is completely separated from the
|
||||
view and unaware of it. This makes testing a snap because it is easy to test your controller in
|
||||
isolation without the view and the related DOM/browser dependency.
|
||||
|
||||
For details about how data binding works in angular, see {@link angular.scope Scope}.
|
||||
@@ -1,304 +0,0 @@
|
||||
@workInProgress
|
||||
@ngdoc overview
|
||||
@name Developer Guide: Dependency Injection
|
||||
@description
|
||||
Dependency injection (DI) is one of the core design patterns in angular and angular applications. DI
|
||||
allows you to replace almost any part of angular framework or angular application with a custom
|
||||
implementation, allowing for a highly flexible, maintainable and testable code-base.
|
||||
|
||||
Dependency injection is a very common pattern in Java and other statically typed languages. While
|
||||
undervalued among JavaScript developers, we feel strongly that DI in JavaScript allows us to achieve
|
||||
the same benefits as in other languages.
|
||||
|
||||
This document will focus on using dependency injection in angular. It is outside of the scope of
|
||||
this document to explain details of dependency injection. For more information on this topic, please
|
||||
refer to these links:
|
||||
|
||||
* {@link http://en.wikipedia.org/wiki/Dependency_injection DI - Wikipedia}
|
||||
* {@link http://martinfowler.com/articles/injection.html Inversion of Control by Martin Fowler}
|
||||
* Java
|
||||
* {@link http://code.google.com/p/google-guice/ Guice}
|
||||
* {@link http://www.devshed.com/c/a/Java/The-Spring-Framework-Understanding-IoC/ Spring}
|
||||
* {@link http://picocontainer.org/injection.html picoContainer}
|
||||
* .NET
|
||||
* {@link http://msdn.microsoft.com/en-us/magazine/cc163739.aspx MSDN Design Patterns - Dependency Inject}
|
||||
* {@link http://www.springframework.net/ Spring.NET}
|
||||
|
||||
|
||||
|
||||
# Dependency Injection in angular
|
||||
|
||||
Angular's dependency injection story begins with a `service`. Service in angular lingo is a
|
||||
JavaScript object, function, or value that is created by angular's injector via a provided factory
|
||||
function. The factory function is registered with angular via {@link angular.service}.
|
||||
|
||||
<pre>
|
||||
// register a factory for a uniqueId service.
|
||||
angular.service('uniqueId', function(){
|
||||
// calling the factory function creates the instance function
|
||||
var id = 0;
|
||||
return function(){
|
||||
// calling the counter instance function will return and increment the count
|
||||
return ++id;
|
||||
}
|
||||
});
|
||||
</pre>
|
||||
|
||||
At run-time we can access the `uniqueId` service by looking it up with the service locator like
|
||||
this:
|
||||
|
||||
<pre>
|
||||
// create new root scope which has the injector function `$service()`
|
||||
var scope = angular.scope();
|
||||
|
||||
// use the `$service` function to look up the service instance function
|
||||
var idGenerator = scope.$service('uniqueId');
|
||||
expect(idGenerator()).toBe(1);
|
||||
|
||||
// subsequent lookups using the same root scope return the service instance
|
||||
var idGenerator2 = scope.$service('uniqueId');
|
||||
expect(idGenerator).toBe(idGenerator2);
|
||||
|
||||
// since it is same instance calling idGenerator2 returns 2;
|
||||
expect(idGenerator2()).toBe(2);
|
||||
</pre>
|
||||
|
||||
The {@link angular.service service} registry seems like a lot of work, so what are the benefits? To
|
||||
answer this question, it’s important to realize that in large scale applications there are a lot of
|
||||
services which are often dependent on each other, as in this example:
|
||||
|
||||
<pre>
|
||||
angular.service('gadgetFactory', function(uniqueId){
|
||||
return function(){
|
||||
return {gadgetId: uniqueId()};
|
||||
};
|
||||
}, {$inject: ['uniqueId']});
|
||||
</pre>
|
||||
|
||||
Specifically, notice that the `gadgetFactory` takes `uniqueId` service in its arguments. It also
|
||||
declares this dependency with the `$inject` property. There are several benefits to this approach:
|
||||
|
||||
* There is no need for a `main` method for an application responsible for instantiating and wiring
|
||||
these services. The order of service instantiation and wiring can be inferred by examining the
|
||||
`$inject` annotations.
|
||||
* It is easy to replace any one service with a different implementation without having to track down
|
||||
all of the dependencies. This is useful in:
|
||||
* Tests: when mocks of services are needed (for example using mock {@link angular.service.$xhr}.)
|
||||
* Customization: when the service bundled with angular does not do exactly what the application
|
||||
requires.
|
||||
|
||||
More importantly, as we'll soon learn, controllers and other components of angular applications can
|
||||
also declare their dependencies on services and these will be provided without explicitly looking
|
||||
them up, but let's not get ahead of ourselves.
|
||||
|
||||
Lastly, it is important to realize that all angular services are singletons – application singletons
|
||||
to be more precise. This means that there is only one instance of a given service per injector. And
|
||||
since angular is lethally allergic to the global state, it's absolutely possible to create multiple
|
||||
injectors each with its own instance of a given service (but that is not typically needed, except in
|
||||
tests where this property is crucially important).
|
||||
|
||||
|
||||
## Service Locator and Scope
|
||||
|
||||
The {@link angular.injector injector} is responsible for resolving the service dependencies in the
|
||||
application. It gets created and configured with the creation of a root scope in your application.
|
||||
The injector is responsible for caching the instances of services, but this cache is bound to the
|
||||
scope. This means that different root scopes will have different instances of the injector. While
|
||||
typical angular applications will only have one root scope (and hence the services will act like
|
||||
application singletons), in tests it is important to not share singletons across test invocations
|
||||
for isolation reasons. We get this isolation by having each test create its own separate root scope.
|
||||
|
||||
<pre>
|
||||
// crate a root scope
|
||||
var rootScope = angular.scope();
|
||||
// accesss the service locator
|
||||
var myService = rootScope.$service('myService');
|
||||
</pre>
|
||||
|
||||
|
||||
|
||||
# Dependency Injection in Controllers
|
||||
|
||||
So far we have been talking about injector as a service locator. This is because we have been
|
||||
explicitly calling the `$service` method to gain access to the service. Service locator is not
|
||||
dependency injection since the caller is still responsible for retrieving the dependencies. *True
|
||||
dependency injection is like Chuck Norris. Chuck does not ask for dependencies; he declares them.*
|
||||
|
||||
The most common place to use dependency injection in angular applications is in
|
||||
{@link angular.ng:controller controllers}. Here’s a simple example:
|
||||
|
||||
<pre>
|
||||
function MyController($route){
|
||||
// configure the route service
|
||||
$route.when(...);
|
||||
}
|
||||
MyController.$inject = ['$route'];
|
||||
</pre>
|
||||
|
||||
In this example, the `MyController` constructor function takes one argument, the
|
||||
{@link angular.service.$route $route} service. Angular is then responsible for supplying the
|
||||
instance of `$route` to the controller when the constructor is instantiated. There are two ways to
|
||||
cause controller instantiation – by configuring routes with the $route service or by referencing the
|
||||
controller from the HTML template, such as:
|
||||
|
||||
<pre>
|
||||
<!doctype html>
|
||||
<html xmlns:ng="http://angularjs.org" ng:controller="MyController">
|
||||
<script src="http://code.angularjs.org/angular.min.js" ng:autobind></script>
|
||||
<body>
|
||||
...
|
||||
</body>
|
||||
</html>
|
||||
</pre>
|
||||
|
||||
When angular is instantiating your controller, it needs to know what services, if any, should be
|
||||
injected (passed in as arguments) into the controller. Since there is no reflection in JavaScript,
|
||||
we have to supply this information to angular in the form of an additional property on the
|
||||
controller constructor function called `$inject`. Think of it as annotations for JavaScript.
|
||||
|
||||
<pre>
|
||||
MyController.$inject = ['$route'];
|
||||
</pre>
|
||||
|
||||
The information in `$inject` is then used by the {@link angular.injector injector} to call the
|
||||
function with the correct arguments.
|
||||
|
||||
|
||||
|
||||
# Using Dependency Injection pragmatically
|
||||
|
||||
At times you’ll need to use dependency injection pragmatically, usually when instantiating
|
||||
controllers manually or writing unit tests. This section explains how to go about it.
|
||||
|
||||
## Retrieving Services
|
||||
|
||||
The simplest form of dependency injection is manual retrieval of scopes, known as service locator.
|
||||
We say manual because we are asking the injector for an instance of the service (rather then having
|
||||
the injector provide them to the function). This should be rare since most of the time the dependent
|
||||
services should be injected into the controller using the `$inject` property array.
|
||||
|
||||
<pre>
|
||||
// create a root scope. The root scope will automatically have
|
||||
// `$service` method defined which is configured with all services.
|
||||
// Each instance of root scope will have separate instances of services.
|
||||
var rootScope = angular.scope();
|
||||
|
||||
// ask for a service explicitly
|
||||
var $window = rootScope.$service('$window');
|
||||
</pre>
|
||||
|
||||
|
||||
## Creating Controllers using Dependency Injection
|
||||
|
||||
In a typical angular application the dependency injection is most commonly used when creating
|
||||
controllers.
|
||||
<pre>
|
||||
// declare our own service by registering a factory function.
|
||||
angular.service('counter', function(){
|
||||
var count = 0;
|
||||
return function(){ return count++; };
|
||||
});
|
||||
|
||||
// example of a controller which depends on '$window' and 'counter' service
|
||||
// notice that there is an extra unbound parameter 'name' which will not
|
||||
// be injected and must be supplied by the caller.
|
||||
function MyController($window, counter, name) {
|
||||
}
|
||||
|
||||
// we must declare the dependencies explicitly and in the same order as in
|
||||
// the constructor function. This information is used by the dependency
|
||||
// injection to supply the arguments.
|
||||
// Notice the lack of 'name' argument which makes it an unbound argument.
|
||||
MyController.$inject = ['$window', 'counter'];
|
||||
|
||||
|
||||
// Create a root scope which creates the the injector
|
||||
var rootScope = angular.scope();
|
||||
|
||||
// use the '$new()' method instead of standard 'new' keyword operator to
|
||||
// create an instance of MyController and have the dependency injection
|
||||
// supply the arguments to the controller. The dependency injection only
|
||||
// supplies the bound arguments in `$inject` all addition arguments are
|
||||
// curried from the '$new', in our case 'Alexandria' is the argument which
|
||||
// will be curried to the 'name' argument, while '$window' and 'counter'
|
||||
// are supplied by the dependency injection.
|
||||
var myController = rootScope.$new(MyController, 'Alexandria');
|
||||
// NOTE: the returning controller will be a child scope of parent scope,
|
||||
// in this case the root scope.
|
||||
</pre>
|
||||
|
||||
|
||||
## Calling functions and Curring of arguments
|
||||
|
||||
NOTE: this section is quite lame. The concept it is trying to describe is more closely related to
|
||||
scope#new than scope#$service. We need a better example to discuss here. Ideally a parent controller
|
||||
creating a child controller imperatively via $new where the child controller's constructor function
|
||||
declares a portion of its dependencies via $inject property, but another portion is supplied by the
|
||||
caller of $new (e.g. parentCtrl.$new(ChildCtrl, configParam1, configParam2);
|
||||
|
||||
Finally, you may need to call functions but have the `$inject` properties of the function be
|
||||
supplied by the injector.
|
||||
|
||||
<pre>
|
||||
// create a root scope with the `$service` injector.
|
||||
var rootScope = angular.scope();
|
||||
|
||||
// given a function such as
|
||||
function greet ($window, name) {
|
||||
$window.alert(this.salutation + ' ' + name);
|
||||
}
|
||||
greet.$inject = ['$window'];
|
||||
|
||||
// you can call function 'greet' such that the injector supplies the
|
||||
// '$window' and the caller supplies the function 'this' and the 'name'
|
||||
// argument.
|
||||
var fnThis = {salutation: 'Hello'}
|
||||
rootScope.$service(greet, fnThis, 'world');
|
||||
</pre>
|
||||
|
||||
|
||||
|
||||
# Inferring `$inject`
|
||||
|
||||
**EXPERIMENTAL: this is an experimental feature, see the important note at the end of this section
|
||||
for drawbacks.**
|
||||
|
||||
We resort to `$inject` and our own annotation because there is no way in JavaScript to get a list of
|
||||
arguments. Or is there? It turns out that calling `.toString()` on a function returns the function
|
||||
declaration along with the argument names as shown below:
|
||||
|
||||
<pre>
|
||||
function myFn(a,b){}
|
||||
expect(myFn.toString()).toEqual('function myFn(a,b){}');
|
||||
</pre>
|
||||
|
||||
This means that angular can infer the function names after all and use that information to generate
|
||||
the `$inject` annotation automatically. Therefore the following two function definitions are
|
||||
equivalent:
|
||||
|
||||
<pre>
|
||||
// given a user defined service
|
||||
angular.service('serviceA', ...);
|
||||
|
||||
// inject '$window', 'serviceA', curry 'name';
|
||||
function fnA($window, serviceA, name){};
|
||||
fnA.$inject = ['$window', 'serviceA'];
|
||||
|
||||
// inject '$window', 'serviceA', curry 'name';
|
||||
function fnB($window, serviceA_, name){};
|
||||
// implies: fnB.$inject = ['$window', 'serviceA'];
|
||||
</pre>
|
||||
|
||||
If angular does not find an `$inject` annotation on the function, then it calls the `.toString()`
|
||||
and tries to infer what should be injected using the following rules:
|
||||
|
||||
* any argument starting with `$` is angular service and will be added to `$inject` property array.
|
||||
* any argument ending with `_` will be added to the `$inject` property array but we strip the `_`
|
||||
* all arguments following an argument which has neither `$` nor `_` , must not have `$` nor `_`
|
||||
(these are free arguments for {@link http://en.wikipedia.org/wiki/Currying curring})
|
||||
|
||||
**IMPORTANT**
|
||||
Minifiers/obfuscators change the names of function arguments and will therefore break the `$inject`
|
||||
inference. For this reason, either explicitly declare the `$inject` or do not use
|
||||
minifiers/obfuscators. In the future, we may provide a pre-processor which will scan the source code
|
||||
and insert the `$inject` into the source code so that it can be minified/obfuscated.
|
||||
@@ -1,207 +0,0 @@
|
||||
@workInProgress
|
||||
@ngdoc overview
|
||||
@name Developer Guide: Expression
|
||||
@description
|
||||
|
||||
# Expressions
|
||||
Expressions are the bindings that you write in HTML and embed in templates in order to create
|
||||
views in angular. They are not equivalent to JavaScript expressions.
|
||||
|
||||
For example, these are all valid expressions in angular:
|
||||
|
||||
* `1+2={{1+2}}`
|
||||
* `3*10|currency`
|
||||
* `Hello {{name}}!`
|
||||
* `Hello {{'World'}}!`
|
||||
|
||||
|
||||
# angular expressions vs. JS expressions
|
||||
It might be tempting to think of angular view expressions as JavaScript expressions, but that is
|
||||
not entirely correct. angular does not use a simple JavaScript eval of the expression text. You
|
||||
can think of angular expressions as JavaScript expressions with these differences:
|
||||
|
||||
* **Attribute Evaluation:** evaluation of all attributes are against the current scope, not to
|
||||
the global window as in JavaScript.
|
||||
* **Forgiving:** expression evaluation is forgiving to undefined and null, unlike in JavaScript.
|
||||
* **No Control Flow Statements:** you cannot do the following from an angular expression:
|
||||
conditionals, loops, or throw.
|
||||
* **Type Augmentation:** the scope expression evaluator augments built-in types.
|
||||
* **Filters:** you can add filters to an expression, for example to convert raw data into a
|
||||
human-readable format.
|
||||
* **The $:** angular reserves this prefix to differentiate its API names from others.
|
||||
|
||||
If you want to run arbitrary JavaScript code, make it a controller method and call that. If you
|
||||
want to eval an angular expression from JavaScript, use the Scope:$eval() method.
|
||||
|
||||
## Example
|
||||
<doc:example>
|
||||
<doc:source>
|
||||
1+2={{1+2}}
|
||||
</doc:source>
|
||||
<doc:scenario>
|
||||
it('should calculate expression in binding', function(){
|
||||
expect(binding('1+2')).toEqual('3');
|
||||
});
|
||||
</doc:scenario>
|
||||
</doc:example>
|
||||
|
||||
You can try evaluating different expressions here:
|
||||
|
||||
<doc:example>
|
||||
<doc:source>
|
||||
<div ng:init="exprs=[]" class="expressions">
|
||||
Expression:
|
||||
<input type='text' name="expr" value="3*10|currency" size="80"/>
|
||||
<button ng:click="exprs.$add(expr)">Evaluate</button>
|
||||
<ul>
|
||||
<li ng:repeat="expr in exprs">
|
||||
[ <a href="" ng:click="exprs.$remove(expr)">X</a> ]
|
||||
<tt>{{expr}}</tt> => <span ng:bind="$parent.$eval(expr)"></span>
|
||||
</li>
|
||||
</ul>
|
||||
</div>
|
||||
</doc:source>
|
||||
<doc:scenario>
|
||||
it('should allow user expression testing', function(){
|
||||
element('.expressions :button').click();
|
||||
var li = using('.expressions ul').repeater('li');
|
||||
expect(li.count()).toBe(1);
|
||||
expect(li.row(0)).toEqual(["3*10|currency", "$30.00"]);
|
||||
});
|
||||
</doc:scenario>
|
||||
</doc:example>
|
||||
|
||||
# Attribute Evaluation
|
||||
|
||||
Evaluation of all attributes are against the current scope. Unlike JavaScript, where names
|
||||
default to global window properties, angular expressions have to use $window to refer to the
|
||||
global object. E.g. if you want to call alert(), which is defined on window, an expression must
|
||||
use $window.alert(). This is done intentionally to prevent accidental access to the global state
|
||||
(a common source of subtle bugs).
|
||||
|
||||
<doc:example>
|
||||
<doc:source>
|
||||
<div class="example2" ng:init="$window = $service('$window')">
|
||||
Name: <input name="name" type="text" value="World"/>
|
||||
<button ng:click="($window.mockWindow || $window).alert('Hello ' + name)">Greet</button>
|
||||
</div>
|
||||
</doc:source>
|
||||
<doc:scenario>
|
||||
it('should calculate expression in binding', function(){
|
||||
var alertText;
|
||||
this.addFutureAction('set mock', function($window, $document, done) {
|
||||
$window.mockWindow = {
|
||||
alert: function(text){ alertText = text; }
|
||||
};
|
||||
done();
|
||||
});
|
||||
element(':button:contains(Greet)').click();
|
||||
expect(this.addFuture('alert text', function(done) {
|
||||
done(null, alertText);
|
||||
})).toBe('Hello World');
|
||||
});
|
||||
</doc:scenario>
|
||||
</doc:example>
|
||||
|
||||
## Forgiving
|
||||
|
||||
Expression evaluation is forgiving to undefined and null. In JavaScript, evaluating a.b.c throws
|
||||
an exception if a is not an object. While this makes sense for a general purpose language, the
|
||||
expression evaluations are primarily used for data binding, which often look like this: `{{a.b.c}}`.
|
||||
It makes more sense to show nothing than to throw an exception if a is undefined (e.g. perhaps
|
||||
we are waiting for the server response, and it will become defined soon). If expression
|
||||
evaluation wasn't forgiving we'd have to write bindings that clutter the code, for example:
|
||||
`{{((a||{}).b||{}).c}}`
|
||||
|
||||
Similarly, invoking a function a.b.c() on undefined or null simply returns undefined.
|
||||
|
||||
Assignments work the same way in reverse. a.b.c = 10 creates the intermediary objects even if a
|
||||
is undefined.
|
||||
|
||||
|
||||
## No Control Flow Statements
|
||||
|
||||
You cannot write a control flow statement in an expression. The reason behind this is core to
|
||||
the angular philosophy that application logic should be in controllers, not in the view. If you
|
||||
need a conditional (including ternary operators), loop, or to throw from a view expression,
|
||||
delegate to a JavaScript method instead.
|
||||
|
||||
|
||||
## Type Augmentation
|
||||
|
||||
Built-in types have methods like [].push(), but the richness of these methods is limited. Consider
|
||||
the example below, which allows you to do a simple search over a canned set of contacts. The
|
||||
example would be much more complicated if we did not have the Array:$filter(). There is no
|
||||
built-in method on Array called $filter and angular doesn't add it to Array.prototype because that
|
||||
could collide with other JavaScript frameworks.
|
||||
|
||||
For this reason the scope expression evaluator augments the built-in types to make them act like
|
||||
they have extra methods. The actual method for $filter() is angular.Array.filter(). You can call
|
||||
it from JavaScript.
|
||||
|
||||
Extensions: You can further extend the expression vocabulary by adding new methods to
|
||||
`angular.Array` or `angular.String`, etc.
|
||||
|
||||
<doc:example>
|
||||
<doc:source>
|
||||
<div ng:init="friends = [
|
||||
{name:'John', phone:'555-1212'},
|
||||
{name:'Mary', phone:'555-9876'},
|
||||
{name:'Mike', phone:'555-4321'},
|
||||
{name:'Adam', phone:'555-5678'},
|
||||
{name:'Julie', phone:'555-8765'}]"></div>
|
||||
Search: <input name="searchText"/>
|
||||
<table class="example3">
|
||||
<tr><th>Name</th><th>Phone</th><tr>
|
||||
<tr ng:repeat="friend in friends.$filter(searchText)">
|
||||
<td>{{friend.name}}</td>
|
||||
<td>{{friend.phone}}</td>
|
||||
</tr>
|
||||
</table>
|
||||
</doc:source>
|
||||
<doc:scenario>
|
||||
it('should filter the list', function(){
|
||||
var tr = using('table.example3').repeater('tr.ng-attr-widget');
|
||||
expect(tr.count()).toBe(5);
|
||||
input('searchText').enter('a');
|
||||
expect(tr.count()).toBe(2);
|
||||
|
||||
});
|
||||
</doc:scenario>
|
||||
</doc:example>
|
||||
|
||||
## Filters
|
||||
|
||||
When presenting data to the user, you might need to convert the data from its raw format to a
|
||||
user-friendly format. For example, you might have a data object that needs to be formatted
|
||||
according to the locale before displaying it to the user. You can pass expressions through a
|
||||
chain of filters like this:
|
||||
|
||||
<pre>
|
||||
name | uppercase
|
||||
</pre>
|
||||
|
||||
The expression evaluator simply passes the value of name to angular.filter.uppercase.
|
||||
|
||||
Chain filters using this syntax:
|
||||
|
||||
<pre>
|
||||
value | filter1 | filter2
|
||||
</pre>
|
||||
|
||||
You can also pass colon-delimited arguments to filters, for example, to display the number 123
|
||||
with 2 decimal points: 123 | number:2
|
||||
|
||||
# The $
|
||||
|
||||
You might be wondering, what is the significance of the $ prefix? It is simply a prefix that
|
||||
angular chooses to differentiate its API names from others. If angular didn't use $, then
|
||||
evaluating a.length() would return undefined because neither a nor angular define such a property.
|
||||
Consider that in a future version of angular we might choose to add a length method, in which case
|
||||
the behavior of the expression would change. Worse yet, you the developer could create a length
|
||||
property and then we would have collision. This problem exists because angular augments existing
|
||||
objects with additional behavior. By prefixing its additions with $ we are reserving our namespace
|
||||
so that angular developers and developers who use angular can develop in harmony without
|
||||
collisions.
|
||||
|
||||
|
||||
@@ -1,37 +0,0 @@
|
||||
@workInProgress
|
||||
@ngdoc overview
|
||||
@name Developer Guide
|
||||
@description
|
||||
|
||||
* {@link guide.overview Overview} - An overview of angular, including its philosophy and how it
|
||||
works.
|
||||
* {@link guide.bootstrap Bootstrap} - How to bootstrap your application to the angular environment.
|
||||
* {@link guide.template Template} - How to define your application's view using HTML, CSS, and
|
||||
other built-in angular constructs.
|
||||
* {@link guide.compiler Compiler} - All about the HTML compiler that's at the core of angular.
|
||||
* {@link angular.directive Directive} - How to use XML attributes to augment an existing DOM
|
||||
element.
|
||||
* {@link angular.markup Markup} - How to use markup to create shorthand for a widget or a
|
||||
directive. For example, markup is what allows you to use the double curly brace notation
|
||||
`{{}}` to bind expressions to elements.
|
||||
* {@link guide.data-binding Data Binding} - About the mechanism that keeps the model the single
|
||||
source of truth of your application at all times, with the view as a live projection of the
|
||||
model.
|
||||
* {@link angular.filter Filter} - How to format your data for display to the user.
|
||||
* {@link angular.widget Widget} - How to create new DOM elements that the browser doesn't already
|
||||
understand.
|
||||
* {@link angular.validator Validator} - How to validate user input.
|
||||
* {@link angular.formatter Formatter} - How to format stored data to user-readable text and
|
||||
parse the text back to the stored form.
|
||||
* {@link guide.css CSS} - Built-in CSS classes, when angular assigns them, and how to override
|
||||
their styles.
|
||||
* {@link angular.scope Scope} - The model in the model-view-controller design pattern. You can
|
||||
think about scopes as the JavaScript objects that have extra APIs for registering watchers.
|
||||
* {@link guide.expression Expression} - The bindings that are embedded in an angular View.
|
||||
* {@link angular.service Service} - Objects that are wired through dependency injection and then
|
||||
injected into the root scope.
|
||||
* {@link guide.testing Testing}
|
||||
* service:$browser(mock)
|
||||
* {@link downloading Downloading} - How to download, compile, and host the angular
|
||||
environment on your own server.
|
||||
* {@link guide.contribute Contributing} - How to contribute to angular project.
|
||||
@@ -1,337 +0,0 @@
|
||||
@ngdoc overview
|
||||
@name Developer Guide: Overview
|
||||
@description
|
||||
|
||||
|
||||
* <a href="#H1_1">What Is Angular?</a>
|
||||
* <a href="#H1_3">The Angular Philosophy</a>
|
||||
* <a href="#H1_2">Anatomy Of An Angular App</a>
|
||||
* <a href="#H1_4">Why You Want Angular</a>
|
||||
* <a href="#H1_5">Angular's Ancestors</a>
|
||||
* <a href="#H1_6">Watch a Presentation About Angular</a>
|
||||
|
||||
|
||||
<a name="H1_1"></a>
|
||||
# What Is Angular?
|
||||
|
||||
The short answer: angular is a new, powerful, client-side technology that makes it much easier for
|
||||
you to create dynamic web sites and complex web apps, all without leaving the comfort of your HTML
|
||||
/ JavaScript home.
|
||||
|
||||
The long answer: it kind of depends on where you're coming from...
|
||||
|
||||
* If you're a web designer, you might perceive angular to be a sweet {@link guide.template
|
||||
templating} system, that doesn't get in your way and provides you with lots of nice built-ins that
|
||||
make it easier to do what you want to do.
|
||||
|
||||
* If you're a web developer, you might be thrilled that angular functions as an excellent web
|
||||
framework, one that assists you all the way through the development cycle.
|
||||
|
||||
* If you want to go deeper, you can immerse yourself in angular's extensible HTML {@link
|
||||
guide.compiler compiler} that runs in your browser. This compiler teaches your browser new tricks.
|
||||
|
||||
So then, angular's not just a templating system, but you can create fantastic templates with it;
|
||||
angular's not just a web framework, but it has a very nice one; and angular's not just an
|
||||
extensible HTML compiler, but it has one of those too. Let's put it this way: angular includes
|
||||
these parts along with some others; it evolved naturally from earlier occurrences of these forms;
|
||||
and thus angular is something far greater than the sum of its parts. It sounds like... it's alive!
|
||||
|
||||
## An Intro By Way of Example
|
||||
|
||||
Let's say that you are a web designer, and you've spent many thous — erm, hundreds of hours
|
||||
designing web sites. But at this point, the thought of doing DOM updates, writing listeners, and
|
||||
writing input validators, all to do something as simple as implementing a form!? You either don't
|
||||
want to go there in the first place or you've been there and the thrill is gone.
|
||||
|
||||
You could even be muttering to yourself as you hack another callback, "This is like building my own
|
||||
bike from scratch every time I want to ride to the store." But let's say a clever friend, who keeps
|
||||
tabs on these sorts of things, told you to check out angular.
|
||||
|
||||
So now here you are checking out angular, and here is a simple example. Note that it features only
|
||||
the templating aspect of angular, but this should suffice for now to quickly demonstrates how much
|
||||
easier life can be with angular:
|
||||
|
||||
<doc:example>
|
||||
<doc:source>
|
||||
<h2>Bigg Bike Shop</h2>
|
||||
<hr>
|
||||
<b>Invoice:</b>
|
||||
<br/>
|
||||
<br/>
|
||||
<table>
|
||||
<tr><td> </td><td> </td>
|
||||
<tr><td>Quantity</td><td>Cost</td></tr>
|
||||
<tr>
|
||||
<td><input name="qty" value="1" ng:validate="integer:0" ng:required/></td>
|
||||
<td><input name="cost" value="19.95" ng:validate="number" ng:required/></td>
|
||||
</tr>
|
||||
</table>
|
||||
<hr>
|
||||
<b>Total:</b> {{qty * cost | currency}}
|
||||
<hr>
|
||||
</doc:source>
|
||||
<!--
|
||||
<doc:scenario>
|
||||
it('should show of angular binding', function(){
|
||||
expect(binding('qty * cost')).toEqual('$19.95');
|
||||
input('qty').enter('2');
|
||||
input('cost').enter('5.00');
|
||||
expect(binding('qty * cost')).toEqual('$10.00');
|
||||
});
|
||||
</doc:scenario>
|
||||
-->
|
||||
</doc:example>
|
||||
|
||||
Go ahead, try out the Live Preview above. "Well I _declare_! It's a fully functioning form, with
|
||||
an instantly updating display, and input validation." Speaking of being declarative, let's walk
|
||||
through the example and look at the angular-related lines to see what's going on around here.
|
||||
|
||||
In line __2__ of the example, we let the browser know about the angular namespace:
|
||||
|
||||
2 <html xmlns:ng="http://angularjs.org">
|
||||
|
||||
This ensures angular runs nicely in all major browsers.
|
||||
|
||||
In line __3__ we do two angular setup tasks inside a `<script>` tag:
|
||||
|
||||
1. We pull in `angular.js`.
|
||||
2. The angular {@link angular.directive.ng:autobind ng:autobind} directive tells angular to {@link
|
||||
guide.compiler compile} and manage the whole HTML document.
|
||||
|
||||
3 <script src="file:///Users/krculp/angular.js/build/angular.min.js" ng:autobind></script>
|
||||
|
||||
Lines __14__ and __15__ set up one side of angular's very cool two-way data binding, as well as
|
||||
demonstrate some easy input validation:
|
||||
|
||||
14 Quantity: <input name="qty" value="1" ng:validate="integer:0" ng:required/>
|
||||
15 Cost: <input name="cost" value="199.95" ng:validate="number" ng:required/>
|
||||
|
||||
These input widgets look normal enough, but consider these points:
|
||||
|
||||
* Remember the `ng:autobind` directive from line 3? When this page loaded, angular bound the names
|
||||
of the input widgets (`qty` and `cost`) to variables of the same name. Think of those variables as
|
||||
the "Model" part of the Model-View-Controller design pattern.
|
||||
* Note the angular directives, {@link angular.widget.@ng:validate ng:validate} and {@link
|
||||
ngular.widget.@ng:required ng:required}. You may have noticed that when you enter invalid data or
|
||||
leave the the input fields blank, the borders turn a plainly irritated red color, and the display
|
||||
value disappears. These `ng:` directives make it easier to implement field validators than coding
|
||||
them in JavaScript, no? Yes.
|
||||
|
||||
And finally, the mysterious line #__19__:
|
||||
|
||||
19 Total: {{qty * cost | currency}}
|
||||
|
||||
What's with the curly braces? Those curly braces are your friend. This notation, `{{ _expression_
|
||||
}}`, is a bit of built-in angular {@link angular.markup markup}, a shortcut that you use to display
|
||||
data. The expression within curly braces gets transformed by the angular compiler into an angular
|
||||
directive ({@link angular.directive.ng:bind ng:bind}). The expression itself can be a combination
|
||||
of both an expression and a {@link angular.filter filter}: `{{ expression | filter }}`.
|
||||
|
||||
In our example above, we're saying, "Bind the data we got from the input widgets to the display,
|
||||
multiply them together, and format the resulting number into something that looks like money."
|
||||
|
||||
|
||||
<a name="H1_3"></a>
|
||||
# The Angular Philosophy
|
||||
|
||||
Angular is built around the belief that declarative code is better than imperative when it comes to
|
||||
building UIs and wiring software components together, while imperative code is clearly the way to
|
||||
go for expressing business logic.
|
||||
|
||||
Not to put too fine a point on it, but if you wanted to add a new label to your application, you
|
||||
could do it by simply adding text to the HTML template, saving the code, and refreshing your
|
||||
browser (this here is declarative):
|
||||
|
||||
<pre>
|
||||
<span class="label">Hello</span>
|
||||
</pre>
|
||||
|
||||
Or, as In programmatic systems (like {@link http://code.google.com/webtoolkit/ GWT}), you would
|
||||
have to write the code and then run the code like this:
|
||||
|
||||
<pre>
|
||||
var label = new Label();
|
||||
label.setText('Hello');
|
||||
label.setClass('label');
|
||||
parent.addChild(label);
|
||||
</pre>
|
||||
|
||||
That looks like, let's see, do some math, factor out the `<pre>`s, carry the one, ummm... a little
|
||||
bit of markup versus four times as much code.
|
||||
|
||||
More Angular Philosophy:
|
||||
|
||||
* It is a very good idea to decouple DOM manipulation from app logic. This dramatically improves
|
||||
the testability of the code.
|
||||
* It is a really, _really_ good idea to regard app testing as equal in importance to app writing.
|
||||
Testing difficulty is dramatically affected by the way the code is structured.
|
||||
* It is an excellent idea to decouple the client side of an app from the server side. This allows
|
||||
development work to progress in parallel, and allows for reuse of both sides.
|
||||
* It is very helpful indeed if the framework guides developers through the entire journey of
|
||||
building an app: from designing the UI, through writing the business logic, to testing.
|
||||
* It is always good to make common tasks trivial and difficult tasks possible.
|
||||
|
||||
Now that we're homing in on what angular is, perhaps now would be a good time to list a few things
|
||||
what angular isn't:
|
||||
|
||||
* It's not a Library. You don't just call its functions, although it does provide you with some
|
||||
utility APIs.
|
||||
* It's not a DOM Manipulation Library. angular uses jQuery to manipulate the DOM behind the scenes,
|
||||
rather than give you functions to manipulate the DOM with yourself.
|
||||
* It's not a Widget Library. There are lots of existing widget libraries that you can integrate
|
||||
with angular.
|
||||
* It's not "Just Another Templating System". A part of angular is a templating system. The
|
||||
templating subsystem of angular is different from the traditional approach for these reasons:
|
||||
* It Uses HTML/CSS syntax: This makes it easy to read and can be edited with existing HTML/CSS
|
||||
authoring tools.
|
||||
* It Extends HTML vocabulary: Angular allows you to create new HTML tags, which expand into
|
||||
dynamic UI components.
|
||||
* It Executes in the browser: Removes the round trip to the server for many operations and
|
||||
creates instant feedback for users as well as developers.
|
||||
* It Has Bidirectional data binding: The model is the single source of truth. Programmatic
|
||||
changes to the model are automatically reflected in the view. Any changes by the user to the view
|
||||
are automatically reflected in the model.
|
||||
|
||||
|
||||
<a name="H1_2"></a>
|
||||
# Anatomy Of An Angular App
|
||||
|
||||
This section describes the parts of an angular app in more detail.
|
||||
|
||||
## Templates
|
||||
|
||||
{@link guide.template Templates} are the part of angular that makes it easy and fun to create the
|
||||
UI for your web apps. With angular's templates you can create a dynamic UI using only HTML and
|
||||
CSS, but now you can add your own elements, attributes, and markup. The angular compiler reads the
|
||||
"angularized" HTML when your page loads, and follows the instructions in there to generate a
|
||||
dynamic page for you. This is the View part of MVC. "But wait there's more": since the compiler is
|
||||
extensible, you can build your own declarative language on top of HTML!
|
||||
|
||||
## Application Logic and Behavior
|
||||
|
||||
Application Logic and Behavior, which you define in JavaScript, is the C in MVC. With angular you
|
||||
write the logic (the controllers) for your app, but because angular takes care of reflecting the
|
||||
state of the model in the view, you don't have to write listeners or DOM manipulators. This feature
|
||||
makes your application logic very easy to write, test, maintain, and understand.
|
||||
|
||||
## Data
|
||||
|
||||
In an angular app, all of your data is referenced from inside of a {@link angular.scope scope}.
|
||||
The scope is the data Model, the M in the MVC pattern. A scope is a JavaScript object that has
|
||||
watcher functions that keep tabs on the data that is referenced from that scope. The data could be
|
||||
one or more Javascript objects, arrays, or primitives, it doesn't matter. What matters is that
|
||||
these are all referenced by the scope.
|
||||
|
||||
This "scope thing" is how angular takes care of keeping your data model and your UI in sync.
|
||||
Whenever something occurs to change the state of the scope, angular immediately reflects that
|
||||
change in the UI, and vice versa.
|
||||
|
||||
In addition to the three components described above (the MVC bits), angular comes with a set of
|
||||
{@link angular.service Services} that are very helpful for building web apps. The services include
|
||||
the following features:
|
||||
|
||||
* You can extend and add application-specific behavior to services.
|
||||
* Services include Dependency-Injection, XHR, caching, URL routing, and browser abstraction.
|
||||
|
||||
The following illustration shows the parts of an angular application and how they work together:
|
||||
|
||||
<img class="left" src="img/angular_parts.png" border="0" />
|
||||
|
||||
|
||||
<a name="H1_4"></a>
|
||||
# Why You Want Angular
|
||||
|
||||
Angular frees you from the following pain:
|
||||
|
||||
* **Registering callbacks:** Registering callbacks clutters your code, making it hard to see the
|
||||
forest for the trees. Removing common boilerplate code such as callbacks is a good thing. It vastly
|
||||
reduces the amount of JavaScript coding _you_ have to do, and it makes it easier to see what your
|
||||
application does.
|
||||
* **Manipulating HTML DOM programatically:** Manipulating HTML DOM is a cornerstone of AJAX
|
||||
applications, but it's cumbersome and error-prone. By declaratively describing how the UI should
|
||||
change as your application state changes, you are freed from low level DOM manipulation tasks. Most
|
||||
applications written with angular never have to programatically manipulate the DOM, although you
|
||||
can if you want to, knock yourself out.
|
||||
* **Marshaling data to and from the UI:** CRUD operations make up the majority of AJAX
|
||||
applications. The flow of marshaling data from the server to an internal object to an HTML form,
|
||||
allowing users to modify the form, validating the form, displaying validation errors, returning to
|
||||
an internal model, and then back to the server (gah!) creates a lot of boilerplate code. Angular
|
||||
eliminates almost all of this boilerplate, leaving code that describes the overall flow of the
|
||||
application rather than all of the implementation details.
|
||||
* **Writing tons of initialization code just to get started:** Typically you need to write a lot of
|
||||
plumbing just to get a basic "Hello World" AJAX app working. With angular you can bootstrap your
|
||||
app easily using services, which are auto-injected into your application in a {@link
|
||||
http://code.google.com/p/google-guice/ Guice}-like dependency-injection style. This allows you to
|
||||
get started developing features quickly. As a bonus, you get full control over the initialization
|
||||
process in automated tests.
|
||||
|
||||
|
||||
<a name="H1_5"></a>
|
||||
# Angular's Ancestors
|
||||
|
||||
Where does angular come from? What events led to the inevitability of the appearance of something
|
||||
like angular?
|
||||
|
||||
## First There Was HTML
|
||||
|
||||
HTML was initially designed long, long ago, in the great year of 1989, with the intention to create
|
||||
a markup language for sharing scientific documents over the network. Yes, yes, certainly there was
|
||||
SGML even before that, but it was so difficult that even esteemed scientists balked at using it.
|
||||
Thankfully, Tim Berners-Lee saved all of us from that pain with his much friendlier HTML.
|
||||
`<HTML><BODY>Thank You, TB-L!</BODY></HTML>`.
|
||||
|
||||
## Then There Was JavaScript
|
||||
|
||||
Fast forward to 1995: JavaScript was invented. This was done with the best of intentions! But in
|
||||
practice it initially served mainly to annoy Internet users with cheap effects that "enhanced"
|
||||
static HTML documents.
|
||||
|
||||
Fast forward to the mid 2000s, when a new breed of back-then-considered-rich web applications
|
||||
started to appear on the web. These were built with HTML, JavaScript, and CSS, and featured less
|
||||
annoying and more impressive effects. Can you recall the first time you saw apps like Gmail, or
|
||||
Google Maps, and you couldn't believe everything that was going on in the browser?
|
||||
|
||||
## And JavaScript Prevailed
|
||||
|
||||
As of this writing, in 2011, people are building still richer and more interactive web applications
|
||||
that often rival their desktop counterparts. And yet they are essentially still working with
|
||||
technology and programming primitives that were used decades ago for the creation of static
|
||||
documents with cheap graphic effects. At the same time, the web is HUGE now, and we
|
||||
can't just abandon the technologies it was built with. Applets, Flash and Silverlight tried it, and
|
||||
in some ways succeeded. Yet many would argue that in reality they failed, because they tried to
|
||||
work _around_ the web instead of working _with_ it.
|
||||
|
||||
## And Then There Was Angular
|
||||
|
||||
Angular recognizes the strengths of the existing "static" web technologies, as well as their
|
||||
deficiencies. At the same time, angular is learning from the failures of other technologies that
|
||||
tried, or are trying, to work around the web.
|
||||
|
||||
For these reasons angular plays to the strengths of established web technologies, instead of
|
||||
bypassing them. Angular sets out the goal of increasing the abstraction and programming primitives
|
||||
that developers use to build web applications, so as to better reflect the needs of modern web
|
||||
applications and their developers.
|
||||
|
||||
|
||||
<a name="H1_6"></a>
|
||||
# Watch a Presentation About Angular
|
||||
|
||||
Here is an early presentation on angular, but note that substantial development has occurred since
|
||||
the talk was given in July of 2010.
|
||||
|
||||
<object width="480" height="385">
|
||||
<param name="movie" value="http://www.youtube.com/v/elvcgVSynRg&hl=en_US&fs=1"></param>
|
||||
<param name="allowFullScreen" value="true"></param>
|
||||
<param name="allowscriptaccess" value="always"></param>
|
||||
<embed src="http://www.youtube.com/v/elvcgVSynRg&hl=en_US&fs=1"
|
||||
type="application/x-shockwave-flash" allowscriptaccess="always"
|
||||
allowfullscreen="true" width="480" height="385"></embed>
|
||||
</object>
|
||||
|
||||
{@link
|
||||
https://docs.google.com/present/edit?id=0Abz6S2TvsDWSZDQ0OWdjaF8yNTRnODczazdmZg&hl=en&authkey=CO-b7oID
|
||||
Presentation}
|
||||
|
|
||||
{@link
|
||||
https://docs.google.com/document/edit?id=1ZHVhqC0apbzPRQcgnb1Ye-bAUbNJ-IlFMyPBPCZ2cYU&hl=en&authkey=CInnwLYO
|
||||
Source}
|
||||
@@ -1,22 +0,0 @@
|
||||
@workInProgress
|
||||
@ngdoc overview
|
||||
@name Developer Guide: Template
|
||||
@description
|
||||
#Template
|
||||
|
||||
You can think of a template in angular as a domain-specific language that you can use to easily
|
||||
build the view of your web application. You create a template by writing HTML and CSS, and you can
|
||||
add any constructs that you want to the HTML. This means that you can attach rendering and behavior
|
||||
to any HTML element, attribute or markup text.
|
||||
|
||||
In addition to writing HTML and CSS, you can also use the following angular constructs to create
|
||||
your template:
|
||||
|
||||
* **Directive** - XML attributes that augment an existing DOM element.
|
||||
* **Markup** - Lets you create shorthand for a widget or a directive. For example, markup is what
|
||||
allows you to use the double curly brace notation {{}} to bind expressions to
|
||||
elements.
|
||||
* **Filter** - Lets you format your data for display to the user.
|
||||
* **Widget** - Lets you create new DOM elements that the browser doesn't already understand.
|
||||
* **Validator** - Lets you validate user input.
|
||||
* **Formatter** - Lets you format the input object into a user readable view.
|
||||
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user