On 30-06-13 10:38, Herbert Thoma wrote:
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?
It wasn't needed until now.
This is what has changed: the new user interaction will allow you to do
this sequence:
- open a report based on a custom template
- make some changes in the options
- hit save -> this will update the custom template the report was based on
For this last step, you need to keep track of which custom template (if
any) a report is based on.
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.
It is.
Why do we need the reference to the old
custom template for the new custom template? What am I missing?
See above.
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?
Custom templates are never based on other custom templates. Only a
report can be instantiated from a custom template. So there is no custom
template hierarchy. As for instantiated reports (or "open" reports if
you like), they won't change if their custom template changes. A custom
template is only relevant to open a fresh report based on it. At that
point all options are copied from the template to the new report. Any
changes later on in the custom template will not be propagated to
already open reports.
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 :-(
I agree. The report system is almost purely written in scheme. The only
parts that touch C are the parts that integrate the whole report logic
into the GUI.
Unfortunately that's how it is currently. I would take way more time
than I have available in the short term to change this, though it is one
of my long term ideas.
Geert
_______________________________________________
gnucash-devel mailing list
[email protected]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
