Separated code to have a lib and an example.
Improved design, fixed a few issues related to folder location.
This is still experimental and require more work to be really friendly to use.
This is mainly to be compatibe with other classes API.
In a lot of classes, we define methods like this:
```Eiffel
method (req: WSF_REQUEST; res: WSF_RESPONSE)
do
...
end
```
With the context, the signature becomes:
```Eiffel
method (ctx: C; req: WSF_REQUEST; res: WSF_RESPONSE)
do
...
end
```
So, I can't build a filter chain where one filter is with context
and one is without context (I can't call
WSF_FILTER.set_next (a_next: WSF_FILTER) with a filter that is a
descendant of WSF_CONTEXT_HANDLER).
Moreover, having to play with generic types just to pass some
data from one filter to another is a bit overkill imho.
Because this is really what I use contexts for:
to pass data from one filter to the next one.
Regarding execution_variable and strong typing, if we want to achieve these,
I realize we could write a class with one getter and one setter like this:
```Eiffel
class
TYPED_DATA
feature -- Access
user (req: WSF_REQUEST): detachable USER
do
if attached {USER} req.execution_variable ("user") as l_user then
Result := l_user
end
end
feature -- Element change
set_user (req: WSF_REQUEST; a_user: USER)
do
req.set_execution_variable ("user", a_user)
end
```
Now, I realize this is a major change since the last time we talked about this,
but at the end, after having played with both, I prefer the one with
execution_variable.
This is mainly a refactoring that is useful for an upcoming PR
regarding CORS (smaller patches are better...)
Note that this also fixes a small typo where an extra space was
added when calling {HTTP_HEADER}.put_allow
added `a_request_methods' argument to WSF_ROUTER_SELF_DOCUMENTATION_HANDLER.mapping_documentation
added similar argument to WSF_ROUTER_SELF_DOCUMENTATION_ROUTER_MAPPING.documentation
Renamed WSF_ROUTER_METHODS as WSF_REQUEST_METHODS
Enhanced WSF_REQUEST_METHODS with new has_... function
Added WSF_ROUTER_VISITOR and WSF_ROUTER_ITERATOR that may be useful to iterate inside the router.
we may improve the implementation of the router using those visitors in the future.
Improved the WSF_DEFAULT_RESPONSE to embedded suggested items (typically based on pseudo self documented router)
