Author: trueskew
Description:
A query the uses:
| format=template |
| template=sometemplate |
| limit=0 |
will show the "... further results" in a table and not using the "sometemplate" format. If at least 1 record is shown with
| limit=1 |
the further results link will show the properly formatted results.
Example:
http://scratchpad.referata.com/wiki/BuildList
Version: unspecified
Severity: major
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Resolved | mkroetzsch | T27915 Format Failure when using format=template and limit=0 | |||
| Resolved | None | T39441 [SMW] [ROADMAP] [OPEN] Improve query argument handling |
trueskew wrote:
"... further results" should take me to a page that presents data using the template, not a broadtable.
(In reply to comment #2)
"... further results" should take me to a page that presents data using the
template, not a broadtable.
Oh ok, now I get it. Will have a look soonish.
The issue is that the HTML that is outputted is not valid. Basically what's done is list items in divs in a list. What should be done is list items in a list per column (div).
When the limit is 0, no results are printed, and the getResultText method of the query printer is never called. This method causes the template parameter to be set in the further results link, so this issue is not limited to the list formats, but occurs for every query with limit 0, and all parameters that would normally be passed along.
trueskew wrote:
That makes sense, and perhaps when the "Result limits and links to further results" section was written (http://semantic-mediawiki.org/wiki/Help:Inline_queries#Result_limits_and_links_to_further_results), only the table case was used. Do you anticipate the fix being difficult?
To fix this, you'd need to make changes to every query printer. I'm not sure this feature is worth it, as you can achieve similar results by creating your query on Special:Ask, and then linking to it.
In reply to comment 4: Accidentally posted this with the wrong bug :)
We understand the implication, why limit=0 causes trouble but handling further results via #ask is much simpler and easier than to have to generate the actual URL and replace #ask with {{fullurl ... }}.
For example, in our case we use a lot of graphs that displays a limit amount of data while allowing an additional link to Special:Ask page where the user can display a larger set of data. At the moment all those additional links are {{fullurl: }} to point to Special:Ask but as soon something changes its quite a bit of work to get all the URLs working again. Therefore we still will vote for this request and whenever someone finds the time to get it right we will be happy.
Just re-read the issue and my analysis of the problem. The current way extra params are passed to the further results links is rather ugly and fragile, and can now that Validator is used, be replaced by a much nicer and generic system. Doing this ought to solve this issue, but it's a bunch of work. Also, I think there are enough such changes for 1.7 already and am tempted to defer this to a later big release, ie 1.8 or so.