Thanks for your helpful contribution on this question.

I did start out by assuming that plugins were related to objects, so there was one for e.g. Person.

I agree that selection ensures that there is no risk of pointing to a person or source that has not been provided to another plugin.

However, this does not address the problem of part pages and things like all sources on one page See below:

On 29 Nov 2012, at 15:40, Benny Malengier wrote:


First, with the export selection code, a plugin would only see information that is present in the selection code. So there is no risk of pointing to a source or person that will not be present in another plugin. This is a first important part of the design.

Second, the central class knows the plugins, and should know which objects will be written to the narweb. So a user selects source and person plugin, nothing else, then the central class knows this.
I would then assume a plugin, on adding eg a media, will know from the central class no media pages will be written, so no link is added, only the content.

The central class should make sure no two plugins about the same object will be run, so no duplicate pages.

Yes, I agree the central class knows no media are written, so no link is added to them. However, things like the (surname page and surname index) and the (individual index and individual pages) are in a sense duplicate (they both display information about individuals), so they need to be allowed for.

On the other hand, we would want plugins for only parts of a page. This seems to indicate to me that we need a central class, then a plugin class for the different pages (person, source), and for cross links the central class can be queried for that. Then sub-plugins that write part of a page. Eg, a plugin for a map on the place pages.

The problem that I was describing is not addressed by this. The problem is that a Person plugin will only output part of the information about a person (in your terms it will be a part of a page - part of the Socratic Ideal page that outputs all of the available information about the person). If the person page does not output the information that the source page would be referring to, what happens? That is the central point of the question I was asking.

For control, we could mandate that the object plugins are actually no plugins at all, but our code, and we then only need to know if user wants the page present or not. The actual plugins are then for pieces on the pages.

So, I would make sure that in the design we keep some control so the user is not able to combine everything with everything.

OK, that sounds a good idea. 

About a source page plugin that could put all the sources on one page. This seems to indicate that the central class should query the page class on the url for the object.
central class -> central person page -> person plugins
                    -> central source page -> source plugins
If source needs url for the person, the source queries central class with the handle of the person, and the central class returns the result the central person page returns for that handle.

I don't understand this. What is the link diagram showing? Why would the central page person class know what the url is for any particular person plugin? 

The problem with this sort of relationship is that it cannot support the objective in GEPS022: "The main goal of the refactor is to move each major part of NarrWeb into its own Web Report that can be run as a stand-along webreport, or as a sub-report of the refactored NarrWeb." If one webreport is dependent on another to find the url, then the webreports cannot be run stand alone.


If no person page is registered, the returned url would be empty.

We should be careful a plugin based narweb does not become a configuration nightmare for the user. Most uses will want some simple options and press 'Generate website'.

Yes. I am not trying to support the full flexibility implicit in GEPS022 at the moment. I am only trying to work within the current functionality of the current NarrativeWeb but to change the structure to allow for a future move towards GEPS022.



2012/11/29 Tim Lyons <>
Nick, Doug, Thanks very much for your replies.

Unfortunately, my question was not about filters at all. I agree that
reusing the "export" selection code would be a good idea, but that
seems just to be a matter of implementing it, and my question was

I am sorry that I was not clear, and will try again with a specific
example. The problem is: how does one plugin determine the URL for
hyperlinks to pages produced by other plugins?

The database consists of Person "Alice", Person "Bob", Citation "Page
5" and Source "Legend". All these objects are selected by the current

Alice has a Source Citation of Page 5/Legend for herself (i.e. in the
Person Editor, under the Source Citation tab). Bob has a Source
Citation of Page 5/Legend for his name (i.e. in the Name editor under
the Source Citation tab).

Alice -> Page 5 -> Legend
Bob -> Name -> Page 5 -> Legend

The Source plugin is designed to show the Page/Volume for Citations
that reference that source and a hyperlink to the pages for the
objects that reference the Citation. So, in general, on the "Legend"
page you would expect to see "Page 5" and a hyperlink to the pages for
Alice and Bob.

Source Legend -> Page 5 -> Person Alice
                         -> Bob

Now consider three different plugins for people.

Plugin X output one page for each person, and displays the sources for
people (but not the sources for names). So this plugin would produce a
page for Alice mentioning the source "Page 5/Legend" for her. It
should contain a hyperlink to the Source page "Legend". This plugin
would also produce a page for Bob, but there would be no mention of
the source, and hence no hyperlink to the Source page.

Plugin Y outputs one page for each person, and displays the sources
for names, but not the sources for people. So Alice will not have any
sources, and Bob will mention the source "Page 5/Legend"  and have a
hyperlink to Legend.

Plugin Z outputs one page for each surname, containing details all
people with that surname. So there would be one page for both Alice
and Bob, and this might mention the source for both Alice and for
Bob's name.

Now the idea of plugins is that it should be possible to run the
source plugin and X, Y and Z independently.

At present, what I have done is to implement a central/kernel class,
which determines the list of object to be output, which are Alice,
Bob, Page 5 and Legend (this works well, and solves some current bugs
where some linked objects are missed).

The question is, how does the Source plugin determine the URL for the
backlink hyperlinks to the objects that reference the citation Page 5?

At present, I have implemented the central class to assume that the
URL for all pages is derived algorithmically from the handle, so the
assumed URLs for Alice and Bob are known.

I have implemented the central class to recursively discover all the
objects that might need to be output, so it progresses:
Alice -> Page 5 -> Legend
Bob -> Name -> Page 5 -> Legend

As it follows these links, it remembers the backlinks (so they don't
have to be rediscovered later).

So the Source plugin can look at the list of Source objects to be
output, and can discover that it should output Legend. It can then
look at the backlinks and discover that the citations are Page 5, and
then look at its backlinks, and discover that it should output
hyperlinks to Alice and Bob, whose assumed URLs it knows. Hence it can
Source Legend -> Page 5 -> Person Alice
                         -> Bob

However, with plugin X, there will be a backlink hyperlink to Bob, but
when the user looks at the output page for Bob, he will find no
source, and will wonder why the hyperlink was produced. Conversely
with Plugin Y and Alice.

If you run plugin Z, then the assumed URL for people will not apply,
so any hyperlinks will be wrong.

Similar problems apply with the hyperlink from Alice and Bob to the
Source. At present, the list of objects to be output includes the
Citation Page 5, but as there is no plugin which outputs citations, we
can arrange for there to be no URL for Page 5. The person page
generation then needs to determine the source object (entirely
straightforward). At present, the assumed URL for the source object is
based on the handle, and this can be included in the hyperlink on the
person page. But what if the Source plugin does something different
(e.g. there is only one page for all sources)?

Finally, if you decide to run more that one plugin (e.g. plugin X and
Z), which should be the target for the backlink?

Sorry this is so long, but I hadn't explained my problem clearly before!