[EMAIL PROTECTED] writes:
> Turns out (duhh) tightly intertwining html with code is a bad idea,
> whether that is C or perl or scheme. So I'd strongly advise against
> the style shown above, other than maybe as a test case/scaffolding.
Right. I just meant to use it to replace what we have now, and then
find (or write) something better as soon as we get the chance.
> The above req's are pretty much verbatim to similar requriements on
> interactive web-page design. You don't want the web site maintainer
> to screw up the C/scheme code, you don't want the C/scheme coder
> creating bud-ugly web pages.
I think I agree with all your points.
> 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".
> 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 --
i.e. you can't do it with regexps, and second, though more flexible,
this approach is potentially more dangerous than (1). It makes it
temptingly easy for people who you're wanting to keep from being able
to shoot themselves too easily to just throw in code.
However, if we leverage scheme's built in parser, we can add as much
safety as we want (we can pick our point on the power/safety tradeoff
continuum), and we can avoid incurring the penalty for calling eval to
whatever extent we like (though the penalty isn't that high when
you're not talking about compiling your scheme code).
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>"
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.
We could also have per-report-template hashes containing the symbols
and their bindings and the allowed functions rather than allowing the
report to call globals. This would be easy.
However, I'm not sure everyone would be happy with this approach. It
would mean some awkward bits, like all double quotes in strings would
have to be escaped with \
"The " meeting-date " was \"better\", but not really good."
> 3) Use jsp's.
Don't know anything about jsps, so I can't comment.
> I personally like 1) the best, but I think a lot of people will hate it,
> and so I think 2) is the obvious choice.
(1) is trivial to implement. (2) is a little harder, but still less
than two pages of code, I suspect, and (2), though more powerful, is
also "uglier" and more dangerous.
--
Rob Browning <[EMAIL PROTECTED]> PGP=E80E0D04F521A094 532B97F5D64E3930
--
Gnucash Developer's List
To unsubscribe send empty email to: [EMAIL PROTECTED]
