> I have been thinking a bit regarding ways forward. In particular the > financial rewrite never seems to go the way I would like it to. >
We spoke a bit about this over PM last week. Maybe we can use this (or a new) thread to define what it means to you? I'm not really clear on what the term "financial rewrite" really means to you. Although I do have ideas about breaking down the scope of rewriting the remaining SQL Ledger code into a larger number of smaller rewrites. Before we can do that, though, I think we have a number of areas where we should put requirements/design/workflow in place. I'm thinking about things like these: - Document workflow: Create -> Save -> [ Edit -> Return to Save ] -> Post -> Reproduce [ -> Copy to new ] [ -> Schedule ] - Rounding - Subcent prices on anything that's not in the ledger (parts prices?) stuff like that. We have at least one important feature slated for 1.6, and that is the > multi-currency improvements Erik has been working on. I would like to > suggest we do one other thing as well, namely finish App::LedgerSMB::Admin > and App::LedgerSMB::Admin::Web, and use these to replace the current > setup.pl. > It's my understanding that these will serve a much broader range of functionalities than setup.pl, am I correct? More like a toolset for managing companies within a PostgreSQL cluster (i.e. multiple databases)? Is there anything more to say about it than that? Work that is left to do here is to add a setup wizard and add user > management functions to the web interface. A major advantage would be an > ability to manage multiple LedgerSMB instances from one console, better > command line management, and restful interfaces for core administrative > functions. > Also, version 1.x of the admin interface uses jquery and templates in a > fairly old-fashioned way. We may want to move to dojo there and start a > 2.x branch of this. > Sounds good, but I think that creating services early on allows easier dojoification, because Dojo applications typically benefit from a well structured service infrastructure on the server. Having a full-scale web app based on templates before going Dojo will be a lot of effort wasted on the 'traditional' webapp. That would allow us to remove > > LedgerSMB::Darabase > LdgerSMB::Scripts::setup > and maybe a little more. > Removal is generally good. There's one important question though: should we move these into our tree or not? As we factorize many components, it might become harder for people to install the factored-out dependencies. While this may or may not be the case, I think it's something to think about long and hard before we throw up road blocks to installing LedgerSMB. I would also like to suggest we look closely at one of the following areas > (would be interested in hearing where folks largest frustrations are here) > in terms of UX, web services, and the like: > > chart of accounts, or contact management. > > Any thoughts on prioritiing these? > If I can have a vote: Please start with services for contact management. That'll allow easier Dojoification of the contact management screens, which hopefully will help with the clarification of them. -- Bye, Erik. http://efficito.com -- Hosted accounting and ERP. Robust and Flexible. No vendor lock-in.
------------------------------------------------------------------------------
_______________________________________________ Ledger-smb-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel
