2012/11/30 Doug Blank <doug.blank@gmail.com>


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.

I think we only allow links to primary objects. Therefore, a source can point to a person, a person can point to a note, a note (through the new links-in-text) can point to another note, etc.

A People summary page (list of people, list of names) only points to individual people (person-handle.html). You should not be able to link to a summary page (unless you hand-code a link into a Note or an added footer option, or something). Summary pages are generated by the central WebSite generator (which replaces NarrativeWeb).

On the contrary, when on a person page, to have a link from the name of the person to the name index with curson on that name is interesting.

So consider this case, a plugin writes out a family name in some circumstance, and can put the family name as a clickable link. This is not a primary object, and the link should only be shown if a surname page is present or a list page of all people sorted on surname first.
The plugins will need to know a bit about the possibilities of other plugins to achieve this. It seems the central class needs to be allow to register link types. When the a plugin wants to write out a link, this must pass through a function of the main class that decides the actual link to use.

So, for example the person plugin writes out a person name and wants to put the surname as a link to the collection of those surnames. It requests something like {'link_type': 'surname', 'value': 'Lyons'} from the main class, expecting to receive the url to link to.
The main class goes over the plugins that registered they handle 'surname', and returns as a list the value or url. So the return value can be ['root/index_surname.html#Lyons', 'root/index_names_LtoN.html#Lyons']
A plugin knows it's own position with respect to root and can reform these url to correct form. Here two cases are returned. The plugin can use the first, or can use the first, and a superindex for the second, or some other way.

As a page can be subplugins, like a map, a subplugin should always have a relative position in it's top page.
So, for a link to person Tim Lyons his sources, the request could be {'link_type': 'person', 'value': 'a1q3498djfje', 'content': 'source'}, and the main class should return if there is an link to sources in the person link_type.

Just ideas, I don't say this is a good design, did not think long enough about it to claim that. Main point is that there is a designed api to request things, and fixed function to layout an url based on the reply.

Benny