Re: Global Namespaces

[John Locke <..hidden..>]

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&#174; 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
>