Re: Global Namespaces

[Chris Travers <..hidden..>]

On Sat, Mar 13, 2010 at 11:32 AM, John Locke <..hidden..> wrote:
> Just reading back through the architecture threads, and I think it all
> mostly sounds great, I like the direction you're going.
>
> One thing comes to mind: I don't see a way of detecting in the Request
> struct the difference between a query argument in the URL vs the body,
> e.g. GET vs. POST parameters.
>
> Are these going to get munged together? I do sometimes find it useful to
> distinguish between the two, especially if the body contains something
> other than a query string format (e.g. JSON, XML). As I'm doing more and
> more resource-based web services, it seems like the Request struct may
> need some more detail:

Currently these were munged together in 1.3, but there is no reason
this can't be added.

>
>> struct LedgerSMB::Web::Request, {
>>     params         => '*%', # formerly top-level hash
>>     method         => '$',  # GET/PUT/POST
>>     headers        => '*%', # Defined for the interface
>>     url            => '$',  # full url requested
>>     script_nsp     => '$',  # namespace of the script to run
>>     dispatch_point => '$',  # formerly 'action' on the top-level
>> };
>>


> I'm thinking that for easy integration, it would be nice to be able to
> create a handler plug-in to translate some generic POST data into a
> standardized document/struct of some kind that the rest of LSMB can
> recognize. Not sure this needs to be a global, but it's something I
> could see needing to do.
>
> Basically, I'd want to be able to parse the GET arguments, and translate
> the payload from a JSON- or XML- formated document into params that
> regular LSMB modules can handle. I'd want access to the raw payload, and
> to know how to populate the Request struct appropriately. So perhaps add:
>
> get_params => '*%',
> raw_post => '$',   # only populated on POST/PUT

Good points.  Accepted there.

Also maybe add:
cookies => '@',
files => '@',

That can be used also to handle uploads (things like bank
reconciliation, and the like would need this)
>
> ... and specify that 'params' by default contains the get_params merged
> with a parsed query-string from the raw post (with POST variables
> overriding GET variables on collision). raw_post might be a query
> string, an XML document, a JSON document, binary data, or whatever other
> format a plug-in handler can interpret.

Good points.
>
> Then my handlers can modify the params after parsing the raw_post,
> translate it into something that the rest of LSMB can process.
>
>
> Is this kind of feedback useful?

Perfect. Thanks!
Chris Travers