Report system legacy

[Herbert Thoma]

Am 29.06.2013 17:38, schrieb Geert Janssens:
> On 29-06-13 16:52, John Ralls wrote:
<...>
> Just for clarity, the definitions of report-template and report are purely in guile code (src/reports/report-system/report.scm).
> Our c code is totally unaware of this. It just passes around opaque SCM objects. I don't even know where the html page appears
> in this picture. It's not in this part of the code yet. A "report" in report.scm is defined as a record containing a report-type (which is the guid of a base report template), a report-id (just a number), a structure holding the report options, a reference to the editor widget and some housekeeping flags.
>> 
>> Where I'm going with this is that if a report is if a Report is open it will just sit there until the user tries to reload it
>> (which would include loading a Book with an open report). If the ReportTemplate is changed, the Report gets re-created based
>> on the new ReportTemplate, right? If the ReportTemplate is gone, which is currently possible if one deletes a "custom report" in
>> the dialog box, I would hope that Gnucash displays a nice "Can't find the Report" in the HTML page rather than crashing.
> This doesn't happen, because the custom report's template id is never stored in a report record. Instead the base template on
> which the custom report template is based on is stored in the report record. So when you reopen a report (by reopening a book),
> the report currently doesn't even know it ever was instantiated from a custom report. It will reinstantiate from the base template.
> I believe this was originally done exactly to prevent unexpected crashes when the custom template got deleted.
> 
> This results in a two-level template hierarchy. The base templates are all the report definitions that ship with gnucash, or that
> a user loads manually (what I would consider a true "custom report"). What is called custom reports now are the reports a user can
> save from within the program. Which really aren't much more than a reference to a base report and a custom set of default options.
> The code keeps this hierarchy shallow. There will never be a custom template based on another custom template. Which I think is
> good exactly to avoid the template is deleted issue.
> 
> But I needed to keep track of which custom template a report is instantiated from, so I have now added an extra parameter in the
> report record to keep track of which custom report was optionally instantiated when the report was generated. I'm still keeping
> this parameter separately from the "report-type" which will always hold the core template to prevent the crashes you describe.

My question here is: Why do we need an intermediate custom template at all?

If a custom report template is a core template with a set of options, a new custom template
should be a core template with a set of options as well. Why do we need the reference to the old
custom template for the new custom template? What am I missing? Do changes of options in
the parent custom template affect the child custom template? If yes, how can a user see such
dependencies? Would we even want such a behaviour?

BTW: The whole report logic is too much on the scheme side, IMHO. A while back I tried to
implement a "refresh all reports" feature (I have a number of reports open and right now the most
convenient way to refresh them all is to close GnuCash and start it up again ...). I gave up
on the "refresh all reports" feature, because I could not even find the proper place for the
for all open reports loop. I could not find a list of open reports in the C side code so I
concluded it must be on the Scheme side, but my scheme-foo was to low :-(

 Herbert.

> If the custom report gets deleted, the reference to it in the report record becomes invalid. But this is still no problem, because
> the rest of the code will treat an invalid reference as no reference at all. Or put another way: if you delete a custom template,
> any report that was instantiated from it will now be treated as if it was instantiated from the custom template's parent (or base)
> template and everything continues to work.
>> 
>> So for your rename problem, don't allow renaming TemplateB to TemplateA: Require the user to explicitly delete TemplateA. Don't
>> change the GUID for TemplateB, and retrieve report specs by GUID rather than name. The behavior for open Reports based on TemplateA
>> is then the same as it is now (unless it crashes Gnucash, which should be fixed first).
>> 
>> Regards, John Ralls
>> 
>> 
>> 
> Given how things currently work I think it's even ok to allow renaming TemplateB to TemplateA, added a proper warning, explanation and 
> user confirmation. It will have the exact same effect as  having the user delete TemplateA and then rename TemplateB to TemplateA in
> two separate steps. Other than that I agree that guid should be used as key. That's already the case now.
> 
> Geert _______________________________________________ gnucash-devel mailing list gnucash-devel at gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
> 

-- 
Herbert Thoma
Dipl.-Ing., MBA
Head of Video Group
Multimedia Applications Department
Fraunhofer IIS
Am Wolfsmantel 33, 91058 Erlangen, Germany
Phone: +49-9131-776-6130
Fax:   +49-9131-776-6099
email: herbert.thoma at iis.fraunhofer.de
www: http://www.iis.fraunhofer.de/