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. _______________________________________________ gnucash-devel mailing list [email protected] https://lists.gnucash.org/mailman/listinfo/gnucash-devel
