On Tue, Nov 13, 2012 at 11:31 AM, Tim Lyons <email@example.com>
Nick Hall-6 wrote
It was proposed to treat a WebSite like a Book. A WebSite could run a
selected list of Web components (reports) just as a Book runs a
selection of standalone reports.
The main WebSite class could generate a Homepage and also store the
objects to be displayed.
a separate class for each section
of the NarrWeb report. These sections should access a WebSite class for
shared information (not each other). This will make further development
easier in the future.
I still have a design problem with constructing the list of objects to be output. If I do it in the central/kernel WebSite class, there are three problems:
(1) Individual sections do not always include all possible objects. For example, generating a website from gramps34/example/gramps/example.gramps created pages that have references to about 11 of the citations for the source called "All possible citations". But there are actually 26 citations in all. Only the individual sections know which objects they generate. If I generate the list externally, then some objects will be generated seemingly unlinked! Is this OK?
Tim, first let me say "thanks" for working on these issues! NarrativeWeb is code that probably has the highest ratio of "most users depending on it" to "amount attention from developers". It has grown to be a wonderful monstrosity :)
Your issue #1 actually is an issue for all reports. Filtering to get the right records, and then protecting them appropriately (eg, private, living) is a complex affair, and one that I think we now have correct. For example, applying the private proxy first gives very different results from applying it later, and users need to have that control. Unfortunately, we are only using the selection code in the "export" selection dialog. I believe that we should re-use the selection code for all reports. This accomplishes a few things:
* reuses the code
* ensures correctness
* removes report writers from having to handle privacy/selection issues
I suggest that we start with NarrativeWeb and remove the selection code (Filter Option on "Report Options" tab and the entire "Privacy" tab). We then need to add Options for saving/loading the Selection options in the XML of the report, and add a new tab for the report "Selection Options".
At this point we have another design point: NarrativeWeb has allowed further restrictions on what to include. For example, one might want to include Notes, but not Events. The Selection options for export already have some of this as it allows you to select an additional Note filter, and a Reference option for filtering out those objects not linked to a selected person. The choice: do we make the reports to each choose what to include, or do we push that make to the Selection options? For example, I could imagine that we have a filter choice for all primary objects in addition to the existing one for Notes (Events, Places, etc.) On the one hand, adding all of the primary type filters to the selection options makes sense (why is Note filter included, but not others?) but the selection options is already complicated. (We could hide Note Filter and the rest behind a "More..." button).
Or, we could leave further primary object inclusion to the reports to filter and handle. Re: "If I generate the list externally, then some objects will be generated seemingly unlinked": can we handle that as described above, and we check the db to see if it is included? Does that take care of that issue, and the next two?
(2) How does one section determine the URL for links to other sections. If it asks the other section, that will introduce access between sections.
(3) How does one section determine the backlinks to other sections. I don't want to generate all the backlinks as I generate each page, because that is quite a slow process, especially as I have iterated through each link already.
At present I am thinking of a three pass process:
pass 1 the central/kernel loops through all people accessible under the current filter, and then recursively through all objects linked to those people, building a list of all object handles that can be output and backlinks for each (storing the text for the link e.g. the person's name, the family name, the event name etc).
pass 2 all independent sections are called to add the URL for the pages to the central/kernel list of objects. This won't work if more than one plugin is generating pages for a given object handle).
pass 3 all independent sections are called to generate the pages.
But this seems quite performance expensive, because of repeated scans. Any suggestions?
Right, but I think the selection proxies/filters will take care of this for us.