On Sat, Mar 13, 2010 at 11:32 AM, John Locke <m...@freelock.com> 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
------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Ledger-smb-devel mailing list
Ledger-smb-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel
