I was thinking yesterday, that it would be nice to have an entire XML
based interface. If most of the system was a backend which handled XML
documents, the frontend could be a web app, a thick client, or any other
sort of thing--the backend would have no reason to care.
All a new module would have to do, is process the portion of XML data
passed to it by ID, and the frontend would consist of the UI section
relating to that module, and a formatter to post the proper XML.
I realize that could get tricky with thick clients, but probably on the
read side more than the write side.
Just musing.
Luke
On Sat, 13 Mar
2010, John Locke 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:
>
>> 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 <[email protected]>
> To: Development discussion for LedgerSMB
> <[email protected]>
> 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
>> [email protected]
>> 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
> [email protected]
> 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
[email protected]
https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel
