Looking for feedback for 2-step view style reports

[Christian Stimming]

Dear Matt,

your ideas sound very good so far, but also rather ambitious. My current take 
on the reporting subsystem and definitions of extra levels of abstraction 
before the final rendering is that this problem is a hard one. IMHO every of 
gnucash's currently available levels of abstraction of a report still has 
serious drawbacks. We saw several attempts over the years to define some level 
"which has all the numbers but no rendering yet", but IMHO they all got stuck 
in some clumsy state. Just recently I've been working on defining some 
completely new reports, and - sorry for any fellow developer reading this - it 
still sucks as much as it did 10 years ago. I'd be more than happy to see a 
working implementation which really relieved the report writer from thinking 
about the rendering design or vice versa, but I just think this problem proved 
too hard to be solved so far. I.e. if you can find a good solution, chances 
are good that others are more than happy to incorporate it in here as well.

I think the big problem is that "a data structure (which I'm calling 
docstruct) which consists of a vector full of named lists"  might still not 
yet cover all cases of interest for the report that should be shown to the 
user. For example, names or numbers that should also contain a hyperlink might 
need special treatment - probably your list elements need some sort of 
attributes where things like a hyperlink can go to. Also, the various 
completely different levels of grouping were one issue where the different 
report scm files took completely different approaches, implying that a common 
level of abstraction for that part seems rather difficult.

That being said, the gnucash reporting interface is open for many different 
approaches. We can add a different reporting subsystem for a set of 
complementary reports which we didn't have beforehand, and they can  live in 
parallel to the old existing reports without any difficulties. My advice to 
you is to just go ahead with your ideas and implementing that sort of report 
which you have in mind as an application, without bothering about backward 
compatibility or any of the existing reports. Just go ahead and try your 
ideas, ideally with one particular fully implemented example where we can see 
the results "from the user's point of view". I'm looking forward to hearing 
how things are going.

Best Regards,

Christian

Am Saturday 02 October 2010 schrieb Matt Whipple:
>  I'm presently looking to modify the report system so that a semantic
> representation of the data can be returned, and wanted to get some
> feedback from anyone more familiar with the system (or languages
> involved).  My personal goal is to allow for outputting XML, but rather
> than just modify the existing formatting in the reports to use that
> output I'm thinking of changing the report system so that there is a
> clearly defined gathering of data which is then passed to a renderer.
> 
> My thoughts are to represent each document as a data structure (which
> I'm calling docstruct) which consists of a vector full of named lists.
> This would then be complemented by a set or sets of functions in charge
> of populating the data (ultimately possibly updating the app data though
> that falls outside of "reports"), and a set or sets of functions which
> use the data in the structure to render a presentable form.  The names
> within the structure would allow for self-documenting and a decent
> amount of attempted automatic behavior which could be selectively
> overridden (ideally having basic functionality by just creating an empty
> structure with names).  Let me know of any feedback.