Edited wiki page LifeOfARequest through web user interface.
diff --git a/LifeOfARequest.wiki b/LifeOfARequest.wiki
index d07d018..3e42732 100644
--- a/LifeOfARequest.wiki
+++ b/LifeOfARequest.wiki
@@ -54,4 +54,6 @@
If the system is running normally, the next phase is to check if the current user is allowed to submit the request. In order to do that a concrete class which inherits from RequestHandler must implement checkAccess method. This method should raise AccessViolation, if the user is not permitted to access the requested resource for some reason. The logic ought to be delegated to a utility function in AccessChecker class.
-It is important to mention that for users with developer status a deferent implementation of AccessChecker is used. They are allowed to access every single view, so shortly speaking, the actual access checking functions are bypassed. Therefore no state of objects should be changed by them. In particular, AccessChecker methods should not extend RequestData object with any extra fields, as they may not be defined for developers. It may introduce some vicious errors which will encountered only by that one specific type of users.
\ No newline at end of file
+It is important to mention that for users with developer status a deferent implementation of AccessChecker is used. They are allowed to access every single view, so shortly speaking, the actual access checking functions are bypassed. Therefore no state of objects should be changed by them. In particular, AccessChecker methods should not extend RequestData object with any extra fields, as they may not be defined for developers. It may introduce some vicious errors which will encountered only by that one specific type of users.
+
+Access checking is followed by dispatching the actual request processing to a function designated for that based on the request's type.
\ No newline at end of file
