What I'm looking for is this: Separate the act of actually gathering the data from the GnuCash database from transforming it for display, so that the output can be made much more interactive and easy to style and make 'pretty' :). Use a well known programming language to aggregate the data to make it easier to create new reports which output different sets of data.
I've thought about this a little bit, and here is what I am thinking. Let me know if this sounds un/reasonable or just plain incorrect. (Note that I am basing this off of not being familiar yet with how the current scheme architecture actually manages pulling the data out of gnucash, so please correct me where I am wrong or point out the significant flaws) 1. Create the 'new' reporting system alongside the existing one so that the reports do not suffer until the existing functionality can be fully replaced by the new system. After all reports are replaced and working, the old scheme code could be pulled. 2. Create a set of libraries and/or use the existing gnucash libraries for querying information from the database. Based on the discussion, I presume C or Objective C would be best and just avoid Python/Scheme altogether (I am not sure how the scheme system actually performs the data queries right now). If all the necessary code is already in place, then this does not require any work. 3. Using these libraries, create the code for aggregating the data (also in C or Objective C) for each report. A single prototype report would be OK to start. Output the report data as structured XML. The XML data should adhere to an XML schema. 4. For each report, create an XSLT file which will transform the data into HTML/XHTML for display. 5. A small amount of javascript would be needed to perform the actual XSLT transformation but it would be pretty small. 6. Style the page elements using CSS. Also, I think the jqplot patch that has been made could be migrated in to the new reporting system, as those graphs look really nice. I think there are several benefits to this approach: 1. Currently reports can only be exported as HTML. By making the reporting code export an XML data structure, reports could be easily exported from GnuCash as XML (pre-transformation) or as HTML (post-transformation). 2. Anyone could write their own XSLT transformation file to display the data differently. 3. The actual XSLT, HTML, and CSS code would be very easy to read and modify by anyone familiar with it. The backend reports would still be in C/Objective C for compiling the data and as such require some coding knowledge, but it would be much easier to start using than the existing scheme code. 4. The XSLT and CSS could be very easily modified and applied not only inside of GnuCash, but a user could also take the XSLT and CSS scripts, modify and apply them to the exported XML reports to give it their own look without touching the GnuCash code base at all. For example they might want to style a report with a company logo or different colors or other graphical elements. 5a. In the future, it would be possible to provide multiple different XSLT and/or CSS styles for the reports so users could select the appearance of the reports. (If someone writes additional styles) 5b. In the future, it would be possible to allow users to import their own style sheets into GnuCash and apply them to the reports. (if someone writes the code to manage the import and style selection) 6. No reliance on Scheme or Python. Minimal Javascript, but that should be handled easily by webkit. Thoughts? -Tim On Thu, Jul 7, 2011 at 4:58 PM, John Ralls <jra...@ceridwen.us> wrote: > > On Jul 7, 2011, at 4:24 PM, Christian Stimming wrote: > > > Am Donnerstag, 7. Juli 2011 schrieb John Ralls: > >>>> So I am OK with needing to get more familiar with something > >>>> such as Python, C, or Java to do the work, but I don't want to get > knee > >>>> deep in a major feature patch to find out something else is preferred. > >>> > >>> If you are able to insert some python code that will display some > report, > >>> I will fully agree this to be a worthwhile goal and I will happily > apply > >>> your patches to SVN trunk. > >> > >> Christian: Please don't accept Python code into Gnucash. Python has > >> version-to-version compatibility problems, and I've found with > pure-python > >> applications like Gramps that it requires bundling a Python interpreter > >> with the application so that everyone gets the same version. > > > > You do realize that gnucash already comes with a lot of python code for > quite > > some time being, don't you? Namely we already have the python wrappers > for the > > core engine object being generated by SWIG for approx. 2-3 years by now. > More > > recently, there has been an optional python module added so that the > framework > > is already there to do some real new features with that. > > > > To me, issues with version incompatibilities in python are indeed a > drawback > > of that language, but all languages have drawbacks and advantages. The > clear > > advantages to allow python code in gnucash is that > > * the python wrappers for all engine objects are already there, so using > them > > is a rather efficient way of using your time to implement something new > > * the python language is significantly more easy to learn and suits the > > "normal programmer's thinking" much better than other languages > > > > As for JavaScript, you have the disadvantage that we (so far) don't have > > wrappers for all of our engine objects, so this is a very boring task > that > > needs to be begun and somewhat completed first. Also, the JavaScript > language > > is significantly difficult to work with in a serious way. It's much more > like > > Scheme than one would initially expect, and it suffers the same problem > than > > Scheme: Only a smaller set of programmers really understand the concepts > > behind it well enough to create good architectures in that language. > > > > With this being said, we had Tim's question here: "I'd like to improve > > something with the reports; which language should I use." With the above > > advantages and disadvantages, I still think the most efficient way for > Tim to > > spend his time is creating a report in python. And yes, I still think I > will > > happily add related python code into the optional src/python/ module, > even > > though we know about the limitations of python w.r.t. version issues. But > we > > also know about its benefits. My cost-benefit comparison so far still > turns > > out python as the suggested way to proceed for now. > > There's a big difference between a toy Python console for hackers and > reports at the core of user interaction with Gnucash. Like src/gnc, > src/optional.gtkmm, and src/cmakefilemodules, src/optional/python isn't > appropriate to include in a general-distrbution binary. The standard reports > *must* be included in such a binary. > > You're right, though, that Javascript is a non-starter. I hadn't adequately > investigated what it would take to access the data from javascript. (Details > in my reply to Phil.) > > I think Tim is looking for something different than you think, but I'll let > him speak for himself. > > Regards, > John Ralls > > _______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
