It's been rumoured that Rob Browning said:
> > You can give the HTML widget an HTML string, yes.
> >
> > As I understand it, the way report generation works now is that
> > eperl is invoked on an html file with embedded perl commands which
> > use the perl<->engine bindings to calculate the values to put in the
> > report.
>
> That's what I suspected. So it sounds like it would be pretty trivial
> to just do something, even if temporarily, like:
>
> (display "<html>" port) (newline port)
> ...
> (display whatever)
> ...
> (display "</html>" port) (newline port))
I have more bitter experience here I'd like to share (well, not bitter,
as the second time around, it didn't hurt me. I got to point my finger
and laugh and say 'I know how to not make *that* mistake').
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.
The 'requirements' are these:
-- you want non-programmers to be able to create custom reports. These
may be artistic types looking to beutify the html page/layout, or 'power
users' trying to create custom financial info. Its safe to assume they
can pilot around html at some level. Its bad to assume they can decipher
anything but the very very simplest perl. I'm even more woried about
scheme.
-- you want people to do the above without (a) breaking the build
(b) killing thier app. Worst case, they break the report, but the rest
of the app works.
-- you want the programmers to be able to modify gnucash internals
without having to hand-edit 1001 reports and report-plugin submissions.
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.
There are three solutions that are in common use.
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).
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).
Examples: livewire/javascript (uses <server></server> tags)
jthml (uses the <java></java> tags)
php3, eperl (uses the <: ... > or <? ...> tags)
I suppose we can do this with scheme as long as we simplify it to the
point where non-scheme non-programmers can use it.
3) Use jsp's. The java folks have been around teh block a few times,
and have developed JSP's as the logical next step. It provides
for all the features and sophistication one might ever want in an
interactive page. I think a lot of the smart web designer will end up
going there. But maybe its overkill; at least for us it seems like
overkill.
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.
--linas
--
Gnucash Developer's List
To unsubscribe send empty email to: [EMAIL PROTECTED]
