> On Dec 24, 2014, at 12:22 AM, Dmitry Pavlov <zeldi...@gmail.com> wrote: > > A brief search through list did not bring any results, so I decided to > start a new one. > > First of all: no offence but most gnucash reports are poorly implemented. > It's not because they useless or looks not pretty (most of them are useful > and good, calm down :)) . The reason is that a model (i.e. data of the > report) is completely messed up with the view (html tags) in report > generation code + html creation tag by tag is really outdated now, there > are more proper tools like templates for that. > > Of course it's a really huge work to rewrite that completely in more > model-view style or rewrite that in different language.
Not only no offense, no kidding! > > So I have idea: Gnucash already have an infrustructure of invoking scheme > reports, saving settings, etc. > What about implementing some "wrapper" report that can just invoke some > script (for example that use python bindings). In it's settings we can > point to specific script and all guile invocation would just > 1. include execution of that script with passing parameters from options > 2. grab output that is supposed to be report content (html for now) and > include that as it's own result Isn't our report system already too complicated? Geert has already mentioned that we're going to re-engineer GnuCash to use a SQL database internally; this is our plan for implementing concurrent multi-user access. That alone will vastly simplify the reporting architecture. It will also mean that SQLite3 rather than XML will be the preferred file format for most users and MySql or PostgresQL for those who need multi-user capabilities or who like running a DB Server. That in turn moves the preferred mechanism for custom reporting entirely out of GnuCash: Simply fire up your SQL report generator of choice, write your query, and run the report. You can actually do that now, as long as you don't trip over one of the corners where GnuCash writes to KVP without doing an edit-commit on the object owning the KVP. I can't say that it's the recommended approach for all custom reporting because of those corners, but if you can satisfy yourself that the SQL backend works correctly for your usage it's certainly easier and more future-resistant that writing a custom report in Scheme. Regards, John Ralls _______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
