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
------------------------------------------------------------------------------
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
..hidden..
https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel