RFC: Proposed Framework Change for 1.4

[Chris Travers <..hidden..>]

Hi all;

While the 1.3 framework is a great improvement on the 1.2 framework, I have noticed a number of things that I think should be changed, as well as a few new opportunities to simplify things in 1.4.

First, I would like to propose that 1.4 be targetted at PostgreSQL 8.4 or higher, and require whatever DBD::Pg modules are current at the time when 1.3 is released (i.e. the time when we begin serious work on 1.4).  LedgerSMB 1.3 would remain supported for a number of years after release (at least 3) so this shouldn't cause any real headaches in terms of forcing folks to upgrade.....  8.4 would also allow us to do away with the dependency on tablefunc for the menus and move to WITH RECURSIVE instead, and it would allow a number of other things that could be used to better enforce data integrity between the app and the db.

Anyway, here are my other areas I would like to see addressed:
1)  The current system presents hazards of customization.  One option ot address these is to implement a before/instead/after structure and move UI template rendering out of the workflow script.

2)  Workflow scripts should be moved to LedgerSMB/Scripts/

3)  Dialog:  Do we want to continue having top-level scripts past 2.0?  I know this has been a point of criticism in the past.  However, it is something that will probably have to be changed around 2.0.  What do folks think?  What should be the ideal call interface?  Maybe http://host/ledger-smb/request.pl?module=journal or something like that?

4)  Our object structure in 1.3 is better than that in 1.2 but it still has some serious shortcomings.  The biggest one is that the modules are still grouped in functional units.  This means that object properties are not entirely consistent across uses of the same object, which makes documentation and tracing a bit difficult.  Fixing this will require refactoring.  I would like to have this refactored into a properly documented and designed object oriented framework.

5)  I would like to revisit a few elements of the database interface calls as well.  In particular, the latest DBD::Pg and PostgreSQL allow us to easily make use of more complex db-side datatypes.  If we go this route, we should be able to define our data structures in the db, as complex types, and build database requests out of it.  We could also allow primary object attributes to be defined this way, while secondary arguments could be defined in a way to allow explicit function calls.

What do folks think about these proposals?  Anything else that needs to be added?  Anything that should be up for discussion?

Best Wishes,
Chris Travers