formatted nav patterns

content/NAVPatterns/1-patterns/hooks/index.md

@@ -72,13 +72,13 @@ Suppose, we want to add business logic just before posting a sales document. In
 This pattern can be used in all cases to put business logic. But I see three possible approaches
 
 1. You only declare the most important and most used hooks
-  * This way, you limit the amount of objects and hooks to only a few in the default product
-  * For example, only the OnBeforePostSalesHeader, OnBeforeReleaseSalesDocument, .. And no field validation or such...
+    * This way, you limit the amount of objects and hooks to only a few in the default product
+    * For example, only the OnBeforePostSalesHeader, OnBeforeReleaseSalesDocument, .. And no field validation or such...
 2. Only at objects of the default application which you are customizing. 
-  * This way, you don't want to create hooks for your own objects, only default existing objects.
+    * This way, you don't want to create hooks for your own objects, only default existing objects.
 3. (recommended) You create hooks on all places you don't want to write business logic, and on all existing objects which you would like to customize.
-  * This is a very consistent way of working, as in any case, your business logic ends up in either a hook, or in its corresponding objects from a specific design pattern. But you know that the entry point is always a hook.
-  * You know what to expect in any case, both changed business logic in existing code and business logic in newly created code is entered from a hook.
+    * This is a very consistent way of working, as in any case, your business logic ends up in either a hook, or in its corresponding objects from a specific design pattern. But you know that the entry point is always a hook.
+    * You know what to expect in any case, both changed business logic in existing code and business logic in newly created code is entered from a hook.
 
 ## Related Topics