New reporting system

[two old]

So basically we need a script that keeps all options open:

if custom script exist -> execute ([user dir]/script)
else use standard script.

if custom template exist -> use it ([user dir]/template)
else use standard template

Fill template with data

switch (option-browser)
case internal browser:
case external browser:

The option-browser can be a selection the user can make. I agree we do
not want to launch an external browser if we are navigating the accounts.
But for reports/invoices it may be an acceptable alternative.
And in time when the internal browser gets better the option external
browser will not be used anymore.

Maybe the script will have to rip some style tags for the template if the
browser of choice is internal. I don't know I'm not familiar with the
capabilities of the internal browser.

There can even be an option in the configuration “use standard or use
custom” if the user wants to see the effect of the standard
script/template.

With all the individuals on this world removing the reasons why
individuals users need to have a customized/non-installed report is in my
opinion an idle hope.
In my opinion the individuals will customize the script/template, this is
a fact. Therefor you have to define the restrictions rather then program
for every eventuality.

Sun Tzu (the art of war) said: Do not trust on the enemy not attacking
but be prepared to encounter him.


  ----- Original Message -----
  From: "Josh Sled"
  To: "two old"
  Subject: Re: New reporting system (Re: Again font size when printing)
  Date: Thu, 29 Mar 2007 17:17:11 -0400 (EDT)


  On Thu, March 29, 2007 3:16 pm, two old wrote:
  > First I agree a script should output content to a HTML template.
  The
  > template would secure the way my invoices or reports look on every
  update
  > of GnuCash or even an update of the script.

  There's a separate set of concerns about customizing reports. If we
  install a revised report as a script + template, and you customize
  the
  template in the install location, it'll still get over-written at
  upgrade
  time. There are use-cases for both customizing only the template, and
  more so customizing the whole report (and likely the template).

  In my experience -- particuarly: customizing bugzilla both before and
  after they introduced explicit UI templates -- it can be almost as
  hard
  either way. Effort is required to revise a report in a way that
  customized templates are guaranteed to work going forward. Most
  likely,
  one wants to enhance the report, and thus the template, which will to
  some
  degree invalidate the customized templates as well.

  It's a pretty standard problem, so I'm not sure that we should do
  anything
  more than make it: a/ easier to customize the reports and templates,
  b/
  encourage those customizations to be conditional/config-driven and c/
  encourage contribution and thus our re-distribution. Basically:
  remove
  the reasons why individuals users need to have a
  customized/non-installed
  report that can be overwritten or invalidated.


  > If we can make a script that put content into a HTML template and
  then
  > launch a web-browser to view and/or print it, this would be a huge
  step
  > forward.

  That's an interesting idea ... I'm not sure that it's the best user
  experience, though, in terms of the interactive refinement of the
  standard
  reports... where you change the date range, change the graph
  parameters,
  and don't really want to see another spawned browser instance.
  Moreover,
  we do support hyperlinking strings (and historically plot/graph
  elements)
  with other GnuCash interface elements like accounts registers and
  customers. In that case, you even more so want the browser embedded
  for
  practical/integration concerns.

  But if we do embed or use a browser component to which we can offload
  most
  of the heavy lifting of printing, we should leverage that.


  > Besides that, step one can be developed without interfering with
  the
  > printing libraries as they are now. I think ...........

  The printing libraries are changing, so we do need to modify
  gnucash's use
  of them to stay "current" with our dependent libraries. The reports
  are
  the major consumer of printing services in GnuCash, but there are
  others.


  > So first of all I'm looking for an understanding of how this
  > printing/reporting/scripting business essentially works. I
  understand C
  > but I know nothing of Scheme. Nevertheless maybe I can make a start

  For the existing code, there is some documentation in the source
  tree; in
  short...

  The report (a scheme script) is evaluated; it calls on the
  gnucash-provided reporting system to install itself into the report
  list
  and menu. When the menu item is invoked, a report-defined callback is
  called to generate a (html) document, which is then rendered in the
  gnc-plugin-page-report window, using gtkhtml. The report also defines
  an
  operation generator (another callback function), which is used to
  create
  the report options UI; when Apply (or Ok) is pressed in the options
  dialog, the old document is thrown away and the report's rendering
  callback is re-run.

  --
  ...jsled
  http://asynchronous.org/