<commit_before>URI Fragment Routing
====================

[![Build Status](https://travis-ci.org/rolandkrueger/uri-fragment-routing.svg?branch=develop)](https://travis-ci.org/rolandkrueger/uri-fragment-routing)

This library provides a framework for mapping URI fragments as found in URIs such as `http://www.example.com/shop#!signin` on custom actions. For example, the URI fragment `signin` could be mapped on an action class `GoToSignInPageAction` which will be executed when the user visits this address.

This is useful for single-page applications where the application state is typically encoded in the URI fragment. For example, the following URI might by used by an application to show the user a product detail page in some web shop. 

`http://www.example.com/shop#!/products/group/books/id/4711/view`

Here the part `!/products/group/books/id/4711/view` forms the URI fragment that carries an application's current state. As you can see, such a URI fragment consists of a directory-like path structure. This structure may additionally contain parameter values such as ids, categories, or coordinates. Since URI fragments are pushed to the browser history, they allow for writing navigatable web applications that support the browser back button and deep linking.

Web applications typically use a large number of such fragments in order to allow users to navigate to the different parts of an application. Beside navigating to some sub-view, a URI fragment could also be responsible for changing the state of a UI component visible on a view. For instance, you could bring a particular panel of a panel stack to the foreground with a specific URI fragment.

When using URI fragments for encoding application state, you're facing two problems that have to be solved. Firstly, a URI fragment visited by the user has to be parsed and interpreted. Parameter values have to be extracted from the fragment, they need to be converted and validated, and finally have to be passed to the code that is responsible for handling the fragment.
<commit_msg>Add Codecov badge to README<commit_after>URI Fragment Routing
====================

[![Build Status](https://travis-ci.org/rolandkrueger/uri-fragment-routing.svg?branch=develop)](https://travis-ci.org/rolandkrueger/uri-fragment-routing) [![Code Coverage](https://img.shields.io/codecov/c/github/rolandkrueger/uri-fragment-routing/develop.svg)](https://codecov.io/github/rolandkrueger/uri-fragment-routing?branch=develop)

This library provides a framework for mapping URI fragments as found in URIs such as `http://www.example.com/shop#!signin` on custom actions. For example, the URI fragment `signin` could be mapped on an action class `GoToSignInPageAction` which will be executed when the user visits this address.

This is useful for single-page applications where the application state is typically encoded in the URI fragment. For example, the following URI might by used by an application to show the user a product detail page in some web shop. 

`http://www.example.com/shop#!/products/group/books/id/4711/view`

Here the part `!/products/group/books/id/4711/view` forms the URI fragment that carries an application's current state. As you can see, such a URI fragment consists of a directory-like path structure. This structure may additionally contain parameter values such as ids, categories, or coordinates. Since URI fragments are pushed to the browser history, they allow for writing navigatable web applications that support the browser back button and deep linking.

Web applications typically use a large number of such fragments in order to allow users to navigate to the different parts of an application. Beside navigating to some sub-view, a URI fragment could also be responsible for changing the state of a UI component visible on a view. For instance, you could bring a particular panel of a panel stack to the foreground with a specific URI fragment.

When using URI fragments for encoding application state, you're facing two problems that have to be solved. Firstly, a URI fragment visited by the user has to be parsed and interpreted. Parameter values have to be extracted from the fragment, they need to be converted and validated, and finally have to be passed to the code that is responsible for handling the fragment.

{'fraction_non_alphanumeric': 0.06502554575011611, 'fraction_numerical': 0.0037157454714352067, 'mean_word_length': 4.9, 'pattern_counts': {'":': 0, '<': 3, '<?xml version=': 0, '>': 3, 'https://': 6, 'lorem ipsum': 0, 'www.': 4, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '1232076', 'n_tokens_mistral': 1033, 'n_tokens_neox': 1003, 'n_words': 578}