On Tue, Sep 18, 2012 at 7:12 AM, Andres Basile <[email protected]> wrote:
> Hello Chris,
> My personal opinion would be to move to 9.2 and using json as protocol
> between server and client, but, my understanding is that it will need a new
> kind of client, able to request, understand json and fill the html, also,
> it would need a new kind of handler.
>
Not really. Doing full JSON would require a lot of additional work. This
is specific to the extended attributes, which would not be searchable etc.
but would be understood in JSON.
> Instead of work on that, I would focus efforts on database and store
> procedures, my personal experience contributing to this project was to
> reach the database layer and to don't know what to do.
>
Yep, that's a long term goal. Actually if we can I'd like to do this for
all the financial logic. More on that soon btw.
> What I mean is, if the database had a full set of procedures working as
> abstraction layer it would be easy for development to add new
> extensions. When I was writing the wxpos, I started to write a new approach
> with procedures, the idea was to give all the logic to the database and use
> the client/handler just like an IO interface.
>
Yep. In fact for the new stuff in 1.3, these are discoverable. You may
want to take a look at the LedgerSMB/DBObject.pm for how we do the
discovery, or look at sql/modules/Assets.sql for some examples. These are
nice because they are discovered at run-time and so the application doesn't
actually need to know which arguments go where in the argument list. It's
like SOAP for stored procedures but better ;-).
I have ideas for improvements, but effort needs to go into current work
first.
> Let me try to explain this with an example:
> <http://192.168.7.21/phppgadmin/redirect.php?subject=function&server=localhost%3A5432%3Aallow&database=solucionya&schema=public&action=properties&function=wxpos_invoice_sell_new+%28integer%29&function_oid=23928>wxpos_invoice_sell_new
> (integer)<http://192.168.7.21/phppgadmin/redirect.php?subject=function&server=localhost%3A5432%3Aallow&database=solucionya&schema=public&action=properties&function=wxpos_invoice_sell_new+%28integer%29&function_oid=23928>:
> This
> function gets the customer id and set a couple of temporary tables (like
> taxes, list of items, etc) to follow the operation.
> <http://192.168.7.21/phppgadmin/redirect.php?subject=function&server=localhost%3A5432%3Aallow&database=solucionya&schema=public&action=properties&function=wxpos_invoice_sell_add+%28integer%2C+text%29&function_oid=23926>wxpos_invoice_sell_add
> (integer,
> text)<http://192.168.7.21/phppgadmin/redirect.php?subject=function&server=localhost%3A5432%3Aallow&database=solucionya&schema=public&action=properties&function=wxpos_invoice_sell_add+%28integer%2C+text%29&function_oid=23926>:
> This one gets quantity and barcode, add the item to temporary tables,
> calculate taxes, etc.
> <http://192.168.7.21/phppgadmin/redirect.php?subject=function&server=localhost%3A5432%3Aallow&database=solucionya&schema=public&action=properties&function=wxpos_invoice_sell_del+%28integer%29&function_oid=23927>wxpos_invoice_sell_del
> (integer)<http://192.168.7.21/phppgadmin/redirect.php?subject=function&server=localhost%3A5432%3Aallow&database=solucionya&schema=public&action=properties&function=wxpos_invoice_sell_del+%28integer%29&function_oid=23927>:
> WIP - This will delete the item id and reverse all previous calculations.
> <http://192.168.7.21/phppgadmin/redirect.php?subject=function&server=localhost%3A5432%3Aallow&database=solucionya&schema=public&action=properties&function=wxpos_invoice_sell_post+%28%29&function_oid=23929>wxpos_invoice_sell_post
> ()<http://192.168.7.21/phppgadmin/redirect.php?subject=function&server=localhost%3A5432%3Aallow&database=solucionya&schema=public&action=properties&function=wxpos_invoice_sell_post+%28%29&function_oid=23929>:
> TODO - Once we are happy to go, this function will post all temporary
> tables calculations with a store procedure. warranting to save data or not.
>
> I'm not an expert to say it this is better or not, but I found
> this paradigm to be easy to extend without affect the core logic, I'm
> attaching a txt so you can take a look to them. I hope you find these
> comments useful, I'm a little far now a days, but I would like to
> contribute ever that I can.
>
We are actually doing something similar. The reason in fact why I am
suggesting JSON for extended attributes is that with a stored procedure
interface, it is a bit of a pain to extend in order to handle something
like "we need to track vehicle identification numbers on invoices for our
auto repair work." With JSON, we can just mark the field as extended,
convert to/from JSON in the app layer. Systems implementors can then
implement additional logic in plv8js if it is important to process this in
the db but that is nicely outside our scope.
Best Wishes,
Chris Travers
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Ledger-smb-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel
