Patch to SCM Stuff...

[Robert Graham Merkel]

Christopher Browne writes:
 > Unfortunately, I'm having _zero_ luck connecting to cvs.gnucash.org,
 > so I'm depending on local RCS differences to find the changes to be
 > made.
 > 
Christopher, I got mail about this - apparently the net connection is back up again.

 > The "global" change is that rather than using (string-append) to 
 > create the output, I've changed the (html-whatever) functions to instead
 > create lists.
 > 
 > Thus rather than:
 > (define (html-strong html) 
 >    (if html 
 >        (string-append "<strong>" html "</strong>") #f))
 > we get:
 > (define (html-strong html)
 >    (if html
 >        (list "<strong>" html "</strong>") #f))
 > 
 > Net result of this is that rather than generating a single string,
 > you wind up with a tree.
 > 
 > This means that rather than turning this into a string basically
 > by appending the strings together, via (report-output->string lines),
 > there is a tree-walker:
 >   (define (output-tree-to-port tree port)
 >     (cond
 >       ((pair? tree)
 >        (output-tree-to-port (car tree) port)
 >        (output-tree-to-port (cdr tree) port))
 >       ((string? tree)
 >        (display-report-list-item tree port))
 >       (tree
 >        (display-report-list-item "<B> Error! bad-atom! </B>" port)
 >        (display-report-list-item tree port))))
 > 

I rather like this.  We've been having
discussions on how to do this better, and this looks like a step in
the right direction.

 > What I'd _rather_ see, a bit longer term, is to use the XML generator
 > to generate HTML output.
 > 
 > A (very simple) table might be generated via:
 > 
 > (define simple-table
 >   (xml-element 'table '(border 1)
 >     (xml-element 'tr #f
 >       (xml-element 'th #f "ISO Code")
 >       (xml-element 'th #f "Country"))
 >     (xml-element 'tr #f
 >       (xml-element 'td #f "USD")
 >       (xml-element 'td #f "US Dollars"))
 >     (xml-element 'tr #f
 >       (xml-element 'td #f "CDN")
 >       (xml-element 'td #f "Canadian Dollars"))
 >     (xml-element 'tr #f
 >       (xml-element 'td #f "UKP")
 >       (xml-element 'td #f "UK Pounds"))))
 > 
 > and would turn into well-formed HTML via:
 > 
 > (output-xml-element simple-table port)
 > 
 > The benefits of this are fivefold:
 >   a) Many pieces of this can represent shared data; 'td does
 >      not exist 12 times, as it would if the string "td" were used, but
 >      rather exists exactly _once_.  This should be a pretty big deal.
 >   b) You have better guarantees of well-formedness, and don't need
 >      to track end tags and the likes.
 >   c) As a tree, the _pieces_ stay distinct until they are actually
 >      rendered, and the pieces can remain interpretable as complex
 >      substructures.  You could, for instance, choose to process a 
 >      particular subtree, and skip over others.  That would require
 >      nasty parsing in a 'string-oriented' representation.
 >   d) It's possible to do lazy evaluation; rather than evaluating this
 >      whole thing at once, much of it may be able to be generated on
 >      demand.  The lines of the table might not exist until the moment
 >      before they're outputted as strings to the port.
 >   e) What you essentially wind up with is an HTML "parse tree," and as
 >      it is stored in a parsed form, it becomes a whopping lot more 
 >      practical to write code that interprets it in some other way.
 >      The "trivial" mapping is to take the resulting list:
 > 	(define simple-table
 > 	  '(table (border 1)
 > 	    (tr #f
 > 	      (th #f "ISO Code")
 > 	      (th #f "Country"))
 > 	    (tr #f
 > 	      (td #f "USD")
 > 	      (td #f "US Dollars"))
 > 	    (tr #f
 > 	      (td #f "CDN")
 > 	      (td #f "Canadian Dollars"))
 > 	    (tr #f
 > 	      (td #f "UKP")
 > 	      (td #f "UK Pounds"))))
 >      
 >      and walk it, generating HTML tags for all the symbols and strings.
 > 
 >      The next step would be to walk the tree and generate a Gnumeric
 >      spreadsheet or a text output file.   I wouldn't want to _think_
 >      about doing this with raw HTML; it is _conceivable_ with the
 >      tree representation.

Raw text, certainly - and if you wrote some DSSSL scripts you could
use Jade to generate TeX, IIRC.  I'm still not convinced
you'll get an _idiomatic_ gnumeric spreadsheet out of it, though.
However, it's certainly better than what we have.

One other point that you missed is that if we do this, we can have the
benefits of a fixed "report look", but people can code their report
generators in virtually any way they like.  All they have to do is
generate the tree using the tags we specify, and they get all the
beauty and flexibility of our future export options :)

I'm in the middle of coding up something, so when I've finished that
I'll have a play with your patch.

------------------------------------------------------------
Robert Merkel	                           rgmerk@mira.net

------------------------------------------------------------