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 [email protected] > 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: [email protected] www: http://www.iis.fraunhofer.de/ _______________________________________________ gnucash-devel mailing list [email protected] https://lists.gnucash.org/mailman/listinfo/gnucash-devel
