Christopher Browne <[EMAIL PROTECTED]> writes:
> When spitting out HTML, I'd *strongly* urge doing something like what
> is attached below.
GACK -- that's a lot of info :>
I don't have time to read it carefully right this minute, but I'll get
to it. At the moment what I have is a mostly straightforward, mostly
finished scheme rendition of what we were doing in eperl.
I'd like to get that out. Then I'd like to figure out how to modify
(or overhaul) it to support the "right thing", which it looks like you
may have a better handle on than I do. You've certainly outstripped
my knowledge of html by at least seven orders of magnitude. However,
I do want to be careful and not bite off too much at one time.
> --> By having an ID, this offers a route for the HTML browser to
> (perhaps) "drill" back to GnuCash. e.g. - you double-click on
> the transaction, and GnuCash jumps to that specific transaction.
> Yes, this involves some "rocket science." That ID needs to be
> like unto a CORBA IOR, a somewhat permanent ID for the split, in
> order for this to work.
This is something I eventually want as well, though if we knew that
for the life of a given Session, all transaction pointers would remain
constant, we could just embed their hexadecimal values in the page.
Of course, this depends on the object identity semantics, and ATM I
can't recall if the engine strongly preserves object identity as
pointer equivalence. However even if it does, with this approach, we
couldn't just delete objects, since a visible report could still have
a reference to it. Of course this is fairly easy to handle in a
garbage collected system, but can be tricky otherwise. I suppose if
we were smart enough to dynamically update all the reports whenever
the underlying accounts changed, then we'd be in the clear too.
--
Rob Browning <[EMAIL PROTECTED]> PGP=E80E0D04F521A094 532B97F5D64E3930
--
Gnucash Developer's List
To unsubscribe send empty email to: [EMAIL PROTECTED]
