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 ------------------------------------------------------------------------------ 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
