Improving internal report identifiers

[Andrew Sackville-West]

Hi guys, 

in the course of discussion intermittently beginning about:
http://lists.gnucash.org/logs/2007/12/2007-12-30.html#T01:42:12
it has become obvious that the use of the report names as an internal
identifier: building the hash table of report templates, referencing
the renderer in saved report and so forth, is a problem. 

This appears in #345824 and #505921. If for any reason the names of
the reports are changed (the internal names, that is), then the
currently open reports as well as (I'm sure though not tested) saved
reports will break. 

I have begun the work to include a new field in the <report-record>
constructor called 'report-id to be used only for the purpose of
referencing the report internally. It replaces the 'name field in
every *internal* reference to the report. In fact, I've already got
this working (though there is only one report in my tree with this
field in it... the menu looks kinda funny). The idea is that this
internal reference for the report would be free of the problems of
translation issues and would also allow reports to be renamed without
regard to compatibility issues with previous saved or open reports. I
see all this as good stuff. 

But, there is an issue of how to deal with currently open report and
previously saved reports. Changing how the reports are referenced will
break all of these in the same manner they would break in the bugs
above. There needs to be a method to construct a second set of
references alongside the primary one to allow these legacy reports to
continue to function. I propose to build a separate, parallel, method
of referencing reports using the current method as a means of
recalling reports only. It would also warn the user that it has
opened/recalled a report using the Name method which could break
without warning in the future. 

I think its a task I can definitely handle in terms of coing it up,
but I want to make sure I get some guidance on

1) whether it should be done at all (I think so)? 

2) if there are any inherent problems with the idea? I think it's the
   "right" way to do it, separating the internal reference from the
   visible name.

3) how to handle the saved reports. specifically, how to get the user
to actually go in and fix the things -- do they need to edit the file
by hand? can they just resave the report and have it overwrite the old
one (ideal solution, but I don't think that works ATM)? can we
implement something to one-time-deal translate those reports into YA
saved-reports-2.2 file?  

A

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.gnucash.org/pipermail/gnucash-devel/attachments/20071231/7748d0c3/attachment.bin