Yawar's suggestion is quite interesting, but the declarative XML you suggest is bordering the functionality of a web service. I like the idea of having the XML declarations but there still then must be some way for the user to select individual accounts included in the report, which will require some communication between the reporting system and gnucash.
I think a web service would actually be perfect for this, as this would then totally externalize the reporting infrastructure. I'm not sure, however, exactly what implications this would have. I would have to see how this can be handled - if a port can simply be opened and listened on for requests, or if it would require bundling some type of web service such as tomcat. I would think it could be done just using a listening port but I haven't actually written a web service before so I'm not sure. There are probably libraries already available which could handle the requests, otherwise we would have to roll our own. Also, I wonder if we can make the actual requests with Javascript - the WSDL would eliminate the C -> Javascript access issues mentioned earlier. What this would require then would be to create a WSDL for the available methods and then similar to Yawar's suggestion, the report would make a request to the GnuCash web service for the information needed to generate the report, and the web service would return the results as XML. At that point the XSLT would transform the XML data into HTML for display and voila, you have a report which has been generated entirely using code and methods externally accessible from GnuCash. Having a web service could make for some very interesting use cases such as generating reports directly inside a web page (such as if a business has an intranet where they want to be able to gather and view their financial data). Also, it opens up the possibility of creating additional web service methods which not only read but also write data. For example, a user could enter transactions from a web form and on submitting the form, the web service request is sent to GnuCash which adds the txn to the database for the appropriate account. Another use case for a read/write web service would be having a "GnuCash Server" which would mitigate the problems associated with having multiple clients reading and writing to gnucash at one time. For example, GnuCash would sit on a dedicated system listening for web service requests. Client machines running copies of GnuCash would then connect to the server (I think it could be implemented as just another interface to the data such as we have XML and DBI currently) to access the GnuCash data. Finally, when a user action causes a insert/update/delete request, all user's requests would go through the central GnuCash server so they would not be able to access the file concurrently, thus preventing user collisions when editing the file. This is of course very ambitious and wouldn't happen unless someone saw the need and implemented all of the functionality that would be needed in the web service, but you get the point. -Tim On Fri, Jul 8, 2011 at 4:21 AM, Geert Janssens <janssens-ge...@telenet.be>wrote: > John's suggestion to find something sql-query like to gather data might be > nicer, as would Yawar's proposal to go for a completely declarative report. > Both mechanisms work generically with the raw data and would adapt easily > to > data format changes. By the way, GnuCash comes with a query framework for > its > data: qof-query. It mayor may not be suitable as a basis for the first > suggestion. > > I'm tempted to say here that such a generic and easy to use interface could > be > implemented as a later improvement, but at the same time I have a feeling > that > such a decision should be taken early on, because it would greatly > influence > how everything gets implemented. > > > 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) > I already some kind of a theme foundry as part of the GnuCash website, > where > users can add stylesheets for others to use. Something in the lines of the > online kde/gnome theme stores > > Geert > _______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel