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:
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
... 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.
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?
Cheers,
John
-------- Original Message --------
Subject: [Ledger-smb-devel] Global Namespaces
From: Chris Travers <..hidden..>
To: Development discussion for LedgerSMB
<..hidden..>
Date: Sat 13 Mar 2010 11:00:01 AM PST
I am thinking of suggesting two global namespaces
In package LedgerSMB
use Class::Struct LedgerSMB::Globals => {
user => 'LedgerSMB::User',
session => 'LedgerSMB::Session',
config => 'LedgerSMB::ConfigFile',
# Config settings, similar to Sysconfig today
};
our Globals = LedgerSMB::Globals->new();
in pacakge LedgerSMB::Web:
use Class::Struct LedgerSMB::Web::Globals => {
session => 'LedgerSMB::Session::Web',
request => 'LedgerSMB::Web::Request',
};
our Globals = LedgerSMB::Web::Globals->new();
Any other globally accessible information that needs to be available
globally through apps/scripts?
Best Wishes,
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
------------------------------------------------------------------------------
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