Include WGI_HEADERS to help the user to build HTTP Header. So that he doesn't have to know the HTTP specification for usual needs
parameter
into item
rename
{REQUEST}.parameter (n: READABLE_STRING_GENERAL): detachable WGI_VALUE
into{REQUEST}.item (n: READABLE_STRING_GENERAL): detachable WGI_VALUE
and similar forparameters
->items
Instead of returning just
READABLE_STRING_32
, it would be better to use WGI_VALUE .
Mainly to address the multiple value for the same param name, but also for uploaded files.
This allows to have various types such as WGI_STRING_VALUE, WGI_LIST_VALUE, WGI_TABLE_VALUE, WGI_FILE_VALUE .Thus we would have:
parameter (a_name: READABLE_STRING_GENERAL): detachable WGI_VALUE
include the corresponding parameter's name in WGI_VALUE interface.
Such as{WGI_VALUE}.name: READABLE_STRING_GENERAL
(or READABLE_STRING_32).This would also allow to replace
signatureparameters: ITERABLE [TUPLE [name: READABLE_STRING_GENERAL; value: WGI__VALUE]]' by a nicer signature
parameters: ITERABLE [WGI__VALUE]`
Description: Instead of forcing the implementation to use HASH_TABLE, DS_HASH_TABLE, DS_HASH_SET, ... or similar we should use
ITERABLE
parameters: ITERABLE [TUPLE [name: READABLE_STRING_GENERAL; value: WGI_VALUE]]
Or, if
P-2011-09-05-WGI_VALUE_interface
is adopted (WGI_VALUE.name holds the related parameter's name)
parameters: ITERABLE [WGI_VALUE]
shorter and pronouncable prefix for EWSGI class names
...