Apologies. I have belatedly noticed that the namespace, when needed, is already included in $valuesTable's 'title'. See amended patch below.

diff --git a/drilldown/CargoSpecialDrilldown.php b/drilldown/CargoSpecialDrilldown.php
index 9e887fa..37c704a 100644
--- a/drilldown/CargoSpecialDrilldown.php
+++ b/drilldown/CargoSpecialDrilldown.php
@@ -1366,6 +1366,17 @@ END;
 		$formatter = $queryDisplayer->getFormatter( $out );
 		$html = $queryDisplayer->displayQueryResults( $formatter, $valuesTable );
 		$out->addHTML( $html );
+		
+		// Check whether user has created a Drilldown template page for this table 
+		$drilldownTemplateTitle = 'Template:Cargo Drilldown ' . $this->tableName;
+		if ( Title::newFromText($drilldownTemplateTitle)->exists() ) {
+			// Create a comma-separated list of Drilldown result pages for sending to user's template
+			foreach ( $valuesTable as $valuesTableRow ) {
+				$valuesTableList .= '"' . $valuesTableRow['title'] . '", ';
+			}
+			$valuesTableList = rtrim ($valuesTableList, ', ');
+			$out->addWikiText( '{{' . $drilldownTemplateTitle . '|' . $valuesTableList . '}}' );
+		}
 	}
 
 	function openList( $offset ) {

This is interesting. Do you have a specific use case where this would be useful? If so, could you describe it?

For a table which has coordinates I'd like to include a query like this:

<includeonly>
{{#cargo_query:
tables=Address
|fields= _pageName,<...>
|where= _pageName in ({{{1}}})
|format=googlemaps
}}
</includeonly>

This would be more flexible than if the Drilldown page were to automatically include a map for any field with coordinates, as this would allow me to choose what fields should appear on the map. (If it were to be automatic I guess you would want to have a separate variable for whether or not the user wanted it, and which type of map, and for Google would need to check whether the user had the $wgCargoGoogleMapsKey variable... and you would need similar things for other automatic output types... not much less complicated.)

For another table which has just text fields, I would like to be able to include some of the fields from each page as part of the Drilldown results. Something like this:

<includeonly>
{{#cargo_query:
tables=Information
|fields= _pageName, Summary, Date<...>
|where= _pageName in ({{{1}}})
|format=table
}}
</includeonly>

I suppose ultimately think it would be good if the Drilldown page defaulted to a Cargo query with "category" output format (similar to what it looks like currently) but allowed the user to override that with a template page, to decide exactly what output format (maybe two queries, or compound queries) should be used for each table. So in the second example above, I would prefer the Drilldown page to only contain the results of my Cargo query, without also including the standard "category" results.

Okay, that's interesting. It seems to me that the only really customizable thing is which extra fields to display, though. You wrote this:

If it were to be automatic I guess you would want to have a separate variable for whether or not the user wanted it, and which type of map, and for Google would need to check whether the user had the $wgCargoGoogleMapsKey variable... and you would need similar things for other automatic output types... not much less complicated.

I don't think any of these are true. In my vision, a table containing a coordinates field would always have a map, and a table containing a date field (or more than one) would always have a timeline - or a calendar, depending on how far away the dates are. The different displays would be shown in different tabs within the page, preventing clutter and allowing users to ignore displays they don't need.

To determine which mapping service to use, the presence or absence of a $wgCargoGoogleMapsKey setting seems like a reasonable criterion for now... it may eventually make sense to have a "default Cargo mapping service" global variable.

That leaves, if I have it right, just a need to be able to define which additional fields get shown. #cargo_declare currently has a "hidden" keyword, which prevents that field from being used as a drilldown filter. What if it had a new keyword, called "default display" or something (maybe there's something more pithy), which led to such fields always being displayed in drilldown results? If such a thing existed, it might also make sense to include such fields in the default set of fields for #cargo_query if no "fields" parameter is specified. (Right now, that parameter always defaults to just _pageName.)

What do you think?

It seems to me that the only really customizable thing is which extra fields to display, though.

It would also be possible to customise layout (e.g. table), or do several queries, or do a compound query (e.g. for different coloured markers on a map), or just add customised text. By the way, I now think that it would be better to either have the customised template appear above (rather than below, in the proposal above) the standard category-style list of pages - or, even better, have an option to do away with the standard list altogether to allow for full customisation.

But I can see your way of thinking, so here are some initial thoughts.

I don't think any of these are true. In my vision, a table containing a coordinates field would always have a map, and a table containing a date field (or more than one) would always have a timeline - or a calendar, depending on how far away the dates are.

I'm not sure all users would always want maps, timelines etc, so there should definitely be options to change the default (e.g. don't show timeline for this particular date). This could be done by a parameter which allows for a field to appear on Drilldown but not lead to an automatic map etc. Maybe "drilldown plain"?

Or maybe drilldown=hidden (same as existing hidden), drilldown=plain, drilldown=enhanced, and the user can set the site or table default as plain or enhanced using a global variable in LocalSettings.php?

The different displays would be shown in different tabs within the page, preventing clutter and allowing users to ignore displays they don't need.

I think Google maps, timeline and calendar all fail to initialise/display if they are initially set as hidden (by Foregound skin tabs, or the Mediawiki collapsible CSS).

Should the user be able to choose which automatic format would appear in the first tab? Whether it should be calendar or timeline, or both, for date? More parameters?

To determine which mapping service to use, the presence or absence of a $wgCargoGoogleMapsKey setting seems like a reasonable criterion for now... it may eventually make sense to have a "default Cargo mapping service" global variable.

Sounds good too.

That leaves, if I have it right, just a need to be able to define which additional fields get shown. #cargo_declare currently has a "hidden" keyword, which prevents that field from being used as a drilldown filter. What if it had a new keyword, called "default display" or something (maybe there's something more pithy), which led to such fields always being displayed in drilldown results?

What about drilldown=include (if it would be possible to have multiple values e.g. "drilldown=plain include") or otherwise just "drilldown include" as the parameter.

This should still be subject to the ability to choose the layout. I guess there can't be that many possibilities, but for me I'd prefer a table format rather than a two- or three-column list like present, especially if there are potentially going to be multiple fields being displayed alongside the page name.

If such a thing existed, it might also make sense to include such fields in the default set of fields for #cargo_query if no "fields" parameter is specified. (Right now, that parameter always defaults to just _pageName.)

Yes that makes sense.

Hi,

It would also be possible to customise layout (e.g. table), or do several queries, or do a compound query (e.g. for different coloured markers on a map), or just add customised text.

A table may make sense if there are a lot of display fields... maybe if there are more than, say, three display fields, it should just show up as a table instead of a category?

I don't know what you would need "several queries" for. What would be an example of that?

If there's more than one Coordinates field in a table, I would indeed imagine that the map would show the different points as different markers on the map. So that again could (and should) be taken care of automatically by the code, I think.

What kind of customized text might users want?

I'm not sure all users would always want maps, timelines etc, so there should definitely be options to change the default (e.g. don't show timeline for this particular date)

Maybe all users indeed will want maps, timelines, etc.? I can't think of any reason why someone wouldn't.

I think Google maps, timeline and calendar all fail to initialise/display if they are initially set as hidden (by Foregound skin tabs, or the Mediawiki collapsible CSS).

That may be true - in that case, it would be possible to implement the tabs via just HTML - the way it's done in Special:Preferences, I think - so that each tab is actually a separate web page, more or less.

Should the user be able to choose which automatic format would appear in the first tab? Whether it should be calendar or timeline, or both, for date? More parameters?

I would think it makes sense to just hard-code the order - have it go category/table, then map, then timeline/calendar, or something like that.

A table may make sense if there are a lot of display fields... maybe if there are more than, say, three display fields, it should just show up as a table instead of a category?

Yes, I guess so. If they appear in the order they are defined in #cargo_declare that would provide the user with flexibility. You could have a global variable saying at which number of fields it changes from category to table (I would set that at 0!)

I don't know what you would need "several queries" for. What would be an example of that?

I was getting carried away there... I suppose something like: (a) a map of the places, followed by (b) a table of names, addresses and telephone numbers. However, I can see how your automatic, tabbed approach would have a similar effect.

If there's more than one Coordinates field in a table, I would indeed imagine that the map would show the different points as different markers on the map. So that again could (and should) be taken care of automatically by the code, I think.

Unless maybe it would make more sense to have the two sets of coordinates appear on two maps, maybe e.g. "UK offices" and "US offices"? This doesn't apply to me so I'm just guessing.

What kind of customized text might users want?

Maybe explanations of how the Drilldown page works, etc, though your way would allow that to be done using system messages.

Maybe all users indeed will want maps, timelines, etc.? I can't think of any reason why someone wouldn't.

They take a while to load. Someone might want a simplistic interface for non-technical users. But if they are in tabs, and don't slow down display of the initial tab, then I don't imagine they would be a problem.

That may be true - in that case, it would be possible to implement the tabs via just HTML - the way it's done in Special:Preferences, I think - so that each tab is actually a separate web page, more or less.

Cool.

I would think it makes sense to just hard-code the order - have it go category/table, then map, then timeline/calendar, or something like that.

Sounds fine. With dates, I think timeline and calendar can sometimes both be useful for the same data, so don't think it should be either/or.

P.S. I wonder whether it would be possible to add a hook to Cargo to allow someone to create their own mini extension to modify the output of Special:Drilldown without having to amend the code of the extension. This could be a short-term solution for me.

You could definitely do it via a hook and separate code... it wouldn't be that helpful for other users, but if you need something right away, that could be the way to go. It probably makes the most sense for you to just add in the hook yourself in to your version of the Cargo code. Though if/when you do that, let me know what the line (i.e., the new Hooks::run() call) is that you added to the Cargo code - I'm always happy to add more hooks in to my code.