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
------------------------------------------------------------------------------
Enter the BlackBerry Developer Challenge
This is your chance to win up to $100,000 in prizes! For a limited time,
vendors submitting new applications to BlackBerry App World(TM) will have
the opportunity to enter the BlackBerry Developer Challenge. See full prize
details at: http://p.sf.net/sfu/Challenge
_______________________________________________
Ledger-smb-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel
