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:wxpos_invoice_sell_new (integer): This function gets the customer id and set a couple of temporary tables (like taxes, list of items, etc) to follow the operation.
wxpos_invoice_sell_add (integer, text): This one gets quantity and barcode, add the item to temporary tables, calculate taxes, etc.
wxpos_invoice_sell_del (integer): WIP - This will delete the item id and reverse all previous calculations.
wxpos_invoice_sell_post (): 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