[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Command Line Interface -- AP Transactions



Chris Travers wrote:
> Well, the largest problem is that the input and output are both
> somewhat complex.
>
> Here is what I am thinking-- the actual application reads arguments
> from stdin and prints arguments to stdout.  Thus you feed the
> application key-value strings (like login=username) and these get
> translated into form variables.  Then two special ones are used:
> module and method.
>   
This would break some applications I've currently written... that
doesn't sound that easy to access from languages like PHP.

It seems to me that whatever interface we build should be generic enough
to share semantics between the CLI and some sort of remote execution,
like XML-RPC. I'm currently building a number of Ajax web applications
that use REST semantics to pass similar numbers of arguments, and this
same code goes straight into the CLI interface. The current CLI syntax
seems fine to me, as long as it accepts these arguments either on the
command line or in a GET string or in the body of a POST.

What would really be an improvement, though, is changing how the
application responds. It currently returns a web page, with lots of markup.
> For example:
> login=myuser
> password=mypasswd
> ...
> module=AR
> method=list_transactions
>   
I would prefer the existing syntax for passing variables with GET or
POST, though I don't see a problem with supporting both...
newline-delimited and ampersand-delimited...
> This might print out something like:
> transaction_id1=10256
> customer1=My Customer
> invnumber1=1001
> ...
>   
Now this is getting useful. Much better response than a big web page to
parse...
> Does that sound usable?
> Any better ideas?
>   

To be dreaming here, it would be great to offer a generic presentation
layer, which could return these values in a variety of formats:
* HTML, according to a customizable template
* key=value pairs, newline delimited
* XML, in some simple schema
* JSON, for consumption by other web applications

I've already done this a few times, but in PHP (Smarty is a great tool
for this kind of thing...). But if we can separate this out, LSMB can
provide a solid financial cornerstone of a larger customized ERP
system... and really get webbified to play nice with other "Web 2.0"
applications...

-- 
John Locke
"Open Source Solutions for Small Business Problems"
published by Charles River Media, June 2004
http://www.freelock.com