anchor.diff:  
   This mode operates similar to the previous one, with the difference that the parameters' ids are not contained in the URI fragment. In the mode, the example above looks like follows:
   
  -    /admin/users/4711/showHistory/2017-01-01/2017-01-31
  +    #!/admin/users/4711/showHistory/2017-01-01/2017-01-31
   
   When this mode is used, parameters must not be defined as optional. Otherwise, a missing parameter value could not be distinguished from the consecutive URI fragment tokens.
   
   ==== Query Mode
   
  -In this mode, all URI parameters are appended to the URI fragment in the same way as customary URL query parameters. The above example will look like follows with this mode:
  -
  -    /admin/users/showHistory?id=4711&startDate=2017-01-01&endDate=2017-01-31
  +In this mode, all URI parameters are appended to the URI fragment in the same way as customary URI query parameters are appended to a URI (as described in https://tools.ietf.org/html/rfc3986#section-3.4[RFC 3986]). The above example will look like follows with this mode:
  +
  +    #!/admin/users/showHistory?id=4711&startDate=2017-01-01&endDate=2017-01-31
   
   == A First Simple Scenario
   
  +Now that we have learned about the basic classes and concepts of this library, we'll put our knowledge to use and start building URI action mapper trees. We will start small and begin with the simplest possible mapper tree.
  +
  +In this section, we will build a mapper tree which is able to handle the following URI fragment:
  +
  +    #!/helloWorld
  +	
  +When the user visits this fragment, we want to print `Hello World!` to the console. To do this, we need two things: we have to define an action class and the URI action mapper tree which can resolves this URI fragment to this action class.
  +
  +Let's first define the action class:
  +
  +[source,java]
  +----
  +public static class HelloWorldActionCommand implements UriActionCommand {
  +    @Override
  +    public void run() {
  +        System.out.println("Hello World!);
  +    }
  +}
  +----
  +
  +Now we can build the URI action mapper tree.
  +
  +[source,java]
  +----
  +UriActionMapperTree mapperTree =
  +    UriActionMapperTree.create().buildMapperTree()
  +        .map("helloWorld").onAction(HelloWorldActionCommand.class)
  +        .finishMapper().build();
  +----
  +
  +To do so, we use the builder provided to us by `UriActionMapperTree.create()`. This builder will guide us through the complete process of creating and configuring the full URI action mapper tree. We start the building process with `buildMapperTree()`. A mapper tree is built in a depth-first manner. That is, we start with the first level of the directory-like URI fragment structure (`\#!/firstLevel`) and continue building the sub-levels from there (`#!/firstLevel/secondLevel`). We will learn how to do that in the following sections.
  +
  +In our simple example, we only want to map a single path segment on an action class. We do this with the `map()` method. This method will create a `SimpleUriPathSegmentActionMapper` for us. We set the action command object for this mapper with the `onAction()` method. When we're done configuring the current action mapper, we finalize it with `finishMapper()`. After this method has been called for the current action mapper, we cannot add any further sub-mappers to it. However, this would not be possible in our example anyway, since we created a simple action mapper which does not support sub-mappers. Simple action mappers represent the leaves of the mapper tree.
  +
  +When we're done composing the URI action mapper tree, we finalize the tree with the `build()` method. This will return the fully configured `UriActionMapperTree` ready for action.
  +
  +How can we now interpret URI fragments visited by the user with this mapper tree?
  +
  +This is done with the `interpretFragment()` method. We can pass a String holding the current URI fragment to this method:
  +
  +[source,java]
  +----
  +UriActionCommand command = mapperTree.interpretFragment("/helloWorld");
  +----
  +
  +This will trigger the interpretation process during which the URI fragment is disassembled and resolved to a URI action command class. The action mapper tree will resolve this fragment to the class object provided by us during the construction of the mapper tree: `HelloWorldActionCommand`. It will then create an instance of this class, execute it and return the command object as a result.
  +
  +If the given URI fragment could not be resolved (e. g. if we made a typo and passed `/heloWrold` to the interpretation method), `null` is returned and no action command object is executed.
  +
  +With this, we have successfully created a very simple but fully functional URI action mapper tree which is able to handle one particular URI fragment.
  +
  +== Defining a Default Action Command
  +
  +As we have seen in the previous section, if a URI fragment could not successfully be interpreted, `null` is returned from the interpretation process as a result. We can prevent this by defining a default action command which will be executed each time a URI fragment could not be successfully resolved. We can this on the instance of the URI action mapper tree:
  +
  +[source,java]
  +----
  +mapperTree.setDefaultActionCommandClass(MyDefaultActionCommand.class);
  +----
  +
  +or alternatively while building this tree with the builder objects:
  +
  +[source,java]
  +----
  +mapperTree = UriActionMapperTree.create()
  +             .useDefaultActionCommand(MyDefaultActionCommand.class)
  +             .buildMapperTree()
  +             ...
  +----
  +
   == Adding Some More Top-Level Mappers
   
  +Now we have a good starting point from which we can go on. We will expand our mapper tree with more mappers in the next step. Let us define the following three top-level path segments which can be handled by the mapper tree:
  +
  +....
  +#!/user
  +#!/admin
  +#!/settings
  +....
  +
  +We can do this in the same way as we did above, except that we continue building the mapper tree after we have fully configured the first action mapper:
  +
  +[source,java]
  +----
  +mapperTree = UriActionMapperTree.create().buildMapperTree()
  +             .map("user").onAction(GoToUserAreaActionCommand.class).finishMapper()
  +             .map("admin").onAction(GoToAdminAreaActionCommand.class).finishMapper()
  +             .map("settings").onAction(GoToSettingsActionCommand.class).finishMapper()
  +             .build();
  +----
  +
  +As you can see, after we called `finishMapper()` the builder is reset to the root of the mapper tree and we can go on adding the next sibling path segment to be handled by the mapper tree.
  +
   == Adding Hierarchy
   
  +Next we want to add some hierarchy to the mapper tree. We would now like to be able to interpret the following URI fragments:
  +
  +....
  +#!/user
  +#!/user/profile
  +#!/admin
  +#!/admin/users
  +#!/admin/groups
  +#!/settings
  +....
  +
  +We will do this in a depth-first manner:
  +
  +[source,java]
  +----
  +UriActionMapperTree mapperTree = UriActionMapperTree.create().buildMapperTree()
  +            .mapSubtree("user").onAction(GoToUserAreaActionCommand.class)
  +                .onSubtree()
  +                .map("profile").onAction(GoToUserProfileActionCommand.class).finishMapper()
  +            .finishMapper()
  +            .mapSubtree("admin").onAction(GoToAdminAreaActionCommand.class)
  +                .onSubtree()
  +                .map("users").onAction(GoToUserAdministrationActionCommand.class).finishMapper()
  +                .map("groups").onAction(GoToGroupAdministrationActionCommand.class).finishMapper()
  +            .finishMapper()
  +            .map("settings").onAction(GoToSettingsActionCommand.class).finishMapper()
  +        .build();
  +----
  +
  +The `user` and `admin` path segments now need to have their type changed from a simple action mapper into a dispatching action mapper which allows adding sub-mappers. This is reflected by the builder methods we have to use now: `mapSubtree()` initiates the construction of a sub-mapper hierarchy. We can still assign an action command class to this mapper. This will be executed when the dispatching action mapper is directly accessed with the URI fragment `#!/user`.
  +
  +After the dispatching mapper has been fully configured, we can go to the next hierarchy level and configure the dispatching mapper's sub-mappers. We initiate the construction of this sub-tree with method `onSubtree()`. From this point on, we can continue with constructing the mapper tree on the next level as we did on the root level. As we can see, we are here dealing with a recursive structure. We can now use the same builders as we did on the root level. We can thus nest the action mappers as deeply as we like.
  +
  +In our example we only add simple action mappers on the second level of the action mapper tree. We could, however, choose to add a second level of dispatching action mappers and a third level of simple mappers and so on by repeatedly calling `mapSubtree()`.
  +
  +It is important to note that method `finishMapper()` will leave the current level of nesting and move the "builder's cursor" up to the parent level. This is why we have to call `finishMapper()` twice after we configured the action mapper for `profile`. The first call to `finishMapper()` moves the cursor up to the level of `user` while the second call to `finishMapper()` moves it back to the root level.
  +
  +== Reusing Path Segment Names
  +
  +Until now, we defined action mappers for a unique set of path segment names. The following path segment names are currently in use by our action mapper tree: `user`, `profile`, `admin`, `users`, `groups`, and `settings`.
  +
  +What happens, when we reuse one of the path segment names? Let's add a `profile` sub-mapper for the `admin` dispatching mapper:
  +
  +[source,java]
  +----
  +UriActionMapperTree mapperTree = UriActionMapperTree.create().buildMapperTree()
  +            .mapSubtree("user").onAction(GoToUserAreaActionCommand.class)
  +                .onSubtree()
  +                .map("profile").onAction(GoToUserProfileActionCommand.class).finishMapper()
  +            .finishMapper()
  +            .mapSubtree("admin").onAction(GoToAdminAreaActionCommand.class)
  +                .onSubtree()
  +                .map("profile").onAction(GoToUserAdministrationActionCommand.class).finishMapper()
  +            ... // remainder omitted for brevity
  +----
  +
  +This gives us the following URI fragment structure:
  +
  +....
  +#!/user
  +#!/user/profile
  +#!/admin
  +#!/admin/profile
  +#!/admin/users
  +#!/admin/groups
  +#!/settings
  +....
  +
  +When we try to build this mapper tree, the following exception will be thrown:
  +
  +    java.lang.IllegalArgumentException: Mapper name 'profile' is already in use
  +
  +What does that mean? While this URI fragment structure is perfectly valid, we are not allowed to construct it in the way shown. We must not reuse the mapper name which is defined with the methods `map()` and `mapSubtree()`. This mapper name serves as a unique identifier of a URI action mapper object. Therefore, a mapper name must only be used once per action mapper tree.
  +
  +What we need to do in this case is to separately define the mapper name for the action mapper and the path segment for which it is responsible. The methods `map()` and `mapSubtree()` we used until now conveniently set these two values to the same String, which is the one we passed as a parameter to these methods. We now have to do without this convenient feature and define both the mapper name and the path segment name separately:
  +
  +[source,java]
  +----
  +UriActionMapperTree mapperTree = UriActionMapperTree.create().buildMapperTree()
  +            .mapSubtree("user").onAction(GoToUserAreaActionCommand.class)
  +                .onSubtree()
  +                .map("profile").onAction(GoToUserProfileActionCommand.class).finishMapper()
  +            .finishMapper()
  +            .mapSubtree("admin").onAction(GoToAdminAreaActionCommand.class)
  +                .onSubtree()
  +            .map("adminProfile").onPathSegment("profile").onAction(MyActionCommand.class).finishMapper()
  +            ... // remainder omitted for brevity
  +----
  +
  +Now we define with the `map()` method the mapper name (the mapper's id) and set the path segment name for which the mapper is responsible in the next step with `onPathSegment()`. When we create a dispatching mapper with `mapSubtree()` we can define the path segment name with the overloaded variant of `mapSubtree()`:
  +
  +[source,java]
  +----
  +mapSubtree("adminArea", "admin").onAction(GoToAdminAreaActionCommand.class)
  +----
  +
  +Here we define the mapper name `adminArea` and the path segment name `admin`.
  +
   == Adding Parameters
   
   == Writing URI Action Commands
  
positive.code: 
  Using the enumeration `org.roklib.urifragmentrouting.parameter.ParameterMode` you can specify in what mode the URI action mapper tree shall operate.
  
  Let's clarify these modes.
  
  ==== Directory Mode With Names
  
  In this mode, parameter values are contained in a URI fragment in a directory-like format. Their parameter ids are also contained in the URI fragment. Example:
  
      /admin/users/id/4711/showHistory/startDate/2017-01-01/endDate/2017-01-31
  
  This URI fragment contains three parameters: `id`, `startDate` and `endDate`. As you can see, the parameters' ids are contained in the the URI fragment together with their concrete values.
  
  
negative.code: 
  is disassembled into the following list of tokens:
  
      ["admin", "users", "id", "4711", "profile", "activeTabsheet", "address"]
  
  This list is then interpreted by the mapper tree. Parts of this list are parameter values (here ["id", "4711"] and ["activeTabsheet", "address]). The other parts make up the directory-like hierarchical URI fragment structure (here ["admin", "users", "profile"]). For each of the directory parts (_path segments_), there is one instance of a `UriPathSegmentActionMapper` which is responsible of handling this part. These _action mappers_ have different tasks. The task of the inner segments is to pass the interpretation process on to the action mapper of the next hierarchy level. For instance, the action mapper responsible for the `admin` path segment is responsible to pass the interpretation process on to the action mapper for the `users` path segment.
  
  