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.
Initial support for the Cross-Origin Resource Sharing specification.
This allows JavaScript to make requests across domain boundaries.
Also reviewed the filter example to get rid of the context and
the generic classes (we can actually use {WSF_REQUEST}.execution_variable
and {WSF_REQUEST}.set_execution_variable).
Links:
* How to enable server-side: http://enable-cors.org/server.html
* Specification: http://www.w3.org/TR/cors/
* Github: http://developer.github.com/v3/#cross-origin-resource-sharing
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)
The logging filter is now part of EWF core (before it was only available in
the filter example) and can therefore be reused by others needing it.
Note that this is a first implementation. It can certainly be improved in
the future to support more fine grained logging.
(note: this commit is a merged of pull request from Olivier Ligot, and changes from Jocelyn Fiat)
Signed-off-by: Jocelyn Fiat <jfiat@eiffel.com>
Signed-off-by: Olivier Ligot <oligot@gmail.com>
Filters are part of a filter chain, thus following the chain of responsability
design pattern.
More information are available in library/server/wsf/src/filter/README.md
kept `key' as redirection, and also string as obsolete redirection.
Router: provide a way to pass the request methods without using manifest string, thanks to WSF_ROUTER_METHODS
so instead of using manifest array or manifest strings, just create an instance of WSF_ROUTER_METHODS
for convenience, WSF_ROUTER provides a few `methods_...' returning prebuilt WSF_ROUTER_METHODS objects
Improved code related to unicode handling in URL, and parameters (before the framework was doing too much)
Added WSF_STRING.is_empty
Improved HTML_ENCODER to be able to decode a STRING_8 or STRING_32 using general_decoded_string (s)
Improved tutorial example
Added precompilation for WSF library
Cosmetic (removed unused locals)
