Update README.md

README.md

@@ -1,26 +1,26 @@
 angular-rbac
 ============
 
-A simple version of RBAC for angular that can be easily integrated with any angular application and any backend
-This module consist from 2 parts: '$rbac' service and directive 'allow'.
+A simple version of RBAC for angular that can be easily integrated with any angular application and any backend.
+This module consist from 2 parts: **$rbac** service and directive **allow**.
 
-Task of that module is quite simple - request backend for permission(boolean) for AuthItem (any string). 
-Because we, probably, don't want to spam backend with alot of small request to check permissions, some optimizations is required.
+Task of that module is quite simple - *request backend for permission(boolean) for AuthItem (any string).* 
+Because we, probably, don't want to spam backend with alot of small request to check permissions, some optimization is required.
 That's why was born such module (and because i need some interesting task to learn new technology/framework - in my case, it's angular)
 
-At this module, each permission has 3 state: 'undefined', 'true' and 'false'. 'undefined' means that checking was never requested. So that's additional $digest for watches (if that's important information for you)!
+At this module, each permission has 3 state: **undefined**, **true** and **false**. **undefined** means that checking was never requested. So that's additional $digest for watches (if that's important information for you)!
 
 P.S.: Task of this module - easily to add posibilities to check permission without any RBAC configuration at client-side, let's
-backend do all dirty work and because move/duplicate any real RBAC/ACL to client side is very bad idea, so in real world, we need only
+backend do all dirty work. Moving/duplicating any real RBAC/ACL at client side is very bad idea, so in real world, we need only
 some optimizations in our api-centric/ria/web-application. 
 
 Usage
-=====
+-----
 
-As already was mentioned, there are 2 parts: directive ('allow') and service ('$rbac'). You can't use directive without service, but of course you can use service without directive.
+As already was mentioned, there are 2 parts: *directive* **allow** and *service* **$rbac**. You can't use directive without service, but of course you can use service without directive.
 
 Main task of directive to optimize our permissions checking at templates, because most time at real application there will be alot of such checking and we would like to request server only once - somewhere after 'compile' phase.
-So yes, not matter how many directives will be used to check permission, only once request will be sent to server for checking.
+So yes, not matter how many directives will be used to check permission, only one request will be sent to server for checking.
 Also not matter how many times you will ask to check same permission, that permission will be checked only once.
 
 So let's rock-n-roll.
@@ -32,11 +32,14 @@ So let's rock-n-roll.
 		<li>{{user.name}} <button allow="Admin">Update</button></li>
 	</ul>
 
-All our 'allow' directives enqueue service to check for permissions. At this example, only one request for checking will be send: ["Guest", "User", "Admin"]
-And server must respond with: { Guest: true, User: false, Admin: false }, for example.
+All our **allow** directives enqueue service to check for permissions. At this example, only one request for checking will be sent: 
+> ["Guest", "User", "Admin"]
+
+And server must respond with something like: 
+> { Guest: true, User: false, Admin: false }
 
 Service caching locally any checking, so till application will be reloaded (page reload) or reset() method will be called - state of permissions will be stored.
-Of course, there is no any syncronization with server, so in case if state was changed at server that doesn't mean that client will get this update imideatly. 
+Of course, there is no any syncronization with server, so in case if state was changed at server that doesn't mean that client will get this update immediately. 
 You will need re-request server for state. To implement logic based on this module - is your task and in your hands.
 
 Ok, everything is clear with directives, but what about controllers? Can we use it here? Sure, let's see:
@@ -59,14 +62,16 @@ Ok, everything is clear with directives, but what about controllers? Can we use
 
 	}]);
 
-That's how you can use service at controllers. Btw, how many requests will be send to server at last example and what permissions will be checked?
+That's how you can use service **$rbac** at controllers. 
+
+Btw, how many requests will be sent to server at last example and what permissions will be checked? Ok, ok....two request will be sent to server: 
+> ["User", "Admin"] and ["Guest"]. 
 
-Ok, ok....two request will be sent to server: ["User", "Admin"] and ["Guest"]. WTF?! Why only one checking at last request? That's because 
-that checking was already requested.
+Why only one checking at last request? That's because that checking was already requested.
 
-N.B.: $rbac.allow() is not requesting permission check, it's only return current state of that permission (true/false/undefined).
+N.B.: **$rbac.allow()** is not requesting permission check, it only returns current state of that permission (**true*/**false**/**undefined**).
 
 
 API
-===
+---
 To be continue...