Reporting system and potentially Python

[Phil Longstaff]

I'm not sure I would use Javascript to create the report code, but I could definitely see embedded Javascript into the reports to make them more interactive.  Any place there is a parent account with children indented an arrow icon could trigger javascript to hide/show the children.

Does swig generate javascript bindings?  Could we think of using javascript to generate a report?



________________________________
From: Christian Stimming <christian at cstimming.de>
To: John Ralls <jralls at ceridwen.us>; Tim M <tim at filmchicago.org>
Cc: gnucash-devel at gnucash.org
Sent: Thursday, July 7, 2011 4:24:10 PM
Subject: Re: Reporting system and potentially Python

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.

Regards,

Christian
_______________________________________________
gnucash-devel mailing list
gnucash-devel at gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel