Re: RFC: Proposed Framework Change for 1.4

[Chris Bennett <..hidden..>]

Chris Travers wrote:
> 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.
PostgreSQL 8.4 will be/is supported by OpenBSD (-current).
> 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.
I like anything that makes customization easy.
> 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.
4 and 5 sound good, but also a bit complex for someone wanting to 
contribute to get their mind wrapped around it. I think some good 
documentation and comments would probably be worth the effort from here 
forward. As more and more old code is removed, it seems like a better 
time is arriving for new people to help.
Moving UI stuff outside of workflow will also give a lot of 
opportunities for people who don't know much db stuff, but good with UI 
stuff to really add to those areas.

Chris Bennett