"Further results" link should preserve intro and outro parameters
Closed, ResolvedPublic


Author: dan.bolser

I want to link to the thread where this topic was discussed, but sourceforge is so useless that I can't. Its buggy. I didn't come here to report a bug so I can find a bug in the dam mail archives... this makes me so angry, because mailman works! The mailman archives work! Why re-invent the wheel when your going to brake it... do things really get better?


MIME-Version: 1.0
Received: by with HTTP; Mon, 25 May 2009 09:34:40 -0700 (PDT)
In-Reply-To: <200905211013.53196.markus@semantic-mediawiki.org>
References: <2c8757af0905090523o677b6f19g9616b28157065f3f@mail.gmail.com>


Date: Mon, 25 May 2009 17:34:40 +0100
Delivered-To: dan.bolser@gmail.com
Message-ID: <2c8757af0905250934l3df883edv4dcd52726253f6a8@mail.gmail.com>
Subject: =?windows-1252?Q?Fwd=3A_=5BSMW=2Ddevel=5D_Problem_with_=22=85_further_results=22_?=
From: Dan Bolser <dan.bolser@gmail.com>
To: Dan Bolser <dan.bolser@gmail.com>
Content-Type: multipart/mixed; boundary=00504502d6f2cd996e046abf2f5f

Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

Forwarded conversation
Subject: Problem with "=85 further results" when using "format=3Dtemplate"

(Was: "[Semediawiki-user] New "tips" section on SMW Community Wiki")

From: Dan Bolser <dan.bolser@gmail.com>
Date: 2009/5/9
To: semediawiki-user@lists.sourceforge.net, Semantic MediaWiki
Developers <Semediawiki-devel@lists.sourceforge.net>


I'm using the "intro=3D" and "outro=3D" query parameters to provide the
table header and footer to get tabular output with the
"format=3Dtemplate" in an ask query:


This is working great with a couple of caveats:

  1. the "... further result" link appears at the top of the table for

some reason. I'd expect it to appear after the end of the table... how
is this text interacting with the various "format=3D" settings?

  1. the "... further results" link takes you to a "Special:Ask" page

that ignores the ""intro=3D" and "outro=3D" query parameters (leading to a
very messy result). Is it possible to get Special:Ask to respect these
and other settings?

With regard to 2, there appears to be at least one related bug for
"Special:Ask". Click on "... further results" for any
"format=3Dtemplate" query -> Click on "[Edit query]" -> Click "Find
results" -> You see the error "Provide a value for the parameter
"template" for this query format to work.", i.e. the template
parameter is lost when you click edit query, and has to be manually
added (along with intro and outro if necessary).


From: Markus Kr=F6tzsch <markus@semantic-mediawiki.org>
Date: 2009/5/17
To: semediawiki-devel@lists.sourceforge.net
Cc: Dan Bolser <dan.bolser@gmail.com>, semediawiki-user@lists.sourceforge.n=

The link is put to the top by MediaWiki since it does not understand how to
otherwise treat this text within a table context. The best workaround might=
to have "searchlabel=3D" (empty) as a parameter to completely hide this par=
You can give the quer another time with the same parameters but "limit=3D-1=
" to
get a "further results" label anywhere you want ("-1" skips any checks so t=
the link is displayed even for 0 results, saving resources, but it might be
good to change text to "show all results" or something similar). You can al=
include this additional query into the "outro=3D" part to make sure it is o=
displayed if there are any results at all.
This would require some extension of the SMW code. It is not possible in th=
current SMW-version. Using the above method for creating the "further resul=
link, a possible workaround would be to use another format in this "limit=


query. Then it would at least be usable.
Interesting. This might indeed be the case.

In general, it would be very helpful if you could file your bug reports and
feature requests at MediaZilla, since we may otherwise forget about them ..=





  • The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Yo=


production scanning environment may not be a perfect world - but thanks t=


Kodak, there's a perfect scanner to get the job done! With the NEW KODAK
i700 Series Scanner you'll get full speed at 300 dpi even with all image
processing features enabled. http://p.sf.net/sfu/kodak-com

Semediawiki-devel mailing list

Markus Kr=F6tzsch
Semantic MediaWiki =A0 =A0http://semantic-mediawiki.org
http://korrekt.org =A0 =A0markus@semantic-mediawiki.org

From: Dan Bolser <dan.bolser@gmail.com>
Date: 2009/5/20
To: markus@semantic-mediawiki.org
Cc: semediawiki-devel@lists.sourceforge.net,

2009/5/17 Markus Kr=F6tzsch <markus@semantic-mediawiki.org>:
hehe - sorry about that ... sometimes even I forget about them too!

Did you log this one already, or would you like me to go do that?
actually I found that even if you do pass a template you get the same

Thanks for the reply,

From: Markus Kr=F6tzsch <markus@semantic-mediawiki.org>
Date: 2009/5/21
To: Dan Bolser <dan.bolser@gmail.com>
Cc: semediawiki-devel@lists.sourceforge.net,

Yes, please.
Yes, we need to adjust some internal parameter handling in Special_Ask, I


Content-Type: application/pgp-signature; name="signature.asc"
Content-Disposition: attachment; filename="signature.asc"
Content-Transfer-Encoding: base64
X-Attachment-Id: 0.1


Version: unspecified
Severity: enhancement

bzimport set Reference to bz18911.
bzimport created this task.Via LegacyMay 25 2009, 4:35 PM
mkroetzsch added a comment.Via ConduitAug 1 2009, 6:42 PM

A potential problem that this will cause is that the URL for further results will need to contain the complete intro and outro texts, making it again longer. But the main reason why this is not fixed yet is that the display on Special:Ask does not currently happen by parsing wiki text but by generating HTML. This needs to be changed in order to preserve wiki formatting like table headers/footers.

Maybe it would be better to introduce a templated table display instead for addressing this problem?

bzimport added a comment.Via ConduitJun 29 2010, 5:16 AM

mail wrote:

Are there any updates on this?

A templated table display would be fine.
Being able to have HTML (but not Wiki text) in intro and outro would also be ok with me.

I'm using a lot of format=template queries, and some of them are getting really long and slow to load, because there is a lot of information in the Wiki now. Thus I need a way to split the query result.

Jdpond added a comment.Via ConduitJun 29 2010, 11:36 AM

Bug 22037 - Advanced Formatting for Query Tables fixes this too. It's in the can, tested and running on several production wikis and ready for release if approved.

Jdpond added a comment.Via ConduitJun 29 2010, 12:06 PM

Patch that fixes this bug AND adds table formatting capability

This is a patch that will fix this bug AND allow custom templating of return tables for more complex query formatting. See also bug 22037. Can commit whenever.

attachment SMW_QP_List.patch ignored as obsolete

Jdpond added a comment.Via ConduitJun 29 2010, 7:14 PM

Advanced Formatting and "further results" fix

Advanced Formatting and "further results" fix. Fixed formatting - thanks to Yaron for help

Attached: FurtherResultsFormatting.patch

Jdpond added a comment.Via ConduitJul 6 2010, 10:33 PM

Fixed and tested: r68747

Addresses Markus's comment above (Comment 1) because only the template names are passed and parsed, not the entire contents of the intro and outro.

At some point in the future, we should consider using "POST" instead of URL to pass the parameters, but please note, I am NOT volunteering for that job.

Add Comment