It's been rumoured that Rob Browning said:
> > 1) create a special markup language, and let an interpreter make
> > substituitons into it:
> >
> > <html>The account name is <acct_name>
> > The account balance is <balance>
> > <html>
> > Pros: effective, high performance, low-tech, simple.
> > Cons: limits on flexibility. (but my experience is that this is not a
> > problem, and if someone wants to engage on this, I can explain how).
>
> This would be trivial to do in guile. We could just mandate that all
> the tags look like this <(some-tag)> and then suck in the file, use
> guile regular expression matching to perform substitutions for a
> defined set of symbols, and spit the result to the html widget.
> Something like:
>
> <html> The balance is <(account-balance)>. </html>
>
> and we could provide a simple interface where we can register the
> symbols with the thunks that generate their output for a given report
> "template".
Right. In fact its a tad more complex than that (which account was that
balance for? what dates was it on?) but not much. I've had good luck
with populating heirarchical trees of key-value pairs, and walking those
trees to fill in the blank fields. Hmmm. I have to rethink this for
gnucash a bit. I think some more sophisticated examples are in order.
> > 2) create embed tags, and run it thorough a perl/javascript/java
> > interpreter:
> >
> > <html>The account name is <perl> $acct_name </perl>
> > The account balance is <perl> $balance </perl>
> > <html>
> >
> > Pros: flexible
> > Cons: poor performance (for web sites, that is, for gnucash it shouldn't
> > matter).
>
> Two more cons: First, without implementing/using a real parser, you
> can't safely *always* recognize the tags in this kind of approach --
Bzzt, you missed the point, you don't need to implement a parser (that
was PHP's big mistake that eperl solves). All that the start-tag does is
imply 'pipe this from here, up to the end tag, to the stdin of the
real parser'. Typically, you introduce a teeny-weeny bit of syntactic
suger, i.e. the above perl example automatically generates the following
piped to perl:
use gnucash;
xaccSessionOpen ("asdf.xac");
$acc=xaccAccountOpen(...);
print "<html>The account name is $acc->acct_name
The account balance is $acc->balance <html> "
Basically you slip in a prologue, and epilog, dress it up and convert it
to 100% valid perl piped to the real perl interpreter, and not a fake.
I'd have written the example in scheme if I knew scheme better.
> What you could do, if you were willing to have a notably uglier syntax
> (for report template writing) than I suggested in (1) above, is have
> the user write the templates like this (much easier to read if you
> have string highlighting):
>
> "<html> The balance is " account-balance ".</html>"
>
> or
>
> "<html> Yesterday was " (current-day -1) ".</html>"
No, I don't like the quotes, I'd rather argue that the fundamental form
is this:
<html> Yesterday was <scheme>(current-day -1)</scheme>.</html>
If you wish, we could also define the following abbreviated equivalents:
<html> Yesterday was <s/>(current-day -1)</>.</html>
<html> Yesterday was <s/(current-day -1)/.</html>
These are sgml-ish. Using quote marks I think just is asking for trouble.
> where the input is a sequence of items: scheme strings, symbols, or
> lists. Given that, we could (in almost no code) whip up a loop what
> reads the file as a sequence of forms, and anytime one of these forms
> is a string, it prints the string, if it's a symbol, it prints
> whatever the symbol is bound to, and if it's a list, then it either
> calls eval on the list and substitutes the result, or, if we want more
> control, it selectively evaluates the list in a manner we specify.
Right. exactly. We also automatically pre-pend whats needed to
set up the accounts, etc. so that this simple loop 'just works'.
This is more or less exactly how the perl reports work today.
> > 3) Use jsp's.
>
> Don't know anything about jsps, so I can't comment.
But you now know enough to read the jsp docs. They're trying to solve
this exact same problem, and they've trained considerable firepower on
it. Its too java-centric to be useful for us, but it can be pirated for
good ideas.
--
Gnucash Developer's List
To unsubscribe send empty email to: [EMAIL PROTECTED]
